Реесторитарии всех стран!..

Блин... Писал, писал, и все слетело... Придется заново.
 
Буду писать "короткими предложениями".

Давайте действительно не будем изобретать велосипед, и будем делать на основе wikidot'а. По крайней мере на основе Wiki. Главное при выборе - это какие возможности по работе с базами напрямую сервис может предоставить. Это где можно прочитать?

Кстати, можно и просто взять движок (например, http://www.mediawiki.org/wiki/MediaWiki) и поставить на сайт.

Не, терять функциональность нельзя. А то окажется, что когда в проект будет вложено много сил, и он наберет обороты, функциональности ему и не хватает. Надо сразу делать правильно, по крайней мере в той части, что имеет принципиальных характер. Да и с тем 1% был только один пример. В реальности похожая проблема возникает, наоборот, почти всегда.

С простотой тоже не надо переборщить. А то получится согласно закону Мэрфи: "Сделайте устройство, с которым может обращаться даже дурак, и только дурак захочет с ним обращаться". Надо делать так, чтобы было просто внести простые изменения, и была возможность, немного подразобравшись, вносить изменения сложные.

Мне бы хотелось, чтобы у сайта была следующая функциональность:

1. Удобная навигация и просмотр списков.
2. Возможность делать простые запросы (парк какой-нибудь авиакомпании, список самолетов с бортовым номером "11" и т.д.).
3. Возможность простого добавления и внесения изменений.
4. Сохранение разных версий и архивирование.
5. Возможность доступа к базе сторонними приложениями. Это позволит профессиональным исследователям делать сложные запросы и проводить анализ.
6. Возможность размещения данных базы на других сайтах. То, что делает народ, должно народу и принадлежать.

5. и 6., конечно, можно и не делать, но, как мне кажется, это не потребует никаких дополнительных затрат при грамотной организации. Что-то еще забыл?


---------- Добавлено в 22:52 ----------


Поблагодарили : Ми-26
Нажмите, чтобы раскрыть...

Спасибо за Вашу работу на одноименной ветке.) Когда на нее заходишь, то сразу понятно, что такой сайт нужен.
 
кто может или не может вносить изменения - настраивается вплоть до полного запрета редактирования вики страниц- блокировки. Если появляется вандал, который портит сайт - он тоже может быть забанен по IP. А если человек активно и позитивно ведет сайт - то он получает больше прав и меньше надзора со стороны Вас, как создателя информации. К тому же "что изменилось" - довольно мощная страница, показывающая все изменеиня по категориям за любой срок и даже комментариями порой.

лучшего то все равно ничего нет, если не считать правку единолично или командой человек, получающих з/п. Любой большой коллективный проект рано или поздно становится чем то или вроде вики или вроде форума

когда будут 1000-чи - то будет не одна и не две страницы "что изменилось". Викидот позволяет делать мощные запросы типа "что изменилось в реестре ту-134 за последний месяц" или "что менял такой то человек" или "покажи только созданные страницы / только измененные" и тд


---------- Добавлено в 23:36 ----------



http://www.wikidot.com/doc:api-methods - имея ключ и поставив "разрешить доступ по API" - сайт может давать внешней программе возможность смотреть свои страницы или обновлять их или создавать новые. Методы довольно простые, пример на питоне тоже есть. Сам не пробовал, но в документации все выглядит не сложно. Единственное что - после тестового периода за это дело могут начать брать что то типа $50 в год


---------- Добавлено в 23:42 ----------


