От deruluft
К SK
Дата 12.09.2006 11:58:03
Рубрики Прочее; Люди и авиация; Авиатехника;

пара мыслей

1. В каком формате (excel, dbf, access, oracle, ...) делать базу совершенно неважно.
2. База не должна быть реляционной, то есть она не должна состоять из связанных ссылками таблиц. Она должна состоять из независимых друг от друга таблиц, которые могут быть связаны по единым идентификаторам. Нужно все это для того, чтобы база могла быть легко дополнена новыми данными, или наоборот разбита на части.
3. База должна проектироваться с учетом ее возможного on-line существования.
4. База должна быть многопользовательской, это значит, что инфромация может дополняться большим числом пользователей, и как следствие может быть неверной (случайно или намеренно). Это значит, что база должна хранить историю изменений с возможностью отката либо сортировки по источнику информации.
От SK
К deruluft (12.09.2006 11:58:03)
Дата 12.09.2006 15:46:45

Re: пара мыслей

>2. База не должна быть реляционной, то есть она не должна состоять из связанных ссылками таблиц. Она должна состоять из независимых друг от друга таблиц, которые могут быть связаны по единым идентификаторам. Нужно все это для того, чтобы база могла быть легко дополнена новыми данными, или наоборот разбита на части.
Единственными связующими звеньями, позволяющими много вариантность нашей базы могут быть:
а) воинская часть, подразделение;
б) тип самолета.
Остальные кусочки базы заполняются в связи с этими ключами (справочниками) различными формализированными документами (акт потери или списания), карточка самолета (мотора), оперсводка, донесение о ремонте и т.д.
СК
От Seeker
К deruluft (12.09.2006 11:58:03)
Дата 12.09.2006 13:18:57

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

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

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

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

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

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

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

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

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

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

Хотелось бы чтобы этим занялись профессиональные разработчики, пусть и за деньги, чем страдать от любительских "косяков".
От SK
К Seeker (12.09.2006 13:18:57)
Дата 12.09.2006 15:56:19

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

>>4. База должна быть многопользовательской, это значит, что инфромация может дополняться большим числом пользователей, и как следствие может быть неверной (случайно или намеренно). Это значит, что база должна хранить историю изменений с возможностью отката либо сортировки по источнику информации.
>Естественно, надо понимать, что желающих поместить результаты своих исследований на всеобщее (опять же, можно ограничить доступ к ряду записей) обозрение найдется крайне мало, если вообще таковые будут. Но дело не в этом, задача стоит выработать единые требования (и возможно, частично реализация) к БД. А работать можно будет, как с локальной БД со своими наработками, так и с общей.
>Хотелось бы чтобы этим занялись профессиональные разработчики, пусть и за деньги, чем страдать от любительских "косяков".
Если это будет заказной программный продукт, то есть вполне реальная возможность его последующей реализации с какой-то степенью защиты (эл.ключ на комп) и, соответственно, подписки на обновления базы, распространяемой через сеть. Это подпитка для тех, кто будет базу строить.
Владельцам права на использовние локальной копии, при их желании дополнить базу своими наработками, можно будет делать скидки.
Еще договоры с конечными владельцами оригинальных фото (негативов), схем окраски, чертежей на их тиражирование, раз уж этот раздел будет присутствовать в базе.
СК
От deruluft
К SK (12.09.2006 15:56:19)
Дата 12.09.2006 16:11:35

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

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

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

>Владельцам права на использовние локальной копии, при их желании дополнить базу своими наработками, можно будет делать скидки.
Никаких локальных копий :). Но активным пользователям, и владельцам информации - скидка.
От SK
К deruluft (12.09.2006 16:11:35)
Дата 12.09.2006 16:47:33

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

>>>Естественно, надо понимать, что желающих поместить результаты своих исследований на всеобщее (опять же, можно ограничить доступ к ряду записей) обозрение найдется крайне мало, если вообще таковые будут. Но дело не в этом, задача стоит выработать единые требования (и возможно, частично реализация) к БД. А работать можно будет, как с локальной БД со своими наработками, так и с общей.
>Нет, "экономическая модель", может быть другая:
>- все база никому не передается (не существует локальных копий);
>- экспорт всех данных пользователем невозможен;
>- пользователь оплачивает подписку
>- контроль за авторами, использующими базу (мы же попутно и журналы/газеты/книги читаем и заносим :). Ссылка на базу обязательна :). Использовал, но не платил - отключаем нафиг.
Имейте в виду, что эта база данных весьма специфический продукт и число ее активных пользователей будет небольшим (меньше, чем у авиационных журналов на порядок, а то и на два). То есть ломать и выкладывать как остальные базы на прилавок - на такой уж выгодный бизнес.
Мне, допустим, неприятна (на данном этапе развития IT) сама идея, что придется за каким-то мелким вопросом постоянно лазить в сеть.
А в распространяемую локальную копию входят тело программы, управляющей базой данных, с защитой от несанкционированного использования и чистая база:
а) которую я могу сам наполнить тем, что мне нужно;
б) в которую я могу интегрировать как часть общей купленную мной у М.Быкова (и т.д.) базу;
в) которую я могу сам перестроить по нуждам своего исследования;
г) в которой я мог бы вносить изменения и дополнения к уже купленным частям баз данных, и чтобы при покупке обновлений мои измененные, доработанные или добавленные данные не затирались обновлением.
д) из которой я могу выгрузить копию какого-то блока данных с внесенными мной изменениями и поделиться, например, с Hippo. Или выгрузить свои изменения и предложить их на продажу всем желающим.
Т.е. программа отдельно, база отдельно.
СК
От Seeker
К SK (12.09.2006 16:47:33)
Дата 12.09.2006 22:04:04

