VAR
Местный
Супер!
Еще бы динамические графики состояния ВС по годами в реестры ВС вернуть...
Реесторитарии всех стран!..
Еще бы динамические графики состояния ВС по годами в реестры ВС вернуть...
parfaits
Старожил
восстановлю, конечно, со временем
сейчас пытаюсь увязать реестр с иерархической структурой Аэрофлота (со всеми возможными переподчинениями ЛО) и с деревом авиакомпаний (что от чего произошло, когда и кем поглощено)
получается как-то так:
http://russianplanes.net/REGINFO/10201
---------- Добавлено в 17:19 ----------
по этому примеру - не соображу пока, как грамотно отобразить информацию о преобразованиях а/к вроде
1992/КомиАвиа -> 1999/КомиИнтерАвиа -> 2004/ЮТэйр Экспресс
сейчас пытаюсь увязать реестр с иерархической структурой Аэрофлота (со всеми возможными переподчинениями ЛО) и с деревом авиакомпаний (что от чего произошло, когда и кем поглощено)
получается как-то так:
http://russianplanes.net/REGINFO/10201
---------- Добавлено в 17:19 ----------
по этому примеру - не соображу пока, как грамотно отобразить информацию о преобразованиях а/к вроде
1992/КомиАвиа -> 1999/КомиИнтерАвиа -> 2004/ЮТэйр Экспресс
timsz
Старожил
Можно отобразить основание для передачи из одной компании в другую. Тогда преобразование будет помечено как "преобразование" или что-то в этом роде, и сразу будет понятно.
parfaits
Старожил
ещё одна доработка - уведомление о замеченных рейсах авиакомпании на ВС, не описанных в реестре
http://russianplanes.net/airline/Vostok
по дальневосточным бортам, к сожалению, всё попадается лишь эпизодически - бортовые получается брать только из а/п Хабаровска и Владивостока. Конечно, это крупнейшие порты региона, но всё равно не всё
http://russianplanes.net/airline/Vostok
по дальневосточным бортам, к сожалению, всё попадается лишь эпизодически - бортовые получается брать только из а/п Хабаровска и Владивостока. Конечно, это крупнейшие порты региона, но всё равно не всё
Последнее редактирование:
Micro
ШпиЁн
Включил Ще-2 в нашу базу данных.
Он-лайн будет только через месяц.
Он-лайн будет только через месяц.
Стипан
Старожил
Micro, посмотрел вроде у нас с Вами (команда СТ) в один один. Наконец-то дождался в Вашей базе этотго замечательного пепелаца.
http://aviahistory.ucoz.ru/index/reestr_shhe_2/0-193
Жду от Вас еще Як-6. Я его делал, но забросил. Думаю летом может доберусь. У меня еще в далеких планах Ер-2.
Какие еще интересные типы будете делать для СТ. СБ не планируете? Вроде ведь какие-то нароботки были уже у Вас с командой?
http://aviahistory.ucoz.ru/index/reestr_shhe_2/0-193
Жду от Вас еще Як-6. Я его делал, но забросил. Думаю летом может доберусь. У меня еще в далеких планах Ер-2.
Какие еще интересные типы будете делать для СТ. СБ не планируете? Вроде ведь какие-то нароботки были уже у Вас с командой?
Последнее редактирование:
Micro
ШпиЁн
Да, будут СБ, Г-1 и Г-2. Но когда, пока не знаю.
Команда этим старим железом вообще не интересуется, к сожалению.
Нашел еще один югославский Ще-2, с номером 50. Наверное, были и 51 по 53.
Последнее редактирование:
Стипан
Старожил
Micro, Можно вполне реально сделать и все АНТ-4, а не только Г-1. В книге Леннарта Андерсона "Советские Аэропланы 1917-1945" есть список первых 40 выпущенных АНТ-4.
А с СБ большие трудности. С нумерацией не разобраться. Не привязать к заводу изготовителю.
А с СБ большие трудности. С нумерацией не разобраться. Не привязать к заводу изготовителю.
Micro
ШпиЁн
Да, стараюсь сделать обзор по АНТ-4, не только по Г-1.
Кстати, Леннарт недавно разрешил нам публиковать его данные по Ли-2 в нашей базе данных.
Последнее редактирование:
Стипан
Старожил
Запретить он и не мог, после выхода своей книги. Просто надо обязательно указывать его как источник и никаких проблем не будет.
А по СБ ЕМНИП дробные номера были и на заводе №22. В этом и проблема.
Стипан
Старожил
Свершилось невероятное. Я наконец-то переборол свою лень. Подумал о здоровье любителей авиации.
Оранжевого сайта больше нет.
Добро пожаловать на новую версию: www.aviahistory.ucoz.ru
П.С. Сайт пока на глобальной реконструкции. Все исправляю постепенно.
Оранжевого сайта больше нет.
Добро пожаловать на новую версию: www.aviahistory.ucoz.ru
П.С. Сайт пока на глобальной реконструкции. Все исправляю постепенно.
sova
Старожил
очередная попытка http://airplanes.wikidot.com/register
плюсы: свободное членство, анонимные правки, очень просто все, народ так сказать, все сам занесёт. Есть локальный форум. Очень просто строить запросы к базе средней сложности типа "дай ка мне 787 для эфиопов". Есть коллекция авиакомпаний, типов, самолетов
Все очень просто с регистрацией, членством, паролями, комментариями, форумом, банами вандалов и прочее. все это сервисы викидота.
минусы - вики сайт - все же не база данных и некоторые сложные запросы возможны только путем добавления к странице т.н. "тегов", что не очень удобно.
вообщем, если охота обсуждать - вот я набросал схемку данных http://airplanes.wdfiles.com/local--files/start/schema1.JPG
плюсы: свободное членство, анонимные правки, очень просто все, народ так сказать, все сам занесёт. Есть локальный форум. Очень просто строить запросы к базе средней сложности типа "дай ка мне 787 для эфиопов". Есть коллекция авиакомпаний, типов, самолетов
Все очень просто с регистрацией, членством, паролями, комментариями, форумом, банами вандалов и прочее. все это сервисы викидота.
минусы - вики сайт - все же не база данных и некоторые сложные запросы возможны только путем добавления к странице т.н. "тегов", что не очень удобно.
вообщем, если охота обсуждать - вот я набросал схемку данных http://airplanes.wdfiles.com/local--files/start/schema1.JPG
Стипан
Старожил
редактирование многими пользователями, что приведет к ошибкам
---------- Добавлено в 20:38 ----------
П.С. У себя на сайте решил, что будет удаление всех реестров военных ЛА. Причина отсутсвие сил и абсурдность реестров прототипов военных летательных аппаратов, т.к. все известные монографии заменяют эти реестры. Поэтому прошу, кому это надо сохраняйте, то через неделю уберу...
---------- Добавлено в 20:38 ----------
П.П.С. Гражданские прототипы останутся.
sova
Старожил
ну... редактирование одним пользователем может привести к еще бОльшим ошибкам. Вики подразумевает проверку данных несколькими людьми, и обсуждение - если не согласны. А один человек - может заболеть, ошибиться, умереть, простите, в конце концов. Все же лучше иметь коллективный проект.
тем более история всех изменений - в вики сохраняется и всегда можно откатиться на более старую версию
скажем я пробовал несколько раз исправить ошибки на реестре руссианпланес. Премодерация раздражает тем, что не видишь результата. пришел через несколько дней - всё что вносил - было отменено их модератором без указания причин и без обсуждения. Не говоря уже о том что на том сайте месяцами можете висеть устаревшая информация и её некому исправить - опять же пресловутая премодерация.
З.Ы. только что научился очень элегантному способу ввода типа самолета (или двигателя) в викисайт - будет очень красиво, просто и с минимумом ошибок: человек выбирает сначала производителя, потом тип от этого производителя, потом модификацию этого типа от этого производителя. Короче, как и должно быть. Раньше типы были одним большим списком а модификации приходилось набивать в виде текста. Вообщем, без базы данных получается древесная структура, очень красиво и просто...
Стипан
Старожил
sova, пытался ввести Ту-124. Итог. Сначало ошибка на загрузку фото (нужна регистрация). В результате тип, эксплуатант сохранился как Airbus и Россия. Пытался отредактировать ничего не произошло.
Поправте на этой записи тип на "Туполев Ту-124", Двигатели на "Соловьев Д-20П", Эксплуатант на СССР, МГА (Аэрофлот).
Поправте на этой записи тип на "Туполев Ту-124", Двигатели на "Соловьев Д-20П", Эксплуатант на СССР, МГА (Аэрофлот).
sova
Старожил
Стипан, дело в том, что если в выпадающем списке нет нужного значения, то нужно
1. Выбрать create new
2. Написать нужный текст
3. Нажать Enter (обязательно! Иначе не сохранится)
И все.
Фото наверное только по регистрации (занимает минуту)
Спасибо за попытку сломать сайт
1. Выбрать create new
2. Написать нужный текст
3. Нажать Enter (обязательно! Иначе не сохранится)
И все.
Фото наверное только по регистрации (занимает минуту)
Спасибо за попытку сломать сайт
Стипан
Старожил
не было даже таких мыслей.
timsz
Старожил
По четырехлетнему опыту систематизации информации по всем российско-советским самолетам все оказывается совсем непросто, как кажется на первый взгляд.
Первое, что надо для себя определить - это объем собираемой информации. Одно дело просто перечислить основные самолеты с основными параметрами, другое - собирать всю информацию, которая может представлять интерес. Это и совершенно разные объемы, и совершенно разные структуры данных. Просто перечислить все, что можно, ИМХО, не очень интересно. Это в той или иной степени уже сделано.
Интереснее иметь возможность хранить различные факты биографии самолета, фотографии, истории и т.д. Кроме того, отдельный, но перекликающийся с этим вопрос - заниматься ли поиском и восстановлением информации. То есть, можно просто фиксировать самолеты, о которых все известно, "идентифицированные" самолеты. А можно собирать данные и по не идентифицированным машинам, чтобы потом понять, кто есть кто.
Второе - это, действительно, кто занимается наполнением сайта. Я тоже прихожу к выводу, что одиночку это сделать невозможно. Самое обидное это то, что очень много людей, которым есть, что сказать, проходит мимо. Я сейчас как раз занимаюсь тем, чтобы обеспечить простой доступ к внесению изменений в базу. Тут надо найти золотую середину между простотой и надежностью. Согласен, что встроенный в Вики механизм редактирования очень грамотный, и изобретение чего-то своего нового напоминает изобретение велосипеда. Но возникает вопрос, можно ли при этом хранить данные в удобной для обработки форме?
Можно, конечно, сделать просто табличку в интернете, но, как мне кажется, правильнее хранить все в базе данных, доступ к которой могут иметь и другие приложения. Это сразу существенно повышает ценность информации, так как ее можно использовать в исследованиях, анализировать, обрабатывать и т.д. Кроме того, по базам данным проще организовать поиск, притом сделать его можно любой сложности. Через базу данных можно подключаться к другим базам. Например, уже на подходе замечательная база по конструкциям самолетов, которую делает Бурундук. Делать в такой ситуации свою базу, проигнорировав многолетний труд, как-то совсем неразумно. Наоборот, возможность использования других наработок сразу поднимет ценность и нашей, народной базы.
Позволяет ли Вики помещать данные сразу в базу данных? Если нет, то, думаю, можно сделать какой-нибудь инструментарий, с помощью которого можно периодически сохранять данные из Вики в базу и, наоборот, экспортировать из базы в Вики.
Теперь о базе данных. Она может быть иерархической или реляционной. Реляционная база данных хранит информацию в таблице, иерархическая в виде древовидных структур. В своей базе я выбрал в качестве основы XML - храню информацию в виде деревьев. Достоинство - вся информация локализована в одном месте, ее можно видеть сразу без построения сложных запросов. Недостаток - более сложный поиск по деревьям. Другие достоинства XML - это текстовый вид, а значит простая переносимость, интеграция в Интернет и поддержка огромным количеством приложений, в том числе разными Офисами.
Выбор между иерархической и реляционной базой данных - это фактически выбор между сложностью данных и сложностью базы. У иерархической базы непостоянная, изменчивая структура, а у реляционной - огромное количество таблиц, часто нелогичных, что влечет требования введение кучи дополнительных полей индексов. Из этого вытекает еще одно немаловажное, особенно на начальном этапе достоинство иерархических баз - простота модернизации структуры данных. Если для реляционной базы данных введение новых полей может повлечь переделку всей базы, то для иерархической в основном обходится просто изменением описания структуры. Из этого вытекает и хорошая совместимость разных версий.
Чтобы было понятно, какая структура получается у реляционных баз данных, пробегусь по схемке
"Производители". Тут надо понимать, что "Ту", "Ан" "Боинг" и т.д. - это не совсем производители. Это скорее разработчики. Вообще, вначале надо ответить на вопрос, как самолеты будут группироваться в базе. Я пришел к выводу, что удобнее это делать по серийным (те, которые в ST называются "линейными") номерам. Но серийные номера часто привязываются к заводу, а не к производителю. Например, номера Ту-104 и Ан-12. Или взять, например, номера Ан-148. Там есть номера ВАСО, Авианта, да еще и заводской номер ВАСО. Как их лучше группировать - так до сих пор до конца не решил, группирую по авиантовским. Еще производитель может меняться. Например, был Дуглас, стал Боинг. Тут тоже должно все быть правильно.
"Типы" и "Модификации". Это вообще отдельная песня. Первое - их общем случае нельзя ассоциировать с обозначением самолета, особенно в СССР. Например, Су-7/Су-17. Разные типы или одни? Изначально Су-17 - глубокая модернизация Су-7, что даже в заводских номерах нашло отражение - номера Су-17 продолжали номера Су-7. Но потом он все дальше и дальше отходит от исходной модели, и использует несколько последовательностей заводских номеров, хотя и выпускается на одном заводе. Другая проблема - это сбор информации о неидентифицированных самолетах. Например, появилась какая-то информация об И-16. А каждый тип И-16 - это разный тип Горьковского завода (откуда, собственно слово "тип" и пошло). То есть, надо создавать еще искусственный тип "И-16 вообще", куда помещать информацию о неидентифицированных самолетах.
"Но и это еще не все". С 99% самолетов особых проблем не будет, но если уж требуется структура отражающая все 100%, то... Тем более, что этот 1% часто оказывается самым интересным. Я о том, что практически все характеристики самолета могут изменяться с течением времени. В том числе и его тип. Самолет могут банально переделать в другой. Поэтому структура данных "Самолеты" в представленном виде работать не может. Должна добавиться таблица соответствия между Id самолета, Id типа и Id модификации. Плюс информация о времени существования.
И так практически по всем пунктам таблицы "Самолеты". У самолета может быть несколько обозначений, заводских номеров, дат первого полета (кстати, я храню их, как одни из событий истории), салонов, не говоря уже об смене авиакомпаний, собственников, регистрационных номеров, ливрей, титулов и т.д.
Авиакомпании тоже, кстати, вещь очень изменчивая, особенно при наличии разных лизинговых схем. С регистрационными номерами... Ох... На крыле одни, на хвосте другие, на правом щитке шасси третьи, а в документах четвертые... Двигатели тоже могут меняться, и бывают самолеты у которых одновременно разные двигатели стоят.
В общем... Если выбирать реляционные базы данных, то надо быть готовым к тому, что будет большое количество связывающих таблиц (у Бурундука таблиц под две сотни, если не ошибаюсь), работать с которым можно только через СУБД. В этом отношении иерархические базы гораздо проще, так как там все скомпоновано в одном месте.
Короче.
Давайте проект развивать. Собираем инициативную группу и делаем "Народный авиареестр". Кто записывает?)
ЗЫ. Насколько помню, был зарегистрирован домен aviaregister.ru. Он еще жив?
---------- Добавлено в 17:45 ----------
Жалко. Может, сделать раздел (типа "Архив") куда переносить необновляемые типы? Если все-таки решите удалять, не будет ли сложно все это собрать и скинуть?
Первое, что надо для себя определить - это объем собираемой информации. Одно дело просто перечислить основные самолеты с основными параметрами, другое - собирать всю информацию, которая может представлять интерес. Это и совершенно разные объемы, и совершенно разные структуры данных. Просто перечислить все, что можно, ИМХО, не очень интересно. Это в той или иной степени уже сделано.
Интереснее иметь возможность хранить различные факты биографии самолета, фотографии, истории и т.д. Кроме того, отдельный, но перекликающийся с этим вопрос - заниматься ли поиском и восстановлением информации. То есть, можно просто фиксировать самолеты, о которых все известно, "идентифицированные" самолеты. А можно собирать данные и по не идентифицированным машинам, чтобы потом понять, кто есть кто.
Второе - это, действительно, кто занимается наполнением сайта. Я тоже прихожу к выводу, что одиночку это сделать невозможно. Самое обидное это то, что очень много людей, которым есть, что сказать, проходит мимо. Я сейчас как раз занимаюсь тем, чтобы обеспечить простой доступ к внесению изменений в базу. Тут надо найти золотую середину между простотой и надежностью. Согласен, что встроенный в Вики механизм редактирования очень грамотный, и изобретение чего-то своего нового напоминает изобретение велосипеда. Но возникает вопрос, можно ли при этом хранить данные в удобной для обработки форме?
Можно, конечно, сделать просто табличку в интернете, но, как мне кажется, правильнее хранить все в базе данных, доступ к которой могут иметь и другие приложения. Это сразу существенно повышает ценность информации, так как ее можно использовать в исследованиях, анализировать, обрабатывать и т.д. Кроме того, по базам данным проще организовать поиск, притом сделать его можно любой сложности. Через базу данных можно подключаться к другим базам. Например, уже на подходе замечательная база по конструкциям самолетов, которую делает Бурундук. Делать в такой ситуации свою базу, проигнорировав многолетний труд, как-то совсем неразумно. Наоборот, возможность использования других наработок сразу поднимет ценность и нашей, народной базы.
Позволяет ли Вики помещать данные сразу в базу данных? Если нет, то, думаю, можно сделать какой-нибудь инструментарий, с помощью которого можно периодически сохранять данные из Вики в базу и, наоборот, экспортировать из базы в Вики.
Теперь о базе данных. Она может быть иерархической или реляционной. Реляционная база данных хранит информацию в таблице, иерархическая в виде древовидных структур. В своей базе я выбрал в качестве основы XML - храню информацию в виде деревьев. Достоинство - вся информация локализована в одном месте, ее можно видеть сразу без построения сложных запросов. Недостаток - более сложный поиск по деревьям. Другие достоинства XML - это текстовый вид, а значит простая переносимость, интеграция в Интернет и поддержка огромным количеством приложений, в том числе разными Офисами.
Выбор между иерархической и реляционной базой данных - это фактически выбор между сложностью данных и сложностью базы. У иерархической базы непостоянная, изменчивая структура, а у реляционной - огромное количество таблиц, часто нелогичных, что влечет требования введение кучи дополнительных полей индексов. Из этого вытекает еще одно немаловажное, особенно на начальном этапе достоинство иерархических баз - простота модернизации структуры данных. Если для реляционной базы данных введение новых полей может повлечь переделку всей базы, то для иерархической в основном обходится просто изменением описания структуры. Из этого вытекает и хорошая совместимость разных версий.
Чтобы было понятно, какая структура получается у реляционных баз данных, пробегусь по схемке
Заодно, поделюсь опытом, какие сложности вообще предстоит преодолевать.
"Производители". Тут надо понимать, что "Ту", "Ан" "Боинг" и т.д. - это не совсем производители. Это скорее разработчики. Вообще, вначале надо ответить на вопрос, как самолеты будут группироваться в базе. Я пришел к выводу, что удобнее это делать по серийным (те, которые в ST называются "линейными") номерам. Но серийные номера часто привязываются к заводу, а не к производителю. Например, номера Ту-104 и Ан-12. Или взять, например, номера Ан-148. Там есть номера ВАСО, Авианта, да еще и заводской номер ВАСО. Как их лучше группировать - так до сих пор до конца не решил, группирую по авиантовским. Еще производитель может меняться. Например, был Дуглас, стал Боинг. Тут тоже должно все быть правильно.
"Типы" и "Модификации". Это вообще отдельная песня. Первое - их общем случае нельзя ассоциировать с обозначением самолета, особенно в СССР. Например, Су-7/Су-17. Разные типы или одни? Изначально Су-17 - глубокая модернизация Су-7, что даже в заводских номерах нашло отражение - номера Су-17 продолжали номера Су-7. Но потом он все дальше и дальше отходит от исходной модели, и использует несколько последовательностей заводских номеров, хотя и выпускается на одном заводе. Другая проблема - это сбор информации о неидентифицированных самолетах. Например, появилась какая-то информация об И-16. А каждый тип И-16 - это разный тип Горьковского завода (откуда, собственно слово "тип" и пошло). То есть, надо создавать еще искусственный тип "И-16 вообще", куда помещать информацию о неидентифицированных самолетах.
"Но и это еще не все". С 99% самолетов особых проблем не будет, но если уж требуется структура отражающая все 100%, то... Тем более, что этот 1% часто оказывается самым интересным. Я о том, что практически все характеристики самолета могут изменяться с течением времени. В том числе и его тип. Самолет могут банально переделать в другой. Поэтому структура данных "Самолеты" в представленном виде работать не может. Должна добавиться таблица соответствия между Id самолета, Id типа и Id модификации. Плюс информация о времени существования.
И так практически по всем пунктам таблицы "Самолеты". У самолета может быть несколько обозначений, заводских номеров, дат первого полета (кстати, я храню их, как одни из событий истории), салонов, не говоря уже об смене авиакомпаний, собственников, регистрационных номеров, ливрей, титулов и т.д.
Авиакомпании тоже, кстати, вещь очень изменчивая, особенно при наличии разных лизинговых схем. С регистрационными номерами... Ох... На крыле одни, на хвосте другие, на правом щитке шасси третьи, а в документах четвертые... Двигатели тоже могут меняться, и бывают самолеты у которых одновременно разные двигатели стоят.
В общем... Если выбирать реляционные базы данных, то надо быть готовым к тому, что будет большое количество связывающих таблиц (у Бурундука таблиц под две сотни, если не ошибаюсь), работать с которым можно только через СУБД. В этом отношении иерархические базы гораздо проще, так как там все скомпоновано в одном месте.
Короче.
Давайте проект развивать. Собираем инициативную группу и делаем "Народный авиареестр". Кто записывает?)
ЗЫ. Насколько помню, был зарегистрирован домен aviaregister.ru. Он еще жив?
---------- Добавлено в 17:45 ----------
Жалко. Может, сделать раздел (типа "Архив") куда переносить необновляемые типы? Если все-таки решите удалять, не будет ли сложно все это собрать и скинуть?
sova
Старожил
Давайте я поделюсь тем, чем научился в посл время повозившись с викидотом. Во первых, вики сайт - это прежде всего удобное редактирование текстов(данных) любым человеком вплоть до анонимов, но в то же время коллективный надзор над изменениями и простота отката к предидущей версии - то есть легкость борьбы с вандализмом. Это плюс.
Сам викидот по простоте редактирования и функционалу - на голову выше той же обычной википедии. Хотя бы потому что у них есть такое понятие как "модули". Например, модуль tree может рисовать древесную схему сайта, галерея - фото показывать, а модуль listpages делать практически запросы к базе данных.
Теперь о базе. На тестовом проектике airplanes.wikidot.com есть И древесное хранение данных - (производитель-тип-модификация), и реляционное. Прикол в том, что данные о самолете редактируются в виде удобной формы И поля этой же формы используюся для составления запросов к базе. То есть викидот - это практически база данных с возможностью построения жовольно сложных запросов, в то же время - данные хранятся в виде простых текстовых файлов.
Кстати я уже реализовал ту схему базы что я нарисовал чуть выше. За пару часов и без собственно базы данных как таковой.
Не надо быть меша программистом чтобы исправить этот вики код или понять что изменилось.
Не надо писать интерфейс-страниц к базе данных. Вообщем, мне ннраится такая простота.
Допустим, с помощью listpages можно делать запросы типа "покажи все самолеты в данной ак" или "покажи все б737". Для более сложных вещей есть "теги" то есть к странице можно добавить любой тег и потом делать запросы типа "дай мне все с тегом ХУZ"
На случай же если надо что то Очень хитрое сделать - в викидоте есть API вход - то есть внешняя программа скаже на питоне или java может сгенерироватьь страницы или части страниц (без дизайна, только данные). То есть перекачать вики сайт в обычную БД если надо. или обратно.
В сайте важно еще удобство администрирования, настройка прав на то кто и что может или не может менять, а так же вспомогательные вещи типа возможности комментирования страниц, форум, удобный и быстрый поиск внутри сайта и пр и пр. Удобство добавления файлов на сайт. Удобство удаления /переименования страниц. Что бы никаких FTP доступов и проблем с тем "кому же доверить пароль". Сайт должен удобно просто бакапится и восстанавливаться в другом месте на случай катастрофы (тут у викидота тоже все пучком)
По поводу изменений - я думаю надо или вести "историю изменений" - или просто записать в виде текста. То же по поводу регистрационного номера - перечислить их всех в описании самолета. Кому надо - прочтет; поиск внутри сайта и гугл - все найдут. Ах, да. Сайт должен быть дружелюбным к поисковикам, плохо настроенные страницы - не будут попадать в результаты поиска гуглом, что снижает их ценность. Скажем, один и тот же текст лежит на викидоте и на форуме авиапорта. В первом случае гугл текст находит по ключевому слову показывает в первых позициях, во втором - может вообще не найти и уж точно никогда почти не покажет в первых страницах результатов поиска...
Еще раз- 100-200 таблиц реляционной БД - это неподьемное дело для одного, и очень сложно разобраться тому, кто смотрит со стороны, а не разработчик. Так как за народный реестр з/п никому не платят - то он должен быть не сложным в понимании. Чем проще будет - тем больше людей захотят внести всой вклад. Тем более авиационные люди в массе не программисты. Да и у всех проблемы со временем - по этому чем проще - тем лучше, пмсм
З.ы. Кстати, опять о викидоте - внутри сайт может быть викидотом, а снаружи у него может быть адрес типа aviaregister.ru.
Еще раз, пока я не видел конечно альтернатив, но вики-сайт мне нравится. есть ли лучший движок для коллективного проекта? Программировать очень неохота - некогда - и полагаться на закрытый чей то код - тем более не хотелось бы.
---------- Добавлено в 08:01 ----------
К вопросу изменчивости АК: посмотрите как сделан ввод "истории борта скажем тут: http://airplanes.wikidot.com/plane:sssr-45014
За 5 минут такую же историю можно прикрутить и к АК. А лучше просто в описанииранить текстом- типа раньше называлась так то а еще раньше - так то.
Все должно быть как можно проще и в редактировании и в понимании со стороны, даже ценой потери части функциональности (тот самый 1% сложных случаев - должен решаться в виде простого текста - для начала, а потом уже коллективным разумом текст может перерасти в структурированную бд, Если Это Будет Надо).
Сам викидот по простоте редактирования и функционалу - на голову выше той же обычной википедии. Хотя бы потому что у них есть такое понятие как "модули". Например, модуль tree может рисовать древесную схему сайта, галерея - фото показывать, а модуль listpages делать практически запросы к базе данных.
Теперь о базе. На тестовом проектике airplanes.wikidot.com есть И древесное хранение данных - (производитель-тип-модификация), и реляционное. Прикол в том, что данные о самолете редактируются в виде удобной формы И поля этой же формы используюся для составления запросов к базе. То есть викидот - это практически база данных с возможностью построения жовольно сложных запросов, в то же время - данные хранятся в виде простых текстовых файлов.
Кстати я уже реализовал ту схему базы что я нарисовал чуть выше. За пару часов и без собственно базы данных как таковой.
Не надо быть меша программистом чтобы исправить этот вики код или понять что изменилось.
Не надо писать интерфейс-страниц к базе данных. Вообщем, мне ннраится такая простота.
Допустим, с помощью listpages можно делать запросы типа "покажи все самолеты в данной ак" или "покажи все б737". Для более сложных вещей есть "теги" то есть к странице можно добавить любой тег и потом делать запросы типа "дай мне все с тегом ХУZ"
На случай же если надо что то Очень хитрое сделать - в викидоте есть API вход - то есть внешняя программа скаже на питоне или java может сгенерироватьь страницы или части страниц (без дизайна, только данные). То есть перекачать вики сайт в обычную БД если надо. или обратно.
В сайте важно еще удобство администрирования, настройка прав на то кто и что может или не может менять, а так же вспомогательные вещи типа возможности комментирования страниц, форум, удобный и быстрый поиск внутри сайта и пр и пр. Удобство добавления файлов на сайт. Удобство удаления /переименования страниц. Что бы никаких FTP доступов и проблем с тем "кому же доверить пароль". Сайт должен удобно просто бакапится и восстанавливаться в другом месте на случай катастрофы (тут у викидота тоже все пучком)
По поводу изменений - я думаю надо или вести "историю изменений" - или просто записать в виде текста. То же по поводу регистрационного номера - перечислить их всех в описании самолета. Кому надо - прочтет; поиск внутри сайта и гугл - все найдут. Ах, да. Сайт должен быть дружелюбным к поисковикам, плохо настроенные страницы - не будут попадать в результаты поиска гуглом, что снижает их ценность. Скажем, один и тот же текст лежит на викидоте и на форуме авиапорта. В первом случае гугл текст находит по ключевому слову показывает в первых позициях, во втором - может вообще не найти и уж точно никогда почти не покажет в первых страницах результатов поиска...
Еще раз- 100-200 таблиц реляционной БД - это неподьемное дело для одного, и очень сложно разобраться тому, кто смотрит со стороны, а не разработчик. Так как за народный реестр з/п никому не платят - то он должен быть не сложным в понимании. Чем проще будет - тем больше людей захотят внести всой вклад. Тем более авиационные люди в массе не программисты. Да и у всех проблемы со временем - по этому чем проще - тем лучше, пмсм
З.ы. Кстати, опять о викидоте - внутри сайт может быть викидотом, а снаружи у него может быть адрес типа aviaregister.ru.
Еще раз, пока я не видел конечно альтернатив, но вики-сайт мне нравится. есть ли лучший движок для коллективного проекта? Программировать очень неохота - некогда - и полагаться на закрытый чей то код - тем более не хотелось бы.
---------- Добавлено в 08:01 ----------
К вопросу изменчивости АК: посмотрите как сделан ввод "истории борта скажем тут: http://airplanes.wikidot.com/plane:sssr-45014
За 5 минут такую же историю можно прикрутить и к АК. А лучше просто в описанииранить текстом- типа раньше называлась так то а еще раньше - так то.
Все должно быть как можно проще и в редактировании и в понимании со стороны, даже ценой потери части функциональности (тот самый 1% сложных случаев - должен решаться в виде простого текста - для начала, а потом уже коллективным разумом текст может перерасти в структурированную бд, Если Это Будет Надо).