timsz сказал(а):
можно и просто взять движок (например, http://www.mediawiki.org/wiki/MediaWiki) и поставить на сайт.
Нажмите, чтобы раскрыть...
можно. Но потом кто будет платить за хостинг? в случае викидота - ты завязываешься на их API - минус, но и плюс - на их бесплатный хостинг и поддержку. У них создатели довольно хорошо отвечают на вопросы, улучшают функциональность и добавляют новые вещи. Мне по крайней мере обещали добавить парочку.
Переведен на русский язык викидот на 80%, и перевод может делать опять же каждый, если хочется получше
 
отвечу про викидот-движок
1. можно сделать практически с любыми списками. не хочу вас перегружать, но запросы почти как у БД, например списки самолетов в АК показываются запросом в виде:

[[module ListPages category="plane" _ak="%%fullname%%" perPage="45" separate="false" order="_serialnumber"]]
|| [[[%%fullname%%|%%form_data{regnumber}%%]]] || %%form_data{type}%% || %%form_data{ffyear}%% || [[image /register/%%form_raw{ak}%%.gif]] %%form_data{ak}%% || %%form_data{status}%% %%form_data{statustext}%% ||
[[/module]]
код лежит в http://airplanes.wikidot.com/ak:_template

где
regnumber - рег. номер
type - тип (боинг 737...)
ak - авиакомпания
status и statustext - текущий статус борта
и тд. Поля можно добавлять по мере необходимости, как в саму форму самолета, так и в запросы к этой форме.
посмотрите так же как устроена форма собственно самолета http://airplanes.wikidot.com/plane:_template

3. добавление - проще некуда - вноси номер и жми Ок. изменение - тоже - жми "редактировать" и выбирай из комбобоксов значения
4. ввсе версии страницы сохраняются автоматически. Сайт архивируется через интерфейс администратора (у вас есть доступ)
5. это есть http://www.wikidot.com/doc:api-methods
а) получить ключ API
б) администратор этот ключ вводит в админ-интерфейсе и разрешает доступ (зайдите на "управнение сайтом / доступ через API)
в) программа на внешнем компе делает запросы в стиле .categories.select({"site": "my-site"}) ["_default", "admin", "forum", "system", "blog"] или pages.save_one
6. викидот-архив - это зип файл с текстами. выкладывется хоть на эту ветку и разворачивается в новом месте по желанию народа же. Пока разве что они историю изменений не архивируют, но сами данные - да

из минусов - очень сложные запросы могут быть нетривиальными. например, нельзя (пока) сделать выбор из таблицы по нескольким столбцам сразу ("покажи боинги в S7") однако путем некого геммороя это все же можно - то есть добавить теги к страницам (теги "боинг" и "s7") тогда запрос будет работать и сейчас. В wish list викидота обсуждается много таких будущих фич.
 
а почему вы не хотите сделать standalone-проект?


---------- Добавлено 09.10.2012 в 00:00 ----------


p.s. могу пожертвовать домены AVIAREESTR.RU и/или AVIAREGISTER.RU
 
timsz сказал(а):
Спасибо за Вашу работу на одноименной ветке.)
Нажмите, чтобы раскрыть...
к сожалению нельзя объять необъятное и я ту ветку даже не читал. Меня тут осудили что де не знаю всех 787 и все сайты- реестры (хотя какие то знал) но невозможно за всем на свете уследить, надо и жить ещё когда то. Поэтому большой проект можно поднять только большим коллективом - кто то будет следить за ми-26, кто то за ту-134 и тд. А уж как сделать для каждого удобный интерфейс, списки, "что поменялось" и тд - это вопрос обсуждаемый. Ну и пока ещё не ясно "надо ли", кроме timzs никто интереса вроде не проявил


---------- Добавлено в 00:04 ----------


xoid сказал(а):
а почему вы не хотите сделать standalone-проект?
Нажмите, чтобы раскрыть...

мне кажется что вики-способ - простой и мощный для большого проекта. А уж через какой домен будет народ туда заходить - не суть важно. Может быть вики внутри, а снаружи как AVIAREESTR.RU и/или AVIAREGISTER.RU
это настраивается одной кнопкой внутри админ-интерфейса:

 
sova сказал(а):
мне кажется что вики-способ - простой и мощный для большого проекта
Нажмите, чтобы раскрыть...
а есть ли возможность создания шаблона страницы - чего-то вроде формуляра, с обязательными полями, с автоподстановкой данных в поля и т.п.?
КМК, вики в данном случае полезна лишь версионированием, хотя это не самый лучший способ защиты от дурака.
 