А вы друг другу и не противоречите...

>>Нет, "экономическая модель", может быть другая:
>>- все база никому не передается (не существует локальных копий);

Да, не передается, но существует возможность клиенту работать с собственной локальной БД.

>>- экспорт всех данных пользователем невозможен;

Ну, что-то он сможет получить. Запариться, правда :))

>>- пользователь оплачивает подписку
>>- контроль за авторами, использующими базу (мы же попутно и журналы/газеты/книги читаем и заносим :). Ссылка на базу обязательна :). Использовал, но не платил - отключаем нафиг.

Да, и по суду - иск. Для всего описанного требуется регистрация какого-нибудь ю/л "Рога и Копыта".

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

А это не наши проблемы. Разработчики просто желают защитить свои вложения в продукт. Если ломать не выгодно, покупайте подписку.

>Мне, допустим, неприятна (на данном этапе развития IT) сама идея, что придется за каким-то мелким вопросом постоянно лазить в сеть.

А что делать? Связь сейчас, слава Богу, не проблема.

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

Да, это будет только Ваше. Но мы постраемся сделать более выгодное предложение авторам, распространяя их наработки за звонкую монету.

>в) которую я могу сам перестроить по нуждам своего исследования;

А вот это фигушки, внимательно читайте лицензионное соглашение :)), где прямо говориться о том, что клиент обязуется не изменять исходный код (модифицировать) продукта. Если желаете действовать в рамках Open Source, вперед - займитесь собственной разработкой вместе с желающими. Мы же говорим о том, что продукт будет стороннего разработчика, который отвечает за корректную и стабильную работу. Желаете что-то дополнительно, пожалуйста - за отдельные деньги. И не вижу в этом ничего страшного.

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

Только обратная связь с разработчиками позволит Вам это сделать без проблем. В противном случае - читайте лицензионное соглашение :))

>д) из которой я могу выгрузить копию какого-то блока данных с внесенными мной изменениями и поделиться, например, с Hippo. Или выгрузить свои изменения и предложить их на продажу всем желающим.

В таком случае, контора снимает с себя ответственность за возможные последствия использования БД от стороннего разработчика. Т.е., вы это делаете "на свой страх и риск". Проще заранее согласовать структуру Ваше БД с разработчиками.

>Т.е. программа отдельно, база отдельно.

Да на здоровье.


Фу-у..
От SK
К Seeker (12.09.2006 22:04:04)
Дата 13.09.2006 10:56:01

Re: А вы

>>в) которую я могу сам перестроить по нуждам своего исследования;
>
>А вот это фигушки, внимательно читайте лицензионное соглашение :)), где прямо говориться о том, что клиент обязуется не изменять исходный код (модифицировать) продукта. Если желаете действовать в рамках Open Source, вперед - займитесь собственной разработкой вместе с желающими. Мы же говорим о том, что продукт будет стороннего разработчика, который отвечает за корректную и стабильную работу. Желаете что-то дополнительно, пожалуйста - за отдельные деньги. И не вижу в этом ничего страшного.
А добавить (сконструировать) свои документы, отчеты, разделы БД на основе имеющегося движка (и не задевая разработанные модули) - почему бы нет?
СК
От Seeker
К SK (13.09.2006 10:56:01)
Дата 13.09.2006 11:25:13

А потому.


>А добавить (сконструировать) свои документы, отчеты, разделы БД на основе имеющегося движка (и не задевая разработанные модули) - почему бы нет?

Ну, нет - так нет :)). Все зависит от того, на чем такая СУБД реализована (на мой взгляд лучше всего подойдет SQL-сервер), чтобы учтя все тонкости реализации можно было что-то свое подключать. В конце концов, ведь не движок разрабатывается, а СУБД.
От SK
К Seeker (13.09.2006 11:25:13)
Дата 13.09.2006 15:57:35

Re: А потому.

>Ну, нет - так нет :)). Все зависит от того, на чем такая СУБД реализована (на мой взгляд лучше всего подойдет SQL-сервер), чтобы учтя все тонкости реализации можно было что-то свое подключать. В конце концов, ведь не движок разрабатывается, а СУБД.
Вот теперь возникает резонный вопрос: А зачем все это?
Мне база по самолетам нужна как рабочий инструмент, чтобы после постепенного введения туда обрывочных порой записей архивных тетрадок получитькакие-то сводные данные и определить для каждой части:
1. Сколько машин было в конкретной части на интересующую меня дату (исправных, неисправных, в реморганах).
2. Поступление и потери (в т.ч.причины потерь) самолетов за определенный период.
3. По возможности иметь справочные данные: бортовой номер каждой машины, закрепление за пилотом, номера мотора и т.д.
Есть еще идеи?
Теперь вопрос к вам: зачем нужна база по пилотам (кроме как для справки)?
СК
От Seeker
К SK (13.09.2006 15:57:35)
Дата 13.09.2006 20:52:08

