По четырехлетнему опыту систематизации информации по всем российско-советским самолетам все оказывается совсем непросто, как кажется на первый взгляд.
Первое, что надо для себя определить - это объем собираемой информации. Одно дело просто перечислить основные самолеты с основными параметрами, другое - собирать всю информацию, которая может представлять интерес. Это и совершенно разные объемы, и совершенно разные структуры данных. Просто перечислить все, что можно, ИМХО, не очень интересно. Это в той или иной степени уже сделано.
Интереснее иметь возможность хранить различные факты биографии самолета, фотографии, истории и т.д. Кроме того, отдельный, но перекликающийся с этим вопрос - заниматься ли поиском и восстановлением информации. То есть, можно просто фиксировать самолеты, о которых все известно, "идентифицированные" самолеты. А можно собирать данные и по не идентифицированным машинам, чтобы потом понять, кто есть кто.
Второе - это, действительно, кто занимается наполнением сайта. Я тоже прихожу к выводу, что одиночку это сделать невозможно. Самое обидное это то, что очень много людей, которым есть, что сказать, проходит мимо. Я сейчас как раз занимаюсь тем, чтобы обеспечить простой доступ к внесению изменений в базу. Тут надо найти золотую середину между простотой и надежностью. Согласен, что встроенный в Вики механизм редактирования очень грамотный, и изобретение чего-то своего нового напоминает изобретение велосипеда. Но возникает вопрос, можно ли при этом хранить данные в удобной для обработки форме?
Можно, конечно, сделать просто табличку в интернете, но, как мне кажется, правильнее хранить все в базе данных, доступ к которой могут иметь и другие приложения. Это сразу существенно повышает ценность информации, так как ее можно использовать в исследованиях, анализировать, обрабатывать и т.д. Кроме того, по базам данным проще организовать поиск, притом сделать его можно любой сложности. Через базу данных можно подключаться к другим базам. Например, уже на подходе замечательная база по конструкциям самолетов, которую делает Бурундук. Делать в такой ситуации свою базу, проигнорировав многолетний труд, как-то совсем неразумно. Наоборот, возможность использования других наработок сразу поднимет ценность и нашей, народной базы.
Позволяет ли Вики помещать данные сразу в базу данных? Если нет, то, думаю, можно сделать какой-нибудь инструментарий, с помощью которого можно периодически сохранять данные из Вики в базу и, наоборот, экспортировать из базы в Вики.
Теперь о базе данных. Она может быть иерархической или реляционной. Реляционная база данных хранит информацию в таблице, иерархическая в виде древовидных структур. В своей базе я выбрал в качестве основы 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 ----------
П.С. У себя на сайте решил, что будет удаление всех реестров военных ЛА. Причина отсутсвие сил и абсурдность реестров прототипов военных летательных аппаратов, т.к. все известные монографии заменяют эти реестры. Поэтому прошу, кому это надо сохраняйте, то через неделю уберу...
Жалко. Может, сделать раздел (типа "Архив") куда переносить необновляемые типы? Если все-таки решите удалять, не будет ли сложно все это собрать и скинуть?