для этого нужен ваш опыт. если хотите - можно попробовать. Вы попробуете внести что то эдакое, если не сработает - я покумекаю можно ли это запрограммировать текущим движком или надо внешние силы подключать. Обуждать можно тут, там, или в личке
 
Вот как раз древовидных структур данных и нет (если работает приведенная схема). Данные хранятся в таблицах, которые связаны между собой через ключевые поля. То есть, классическая реляционная БД. Иерархическое представление получается за счет запросов. Если бы вся информация хранилась в XML файле, это была бы иерархическая структура.

На самом деле, как мне кажется, должна быть комбинация иерархических и табличных структур. Идеологически надо, чтобы все, что касается объекта хранилось в одном месте. Например, объект "Самолет". Связанная с ним структура данных включает, например, наименование, заводской номер, регистрацию и авиакомпанию. Авиакомпания - это отдельный объект, и включать информацию о ней в объект "Самолет" нецелесообразно - данные будут дублироваться, что плохо, прежде всего с точки зрения редактирования. Поэтому объект "Самолет" содержит ссылку на соответствующий объект "Авиакомпания", а данные по авиакомпании берутся по запросу к ее дереву.

Но если самолет эксплуатировался в разных авиакомпаниях, все ссылки на эти авиакомпании должны храниться в объекте "самолет", а не использовать отдельную структуру. Вот этого как раз в реляционных базах нормально сделать нельзя. Там можно или выделить ограниченное количество полей, что плохо, так как ограниченно, и так как все запросы и поиск становятся очень сложными, нелогичными и зависимыми от структуры, или сделать отдельную таблицу, где будут храниться записи по всем самолетам и всем авиакомпаниям. Так как практически каждое поле в объекте "Самолет" обладает такой изменчивостью, то таких таблиц должно быть много.

Сразу теряется наглядность, переносимость, а также такие органично вытекающие из иерархичности приятные объектные вещи, как наследование и пр. Впрочем, реляционные базы дают более эффективный поиск. Но за счет более сложной и неочевидной структуры, которая кроме всего ухудшает совместимость версий. Например, выяснилось, что какое-то поле может дублироваться. В реляционной базе это сразу приводит к добавление новой таблицы и полной переделке всего, что с этим полем связано. В иерархической базе все будет работать и дальше. Только теперь программы обработки должны понимать, что полей может быть несколько. А старые базы менять не надо. Если и в программе не поменять, то она все равно будет работать дальше, только игнорировать часть информации в тех записях, которые появились позже. А старые записи по-прежнему будут отображаться правильно. Это может быть очень важно на начальном этапе, пока структура не утряслась.

Со стороны все равно никто не смотрит на сами таблицы - смотрят на запросы и формы. И даже могут не подозревать, сколько таблиц хранится. Но эти запросы и формы проще реализовать в иерархической базе.

Тут целиком согласен со Стипаном - включать это в описание нельзя. Мы сразу порежем всю функциональность и получим еще один вариант табличек, которых в интернете полно. Например, простой и логичный запрос - перечислить все самолеты, которые были в авиакомпании, можно будет сделать только вручную. Или, например, найти все самолеты, у которых регистрационные номера начинались на "RA-45". Тот же ST сделает это гораздо лучше, хотя и даст всего 60 записей. Тем более, что в описании могут встречаться и регистрационные номера, которые к этому самолету не относятся, а просто участвовали в каком-то событии.

Даже, если придется делать на основе реляционной базы данных, все равно надо все сразу сделать правильно, чтобы потом не приходилось перетряхивать всю базу и все наработки по интерфейсу.
 
да, есть. Создается шаблон например http://airplanes.wikidot.com/plane:_template (нажмите "редактировать" и посмотрите код)

там описывается форма. Поля которые есть у самолета (рег.номер, фото, имя, а/к и тд)