Прошу пардону...


за искажение генеральной линии партии.

>Мне база по самолетам нужна как рабочий инструмент, чтобы после постепенного введения туда обрывочных порой записей архивных тетрадок получить какие-то сводные данные и определить для каждой части:

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

>Теперь вопрос к вам: зачем нужна база по пилотам (кроме как для справки)?

Прохождение службы, боевая работа (в идеале, с деталировкой событий), фото на данную персоналию, и источники на основании чего все это составлено. Железяки не так уж важно, это к стендовикам.
От Alex
К SK (13.09.2006 15:57:35)
Дата 13.09.2006 17:54:54

Re: А потому.

>1. Сколько машин было в конкретной части на интересующую меня дату (исправных, неисправных, в реморганах).
>2. Поступление и потери (в т.ч.причины потерь) самолетов за определенный период.
>3. По возможности иметь справочные данные: бортовой номер каждой машины, закрепление за пилотом, номера мотора и т.д.
>Есть еще идеи?

>Теперь вопрос к вам: зачем нужна база по пилотам (кроме как для справки)?

У каждого своя религия:) Для меня лично матчасть вторична, а первичны люди. И если я (грешен) тоже что-то кропаю, то для того, чтобы знать:

1. Сколько пилотов было в конкретной части на интересующую меня дату (исправных, неисправных, в реморганах).
2. Поступление и потери (в т.ч.причины потерь) пилотов за определенный период.
3. По возможности иметь справочные данные: бортовой номер каждого пилота, закрепление за машиной, и т.д. :)
От SK
К Alex (13.09.2006 17:54:54)
Дата 14.09.2006 11:18:35

Это две стороны одной медали

Вам, чтобы описать боевые действия на каком-то участке фронта не обойтись без численности, а мне соответственно не обойтись без ответа на вопрос, а были ли пилоты, чтобы поднять всю армаду в воздух, их подготовка и т.д.
Плюс из-за недостатка документов (или нужной информации в документах), вы знаете, часто приходится сравнивать между собой два этих массива данных, чтобы определить, например, по точной дате гибели летчика дату потери самолета по записи типа: "с 22.6 по 22.7.43 потери ? иап 1 Як-7" и соответственно наоборот.
Именно в этом смысле я вижу необходимость взаимодействия баз. Плюс разделение труда - тоже очень выгодная вещь (у большинства есть семьи, дети, а также гаражи, сараи, ремонт жилища и зарабатывание хлеба насущного).
СК
От deruluft
К Seeker (12.09.2006 13:18:57)
Дата 12.09.2006 13:37:59

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

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

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

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

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

В любом случае технических проблем нет. Есть вопросы "Зачем?" и "что в результате?"
в музей пойдем когда - обсудим.
От hunter019
К deruluft (12.09.2006 13:37:59)
Дата 12.09.2006 15:39:47

А в какой музей идете? (-)
От Seeker
К deruluft (12.09.2006 13:37:59)
Дата 12.09.2006 13:52:11

А теперь - согласен...

>Да не важно :). Перенести с однй платформы на другую это не является пробемой. Экспорт - импорт, попутно выверка :).

Не проблема, но гемморой и лишняя работа. Зачем?

>В любом случае технических проблем нет. Есть вопросы "Зачем?" и "что в результате?"

Есть проблема в организации. Самым правильным и наглядно полезным явилось бы создание БД по книжкам/журналам, возможно, документам для тех кому надо. Т.е., реализация очередного заброшенного мной проекта электронной библиотеки :))))

>в музей пойдем когда - обсудим.

Яволь, обергрупеннфюрер. Пошел звонить. Разрешите идти! :))
От SK
К Seeker (12.09.2006 13:52:11)
Дата 12.09.2006 15:59:08

Re: А теперь

>Есть проблема в организации. Самым правильным и наглядно полезным явилось бы создание БД по книжкам/журналам, возможно, документам для тех кому надо. Т.е., реализация очередного заброшенного мной проекта электронной библиотеки :))))
Это может быть и частью общей базы. Открываешь карточку, например, пилота и имеешь в отдельном поле БД ссылки на литературные источники.
СК
От Seeker
К SK (12.09.2006 15:59:08)
Дата 12.09.2006 21:18:16

Да..


>Это может быть и частью общей базы. Открываешь карточку, например, пилота и имеешь в отдельном поле БД ссылки на литературные источники.

Вот именно. Такую базу можно легко сопрячь с другими. Опять же, она может выступить пробным камнем, на ней можно обкатать все идею создания большой БД. Ну, а если глобальный проект провалиться - у нас будет база по источникам!