От Seeker Ответить на сообщение
К deruluft Ответить по почте
Дата 12.09.2006 13:18:57 Найти в дереве
Рубрики Прочее; Люди и авиация; Авиатехника; Версия для печати

Не согласен...

>1. В каком формате (excel, dbf, access, oracle, ...) делать базу совершенно неважно.

Важно, в противном случае, будет трудно (или потребует каких-то усилий) перенести ее на другую платформу. Неважно с чем это будет связано - объединение проектов, смена СУБД и т.п.

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

Нет, БАЗЫ должны быть реаляционными, связанные друг с другом. Другое дело КАК и КАКИЕ назначить ключи. Кстати, то что ты пишешь, как раз и есть предлагаемое мной разбиение одной базы на несколько (таблицы, как ты их именуешь). Что получим - есть несколько БД, связанных между собой. Возникла необходимость в одной из них ввести новые поля - пожалуйста, вводи, главное, чтобы связи не затрагивало. Короче, чего я распинаюсь - нормализация БД это называется.

>3. База должна проектироваться с учетом ее возможного on-line существования.

Да, "клиент-сервер", поэтому, нужно сразу договариваться в каком формате делать.

>4. База должна быть многопользовательской, это значит, что инфромация может дополняться большим числом пользователей, и как следствие может быть неверной (случайно или намеренно). Это значит, что база должна хранить историю изменений с возможностью отката либо сортировки по источнику информации.

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

Естественно, надо понимать, что желающих поместить результаты своих исследований на всеобщее (опять же, можно ограничить доступ к ряду записей) обозрение найдется крайне мало, если вообще таковые будут. Но дело не в этом, задача стоит выработать единые требования (и возможно, частично реализация) к БД. А работать можно будет, как с локальной БД со своими наработками, так и с общей.

Хотелось бы чтобы этим занялись профессиональные разработчики, пусть и за деньги, чем страдать от любительских "косяков".