потом когда чел редактирует данные - он видит удобную форму. В реальности он сохранит текстовый файл вида с именем "plane:ra-67017"
и содержимым:

"regnumber:RA-67017
status: летает
sernumber: 12345"

потом другая страница захочет показать все самолеты со статусом "летает". На той странице пишется запрос типа

[ListPages category="plane" _status = "летает"]
и показываются все такие самолеты

то есть это вики с БД средней сложности (внутри все индексируется и выдается довольно быстро)

посмотрите на реестре суперджетов - там довольно много чего уже есть и это все автоматически обновляется. Чел правит одну страницу борта - а обновляет тем самым и её, и главную реестра http://superjet.wikidot.com/register, и http://superjet.wikidot.com/production и http://superjet.wikidot.com/year:2012 и ещё кучу всего по необходимости. Например, все самолеты аэрофлота - начинают показывать новый борт - как своего "собрата".
Фотографии сами начинают показываться - только по ключевому слову "RA-что то там"

Человек меняет данные в одном месте - а отображение их меняется во разных местах. Попробуйте зайти на
http://airplanes.wikidot.com/register
добавить борт с разным рег-номером. менять номер. и посмотрите, появятся ли фотографии борта автоматом. используйте последние номера самолетов АФЛ, не исторические. Фото зальются и покажутся автоматически - что довольно удобно.

так же обновятся все ссылки - и на радар, и на сервисы типа айрлайнерс.нет и тд

хотя конечно сервис фотографий можно и нужно улучшать и улучшать. В идеале - он должен позволить человеку не уходя с сайта залить фотки на flckr.com со всеми возможными разрешениями и поставить нужные теги - рег.номер, тип, АК и/или заводской номер. Тут и защита копирайта, и удобство для сайта, и не надо за траффик платить - фликкер займется хранением фотографий
 
sova сказал(а):
Но потом кто будет платить за хостинг?
Нажмите, чтобы раскрыть...
Как кто?
xoid сказал(а):
p.s. могу пожертвовать домены AVIAREESTR.RU и/или AVIAREGISTER.RU
Нажмите, чтобы раскрыть...


Но это я, конечно, в том смысле, что если сайт будет интересным, то, думаю, проблем с поиском желающих его похостить не будет. Те же 300 Мб, которые дает wikidot и у меня есть. Даже если сайт не будет интересным.))

В общем, при выборе, как лучше делать, хостинг не должен пугать.


В общем-то да, ИМХО. Плюс встроенный интерфейс с базой данных, но тут возникает вопрос, нужна ли такая база. А какие еще могут быть варианты?

sova сказал(а):
это есть http://www.wikidot.com/doc:api-methods
Нажмите, чтобы раскрыть...

То есть, прямого доступа к таблицам нет? А схема данных, которая на первой странице с движком сайта никак не связана? И вот это:
XML версия схемы лежит тут http://airplanes.wikidot.com/local--files/start/DataSet1.xsd
Нажмите, чтобы раскрыть...
схема чего?

Если нет доступа, то как минимум надо понять, что будет при обработке таблиц в несколько сотен тысяч записей.

sova сказал(а):
сервис фотографий
Нажмите, чтобы раскрыть...

Отдельный большой и больной вопрос. Фотографии имеют свойство уходить из интернета. А именно там бывает нужная информация. Поэтому возникает необходимость архивирования хотя бы важных фото. Но тут вопросов масса, в том числе и правовых.


ЗЫ Сейчас напишу схему данных.
 
Последнее редактирование:
Приведу примерное описание базы, которую использую у себя. Сейчас пришло понимание, что надо несколько поменять структуру и перевести все с DTD на XML Schema. То есть, пишу то, что на сегодняшний момент планирую, хотя по большому счету от того, что есть сейчас почти не отличается.

База состоит из большого количества файлов: по одному на "крупный" тип, мелкие типы объединяю по конструкторам, и вывожу в отдельные файлы по мере роста. Еще есть файлы с описанием событий, заводов и т.д. Не уверен, что это правильный подход, но поскольку редактирую все вручную, по-другому сложно. Хотя и редактировать все вручную тоже неправильно, и с этим сейчас борюсь.)

Общий подход.

Самолеты группируются по серийными (серия-номер в серии) номерам. Соответственно, объединяются по заводам. Если идет сквозная нумерация по нескольким заводам, создается "виртуальный" завод. Также виртуальный завод создается. когда наперед неизвестно, на каком заводе был произведен самолет.

"Тип" в том смысле, по которому самолеты объединяются в файлы, объединяет самолеты сходной конструкции. Если нельзя четко различить самолеты, то они будут в одном файле. Если самолет является развитием другого, то тоже в одном файле. И, понятно дело, если общая система серийных номеров. Например, все МиГ-21, и наши, и китайские, и индийские в одном файле. Все истребители Як, которые от И-26 пошли тоже объединены. Смысл в том, что, например, если нашли разбитый Як, а точную марку не определили, то понятно, в какой файл писать об этом.

При использовании ссылок, информация дублируется текстом. О чем это я. Например, если самолет эксплуатировался Аэрофлотом, то ему ставится индекс Аэрофлота. В качестве индекса используется код ICAO - AFL. Но кроме этого пишется и текст: "ОАО "Аэрофлот - российские авиалинии". Причин тут несколько. Во-первых, более мощный контроль за отображением. Если есть текст, в таблице будет он, а если нет, то текст пойдет из базы авиакомпаний. Бывает удобно, когда под одним кодом летают разные отделения, например, или авиакомпания название поменяла, а код остался. Другое удобство - когда авиакомпании нет в базе (вообще код не ставится, только название) или эксплуатант является частным лицом (используется общий код "prvt").

Подход применяется не только для авиакомпаний, а для всего, на что идет ссылка. Таким образом реализуется в некоторой степени наследование.

Теперь собственно сама структура. Напишу только основные элементы с комментариями. Элемент может содержать свойства посредством текста, дочерних элементов и атрибутов. Каким образом это делается уточнять не буду, чтобы не загружать информацией. Уровень иерархии буду обозначать значками ">".


Общие элементы, которые много где встречаются.

имя Применяется для обозначения самолета, наименования заводов, авиакомпаний и пр. Может содержать указание на язык. Если указания на язык нет, то подразумевается, что это имя на родном языке.

описание Содержит в произвольной форме описание чего-либо: события, файла, предприятия. Если применяется к самолету, то кратко описывает то, чем самолет известен. Включает ссылку на язык, на котором написано.

источник Источник информации. Может включать ссылку в интернете, название на книгу, ссылку на источник из базы источников или ссылку на человека, от которого такая информация пришла. Вообще, очень важно хранить, откуда взята информация. А то потом приходится ломать голову, откуда пришло - действительно ли было, или, например, опечатка. Особенно важно, когда много людей могут редактировать.

Все ключевые элементы - самолет, производитель, тип и т.д. включают уникальный идентификатор.

> abaza - корневой элемент. Включает описание файла, номер версии и другую служебную информацию.

>> производитель - завод, выпустивший самолет. Может включать имя и описание.

>>> тип - тип самолета с точки зрения завода, не в том смысле, по которому самолеты группируются в файл. Разные типы определяются разными последовательностями серийных номеров. Например, в файле Ту-134 будет два типа: для гражданских и УБЛ один и для Ту-134Ш - другой, так как там своя нумерация.

>>>> серия - серия самолета. Включает номер серии и тип серии. В "синтетические" серии со своим специальным типом собираются самолеты у которых известны только регистрация и не идентифицированные самолеты.

>>>>> самолет. Вот наконец добрались и до самолета.) Практически все поля могут включать дату, определяющую, когда это имело место. Дата - это отдельный вопрос, так как четкая информация "от и до" бывает очень редко. Поэтому приходится в основном оперировать понятиями "на эту дату было" и "на эту дату не было". Но это если интересно будет, распишу.

>>>>>> описание и имя. И то, и другое, может быть несколько раз, из-за разных языков. А обозначение самолета может также меняться по ходу дела. Кроме того, у самолета может быть одновременно несколько обозначений. Если точное обозначение неизвестно, пишется примерное в квадратных скобках.

>>>>>> серийный номер. Оказалось, что и их может быть несколько, как у Ан-148. Еще бывает, что самолет переделывают, и он получает новый серийный номер. Случай тяжелый. Выхожу из положения тем, что "завершаю" старый самолет и "начинаю" новый.

>>>>>> заводской номер, Номер из формуляра. И их бывает несколько.

>>>>>> Еще бывают разные номера, вроде номера по радару, ЕЭВС и т.д.

>>>>>> регистрация - регистрационный номер. Это может быть государственный номер или тактический. Если тактический, то пишется еще и цвет. Если бывают разные, то пишется место расположения. Соответственно, номеров бывает много, к тому же они очень часто меняются с течением времени.

>>>>>> собственное имя - имя присвоенное самолету. Пишется точно, как на самолете. Если по левому борту и по правому написание разное, то разделяются значком "|".

>>>>>> титул - надпись на самолете. Вроде как ерунда, но, во-первых, для многих представляет интерес и, во-вторых, когда самолет не идентифицирован, такая информация часто позволяет его идентифицировать.Тоже делается различие для правого и левого борта. Еще пришлось вводить указание на размер надписи. А то смотришь на фото - надписи нет. Лезешь исправлять и видишь, что надпись эта идет как "tiny", то есть совсем крошечная. Присматриваешься - действительно есть. При необходимости указывается место расположения. А еще бывают надписи закрашенные и вообще самолеты без надписей. Это тоже важно, поэтому фиксируется.) Мелкие значки в надписях обозначаются "*", а большие - [* описание значка].

>>>>>> цвет - раскраска самолета. Может включать тип (белый, некрашенный, камуфляж и т.д.), ссылку на стандартную ливрею или описание.

>>>>>> двигатели - раздел, включающий информацию двигателях.

>>>>>>> двигатель - содержит и информация о конкретном двигателе: тип, заводской номер и т.д.

>>>>>> конструкция Этот раздел пока в разработке. Планирую ссылку на типовую конструкцию, описание, если есть отличия от типовой конструкции или типовой конструкции не существует. Также, наверное, стоит включить описание дополнительного оборудования.

>>>>>> сейчас - информация о текущем состоянии. Местоположение, статус (летает, испытывается, уничтожен, порезан и т.д,) и дату. Оказалось, что и этих полей может быть несколько. Во-первых, есть разная по значимости информация. Например, самолет летал, потом его не видели, а после обнаружили стоящим в непонятном состоянии. То есть есть четкая дата, когда он эксплуатировался и дата, когда он еще в какой-то степени живой. Обе эти даты представляют ценность. Другой вариант. Самолет порезали. Но его кабина используется как тренажер. Опять две даты выходит.

>>>>>> собственник - это понятно. Наименование или ФИО.

>>>>>> оператор Указывается код оператора, дата и место. Код оператора может быть "none", что означает, что самолет не эксплуатируется. Тогда в качестве места берется место стоянки, а в описании пишется что происходит (если известно). Если самолет эксплуатируется, то место - аэропорт базирования.

>>>>>> событие - включает дату, место, тип события, описание и источник информации. Тип – вариант из списка: завершение строительства, первый полет, обычный полет, авария, утилизация и т.д. Если события в списке нет, то тип не указывается. Фотография тоже идет как событие с типом "spot". В этом случае в источнике информации приводится ссылка(и) на фотографию и или страницу с фотографиями. Событие может включать и другое событие, если одно было во время другого. Например, самолет участвовал в МАКСе. В это время было сделано несколько фотографий. По большому счету, можно было бы вообще сделать одни события, а все остальное выводит через них. Но это потребовало бы очень продвинутой обработки.

>>>>>> история - развернутое описание биографии самолета. Внутри нее идет форматированный по правилам HTML текст.

>>>>>> источник информации - ссылки по общей информации о самолете.

>>>>>> комментарий – дополнительная информация, которую отображать не стоит, но и терять жалко. Например, чьи-то предположения. Да, и в таком поле возникла необходимость.)

Как-то так получилось. Конечно, всего много (четыре с лишним страниц Ворда), но и запросы у народа бывают самые разные. Одному интересно одно, другому – другое. По большому счету ничего особо сложного тут и нет. Надо только сделать правильную форму для внесения изменений. Точнее несколько - простую и сложную.
 
Покажите как вы это все храните. Что за xml

Я так понял что это чересчур сложно и сил моих не хватит. В виде текста можно было бы что то хранить, наверное, поиск же есть и может все найти по любым словам....
Короче, я знаю просто бд, в последние пару мес увлекся викидотом, знаю немного php, asp, и тд, но не представляю и близко то, как вы планируете поднять такого слона. Еще раз, мне кажется (осторожно так) что все можно сделать через одну запись "самолет" и связанную с ним коллекцию "история самолета". Поменял владельца - не беда. Пишем нового, добавляем запись в историю борта. То же самое с любыми другими изменениями и событиями в жизни. По моему так будет проще. Поиск тоже найдет запись "история" а там будет ссылка на то "чья это история то"
 
"прямого доступа к таблицам нет? " идея в том что таблицы БД могут лежать где то снаружи, а API используется для того чтобы генерировать текстовые страницы. У викидота нет чисто базы внутри - есть структуированные файлы которые хитро индексируются и работают как база для страниц, которые хотят показать скажем, все дочерние страницы или все "сестры" или се страницы с тегом "списан". все это можно, хотя и без БД, что само по сбе довольно круто на самом деле.
Педставьте что ваша таблица в бд - это папка на диске. А записи в таблице - это файлы в тапке. А поля в записи- это форматированный текст внутри файла. Так у них и устроено. И запросы довольно сложные могут быть - почитайте описание ListPages Module.
Специализированная большая БД может использоваться для генерации таких файлов, например. Или для показа налета по бортам.

Схема данных которая лежит на 1-й странице - это чисто для визуализации, это не реальная бд внутри, реально там уже сложнее стало, схемку обновлю. Мне как то не хочется навязывать такое решение - если есть что тотлучше - ради Бога - просто в последнее время возмлся именно с викидотом, сделал реестр джетов и подумал что это можно бы не погубить, но расширить на "все и вся". Получается что нельзя - вы хотите все очкнь очень и очень сложно ....
 
Последнее редактирование:
Создайте аккаунт на яндексе и все. Яндекс редко лежит. Только не создавайте ничего на радикале. Я обжегся. постепенно все переношу на сам сайт, затем буду на яндекс или еще какой-либо хостинг фотографий. Насчет правовых мер, просто указывайте коопирайт, есвли такой имеется.
 
timsz сказал(а):
А какие еще могут быть варианты?
Нажмите, чтобы раскрыть...
из совсем простых не скажу, но например, modx вполне мог бы справиться. Мы на нем сделали http://aviamuseum.ru/
Меню на самом сайте - это по сути варианты выборки из формуляров - либо по КБ, либо по годам. Поиск в modx можно настроить так, чтобы он искал только в определенном сегменте документов (скажем, в некоей папке). Поиск по тегам - запросто.
 
Стипан сказал(а):
Создайте аккаунт на яндексе и все.
Нажмите, чтобы раскрыть...
надо читать условия, вполне возможно, что ни Яндекс, ни Flickr не позволяют использовать собственные сервисы для автоматический публикации картинок, поэтому в один прекрасный день можно остаться без них вообще.
 
xoid, проще можно, олткрываете загруженное фото на отедльной странице и на сайте даете ссылку на нужное фото. Это к вопросу как можно сэкономить на хостинге, разместив фото на стороннем ресурсе.
 
sova сказал(а):
Покажите как вы это все храните. Что за xml
Нажмите, чтобы раскрыть...
Вот, например: http://abaza.ilisso.ru/ru_susj.xml

Там, в отличие от того, что я писал выше, вместо <abaza> идет <country>, и все типы одного завода сгруппированы в <prod>. Остальное, вроде, соответствует.

sova сказал(а):
Я так понял что это чересчур сложно и сил моих не хватит.
Нажмите, чтобы раскрыть...
Ну я тоже кое-что могу. И в принципе ничего более сложного, чем "История" там нет. Просто надо сделать много таких "историй", по каждому параметру.

Тут ведь такое дело. Вы делаете базу в том виде, как хотелось бы Вам. А кому-то хочется чего-то еще. А третьему - третье. Чтобы реестр был народным, надо чтобы он удовлетворял максимальное количество людей. Это не может быть очень просто.

Почти. У нас есть история владельцев. Добавился новый - делаем новую запись в историю. А так же история бортовых номеров, авиакомпаний, ливрей, событий и т.д. Когда выполняем поиск, просто просматриваем соответствующую историю.
А "XML версия схемы "? Она как-то используется?


Вообще, я тут пообщался с Гуглом и понял, что, похоже, сделать страницу, имея в основе БД файлы XML, не получится, для этого надо писать все самому. Может, я просто плохо искал. Получается, что в основе должен быть MySQL, и база, соответственно будет реляционной. Или что-то еще бывает?

Сейчас буду разбираться.

Уже большой реестр? Я вот уже думаю о том, что делать со своей базой - забить на нее или наладить импорт/экспорт как-нибудь. Все-таки использовать Вики очень заманчиво.)


---------- Добавлено в 19:59 ----------

А там можно запросы делать? И историю хранить? То, что на схеме, слишком просто.

Еще вопрос в движке. Таблицы могут быть под миллион записей. Тут нужна нормальная, мощная СУБД.

---------- Добавлено в 20:04 ----------

Тут вопрос не столько в том, где хранить, а как хранить. Ключевых фотографий не так много, можно и самому хостить. Но с каждой фотографией нужно описание с сайта, ссылка на оригинал и т. д. Вручную все делать довольно нудно, особенно, когда большой массив обрабатывается. А вот как-то автоматизировать сохранение и аннотацию - это было бы хорошо.

xoid сказал(а):
Flickr
Нажмите, чтобы раскрыть...
У него, вроде, вообще сейчас ограничение на объем?

Кстати, можно ведь и на Яндекс-диске выкладывать для общего обозрения? А там сейчас 8 гиг, если не больше.
 
Последнее редактирование:
Flickr очень удобен, хранит кучу разгых разрешений картинки, теги есть. Викидот с него автоматом показывает галереи. Права не нарушаются.

Timsz, xml - это просто описание того же что и на картинке, на случай если кто то захочет изменить схему и показать чего не хватает. Загоняешь в редактор типа Visual studio и вперед.
Я не знаю ни одной базы на основе xml. На обычных бд можно сделать почти все и опыт у меня большой но... Мне все же вики понравилась как то больше. Простотой и скоростью изменения, легкостью создания интерфейса и дизайнов и форм для ввода данных. Не хочется делать на БД то, что можно сделать без БД. Реляционная база имеет немало геморроев, и масштабируемость и прочее. Если уж заморачиваться таким - то тогда сразу в microsoft cloud - там тоже есть все и вся. Но... Это большое время, много сил и мало кто захочет что то программировать долго. А вот если проект растет сам по себе понемногу, как дерево, становясь все более полезным и интересным - люди тоже понемногу могут начать участвовать и в какой то момент - да - вики может не хватить - тогда в ход идет api. Не сочтите за навязчивость но я правда не знаю альтернатив; (предложенные выше по изучаю. )
 
Вам необходимо войти или зарегистрироваться, чтобы здесь отвечать.
Меню
Вход
Регистрация