Balancer
инфо
инструменты
Capt(N)
Реклама Google — средство выживания форумов :)
-
/58bfb5c65f29t.jpg)
База данных по кораблям.
Теги:
Capt(N)> видать IE7 глючит
Так что пишет-то?
...
(А сейчас как?)
Так что пишет-то?
...
(А сейчас как?)
Capt(N)>> видать IE7 глючит
Balancer> Так что пишет-то?
пишет,что Internet Explorer не может отобразить эту веб-страницу
Balancer> (А сейчас как?)
так же
Balancer> Так что пишет-то?
пишет,что Internet Explorer не может отобразить эту веб-страницу
Balancer> (А сейчас как?)
так же
Capt(N)> пишет,что Internet Explorer не может отобразить эту веб-страницу
Balancer>> (А сейчас как?)
Capt(N)> так же
Сейчас проверил IE7 под XP в VirtualBox'е - соединяется без проблем. М.б. что-то в настройках соединения в IE7 у тебя?
Balancer>> (А сейчас как?)
Capt(N)> так же
Сейчас проверил IE7 под XP в VirtualBox'е - соединяется без проблем. М.б. что-то в настройках соединения в IE7 у тебя?
Balancer> Сейчас проверил IE7 под XP в VirtualBox'е - соединяется без проблем. М.б. что-то в настройках соединения в IE7 у тебя?
скорее всего,буду разбираться
скорее всего,буду разбираться
Serge_Kuzmin> Жду конструктивные, прицельные (тщательно) табуретки.
первая пошла...
Таблица navy_crews
1) Содержит в себе данные о физ лице. ИМХО не есть гуд.
Нужна еще одна таблица - физ лица. Из которой в экипаж набирать людей.
Т.е. поля
name
secondname
lastname
перенести в нее.
2) Таблица присвоенных званий ИМХО тоже должна быть отдельной, так как присвоение очередного звания чаще не связано с переводом на другую должность.
И соответственно привязка должна идти к таблице людей.
3) Если уж изголяться, то я бы в таблицу добавлял не id_ship, а regiment_id` - ID соединения (Таблица NAVY_REGIMENTS)
Осознавая что каждый корабль есть воинская часть.( Соответсвенно добавив ссулку на воинскую часть в таблицу кораблей)
Просто если говорить о истории по людям, то тогда потеряются те, кто не служит на кораблях. (Например мы потеряем историю Кэпа).
И тогда в NAVY_REGIMENTS можно вести и штабы и т.п. Ну или в крайнем случае добавил бы возможность отслеживания службы по штабам. (Т.е. добавил regiment_id)
П.С. При здравом размышлении я бы воинские части с NAVY_REGIMENTS не смешивал и сделал отдельную таблицу. А то при переводе из соединения в соединение прийдется и воинскую чсть перебрасывать...
1. NAVY_SPEC_PARAMS
2. NAVY_SPEC_VARIANTS
3. NAVY_SPEC_VALUES
4. NAVY_SYSTEMS
1) Как бы задумка хорошая. Но ИМХО очень сложная.
Тогда прийдется еще хранить варианты отображений данных в виде набора значений которые будут отображаться в том или ином случае. Наворотил в общем...
Может хорошенько продумать состав таблиц? Ведь для поиска и сравнения много данных не нужно.
А все остальное можно вносить на индивидуальной страничке корабля в текстовой форме.
2) С историей NAVY_SPEC_VALUES не очень понятно. А если снимается не весь соства вооружения, а только часть? Например первоначально ставим 3*3 АУ 152. Дата - с 01.01.1941. А потом кормовую 1*3 152 снимаем. Например 01.01.1950.
Как при этом будет выглядеть запись?
3) Плохо, что у тебя привязка идет к проекту. Я бы все таки привязывал это к кораблю. Потому как история изменения вооружения индивидуальна для корабля, а не проекта. Просто в таблице проектов ссылался бы на головной корабль серии.
И выводил характеристики по нему. Для не спущенных на воду заводил бы "корабль проекта №". И вносил бы все характеристики не по проекту, а по кораблю.
4) Не совсем понятно как ты будешь решать например увязку РЛС, ПУ и АСУ в один комплекс ЗРК например. А это по крайней мере для ЗРК очень хотелось бы видеть. Плюс опять же есть например СУ. В сосав входят котлы, ТЗА, винты и т.д. Не понятно как это будет выглядеть в предложенном варианте таблиц.
П.С. Насколько уж я извращенец, но на такое в своей базе не решился. Может все же упростить?
первая пошла...
Таблица navy_crews
1) Содержит в себе данные о физ лице. ИМХО не есть гуд.
Нужна еще одна таблица - физ лица. Из которой в экипаж набирать людей.
Т.е. поля
name
secondname
lastname
перенести в нее.
2) Таблица присвоенных званий ИМХО тоже должна быть отдельной, так как присвоение очередного звания чаще не связано с переводом на другую должность.
И соответственно привязка должна идти к таблице людей.
3) Если уж изголяться, то я бы в таблицу добавлял не id_ship, а regiment_id` - ID соединения (Таблица NAVY_REGIMENTS)
Осознавая что каждый корабль есть воинская часть.( Соответсвенно добавив ссулку на воинскую часть в таблицу кораблей)
Просто если говорить о истории по людям, то тогда потеряются те, кто не служит на кораблях. (Например мы потеряем историю Кэпа).
И тогда в NAVY_REGIMENTS можно вести и штабы и т.п. Ну или в крайнем случае добавил бы возможность отслеживания службы по штабам. (Т.е. добавил regiment_id)
П.С. При здравом размышлении я бы воинские части с NAVY_REGIMENTS не смешивал и сделал отдельную таблицу. А то при переводе из соединения в соединение прийдется и воинскую чсть перебрасывать...
1. NAVY_SPEC_PARAMS
2. NAVY_SPEC_VARIANTS
3. NAVY_SPEC_VALUES
4. NAVY_SYSTEMS
1) Как бы задумка хорошая. Но ИМХО очень сложная.
Тогда прийдется еще хранить варианты отображений данных в виде набора значений которые будут отображаться в том или ином случае. Наворотил в общем...
Может хорошенько продумать состав таблиц? Ведь для поиска и сравнения много данных не нужно.
А все остальное можно вносить на индивидуальной страничке корабля в текстовой форме.
2) С историей NAVY_SPEC_VALUES не очень понятно. А если снимается не весь соства вооружения, а только часть? Например первоначально ставим 3*3 АУ 152. Дата - с 01.01.1941. А потом кормовую 1*3 152 снимаем. Например 01.01.1950.
Как при этом будет выглядеть запись?
3) Плохо, что у тебя привязка идет к проекту. Я бы все таки привязывал это к кораблю. Потому как история изменения вооружения индивидуальна для корабля, а не проекта. Просто в таблице проектов ссылался бы на головной корабль серии.
И выводил характеристики по нему. Для не спущенных на воду заводил бы "корабль проекта №". И вносил бы все характеристики не по проекту, а по кораблю.
4) Не совсем понятно как ты будешь решать например увязку РЛС, ПУ и АСУ в один комплекс ЗРК например. А это по крайней мере для ЗРК очень хотелось бы видеть. Плюс опять же есть например СУ. В сосав входят котлы, ТЗА, винты и т.д. Не понятно как это будет выглядеть в предложенном варианте таблиц.
П.С. Насколько уж я извращенец, но на такое в своей базе не решился. Может все же упростить?
Эх, жалко - королевство маловато , разгуляться негде! Ну ничего! Я поссорюсь с соседями! Это я умею. (с)
Balancer> Поковырялся немного с дизайном. Буду отрабатывать него на http://navy.balancer.ru
Balancer> ...
- Вах!!! ЗачОтный фон!!!))
Как бы "то что вы давно хотели, но никак не могли выразить словами")
Balancer> ...
- Вах!!! ЗачОтный фон!!!
))Как бы "то что вы давно хотели, но никак не могли выразить словами"
)
sas1975kr> первая пошла...
sas1975kr, спасибо за замечания!
У меня прошедшая неделя выдалась не плодотворной, до структуры дело не доходило.
В ближайшие дни осмыслю все замечания, выложу исправленный и дополненный вариант.
Ещё пару таких итераций и будет что-то пригодное для реализации.
sas1975kr, спасибо за замечания!
У меня прошедшая неделя выдалась не плодотворной, до структуры дело не доходило.
В ближайшие дни осмыслю все замечания, выложу исправленный и дополненный вариант.
Ещё пару таких итераций и будет что-то пригодное для реализации.
sas1975kr> А по поводу этого вопроса считаю самым рациональным - добавить два поля со значениями типа "формат даты" ...
vladre> 01.07.2009 05:02 - В генеалогической программе "Древо жизни" любую ...
- ок, думаю что нужно от обеих идей взять полезное, а именно:
1. Добавить в NAVY_SHIP_HISTORY поле PERIOD_TYPE (т.е. ту самую форматную строку - "месяц", "квартал"....).
2. Так так данные могут быть приблизительными, непроверенными, предварительными, прогнозными и т.д. - то это тоже желательно указывать, в отдельном поле, допустим PERIOD_NOTE.
Соответственно добавляются две таблицы NAVY_PERIOD_TYPES и NAVY_PERIOD_NOTES. Или можно таблиц не плодить, а использовать строго оговоренный набор значений. В интерфейсе - в виде выпадающего списка. Их ведь там будет всего по несколько оговоренных вариантов.
vladre> 01.07.2009 05:02 - В генеалогической программе "Древо жизни" любую ...
- ок, думаю что нужно от обеих идей взять полезное, а именно:
1. Добавить в NAVY_SHIP_HISTORY поле PERIOD_TYPE (т.е. ту самую форматную строку - "месяц", "квартал"....).
2. Так так данные могут быть приблизительными, непроверенными, предварительными, прогнозными и т.д. - то это тоже желательно указывать, в отдельном поле, допустим PERIOD_NOTE.
Соответственно добавляются две таблицы NAVY_PERIOD_TYPES и NAVY_PERIOD_NOTES. Или можно таблиц не плодить, а использовать строго оговоренный набор значений. В интерфейсе - в виде выпадающего списка. Их ведь там будет всего по несколько оговоренных вариантов.
sas1975kr> первая пошла...
- замечаний много и замечания конструктивные, поэтому возможно ответ растянется на несколько частей.
sas1975kr> Таблица navy_crews
sas1975kr> 1) Содержит в себе данные о физ лице. ИМХО не есть гуд.
sas1975kr> Нужна еще одна таблица - физ лица. Из которой в экипаж набирать людей.
- Тут у меня логика была следующая:
1. "Экипажная" часть каталога в моем понимании (на момент составления второго релиза структуры)) - очень, очень и очень фрагментарный набор информации. Потому что информации там масса, а данные есть как правило - по командирам корабля, остальное - совсем отрывочно. По крайней мере такая картина наблюдается во всех доступных интернет-ресурсах, подавляющем большинстве бумажных справочников и монографий.
2. Отсюда был сделан вывод - экипажи это табличка где привязваются имена-фвмилии-должности и кратенькая инфа к конкретному кораблю и всё. Естественно такая структура "лицом развернута" к кораблю, а к человеку ... ммм... эээ... ну в общем не позволяет такая структура проследить боевой путь Пупкина Ивана Спиридоновича. В свете твоих слов - наверное нужно заложить основу для полноценного справочника военно-морских персоналий. Поэтому появится таблица NAVY_PERSONS - это каталог физ. лиц. А NAVY_CREWS - привязка людей/должностей/званий/кораблей-в.частей к времени.
sas1975kr> 2) Таблица присвоенных званий ИМХО тоже должна быть отдельной, так как присвоение очередного звания чаще не связано с переводом на другую должность.sas1975kr> И соответственно привязка должна идти к таблице людей.
- так они и были предложены ввиде отдельной таблицы (navy_crew_positions), как и звания - navy_crew_ranks. На схеме см. слева вверху. Я просто в своем посте до них не дошел.
sas1975kr> 3) Если уж изголяться, то я бы в таблицу добавлял не id_ship, а regiment_id` - ID соединения (Таблица NAVY_REGIMENTS)
sas1975kr> Осознавая что каждый корабль есть воинская часть.( Соответсвенно добавив ссулку на воинскую часть в таблицу кораблей)
- ОК. Решение вижу в добавлении поля regiment_id в таблицу NAVY_CREWS. Но id_ship при этом останется, это во-первых позволит обыгрывать ситацию когда в одну воинскую часть входит несколько кораблей. У меня большие сомнения что, например, во времена ВМВ каждый торпедный катер типа Г-5 был отдельной в/ч - входили наверняка в какой-нибудь дивизион.
sas1975kr> Просто если говорить о истории по людям, то тогда потеряются те, кто не служит на кораблях. (Например мы потеряем историю Кэпа).
- этого мы не допустим
sas1975kr> И тогда в NAVY_REGIMENTS можно вести и штабы и т.п. Ну или в крайнем случае добавил бы возможность отслеживания службы по штабам. (Т.е. добавил regiment_id)
- О! ну вот мы и встретились))
sas1975kr> П.С. При здравом размышлении я бы воинские части с NAVY_REGIMENTS не смешивал и сделал отдельную таблицу. А то при переводе из соединения в соединение прийдется и воинскую чсть перебрасывать...
- надо обдумать. Эта тема сама по себе бездонная... не хочется в неё нырять "до дна" - кораблям ничего не достанется
- замечаний много и замечания конструктивные, поэтому возможно ответ растянется на несколько частей.
sas1975kr> Таблица navy_crews
sas1975kr> 1) Содержит в себе данные о физ лице. ИМХО не есть гуд.
sas1975kr> Нужна еще одна таблица - физ лица. Из которой в экипаж набирать людей.
- Тут у меня логика была следующая:
1. "Экипажная" часть каталога в моем понимании (на момент составления второго релиза структуры
)) - очень, очень и очень фрагментарный набор информации. Потому что информации там масса, а данные есть как правило - по командирам корабля, остальное - совсем отрывочно. По крайней мере такая картина наблюдается во всех доступных интернет-ресурсах, подавляющем большинстве бумажных справочников и монографий.2. Отсюда был сделан вывод - экипажи это табличка где привязваются имена-фвмилии-должности и кратенькая инфа к конкретному кораблю и всё. Естественно такая структура "лицом развернута" к кораблю, а к человеку ... ммм... эээ... ну в общем не позволяет такая структура проследить боевой путь Пупкина Ивана Спиридоновича. В свете твоих слов - наверное нужно заложить основу для полноценного справочника военно-морских персоналий. Поэтому появится таблица NAVY_PERSONS - это каталог физ. лиц. А NAVY_CREWS - привязка людей/должностей/званий/кораблей-в.частей к времени.
sas1975kr> 2) Таблица присвоенных званий ИМХО тоже должна быть отдельной, так как присвоение очередного звания чаще не связано с переводом на другую должность.sas1975kr> И соответственно привязка должна идти к таблице людей.
- так они и были предложены ввиде отдельной таблицы (navy_crew_positions), как и звания - navy_crew_ranks. На схеме см. слева вверху. Я просто в своем посте до них не дошел.
sas1975kr> 3) Если уж изголяться, то я бы в таблицу добавлял не id_ship, а regiment_id` - ID соединения (Таблица NAVY_REGIMENTS)
sas1975kr> Осознавая что каждый корабль есть воинская часть.( Соответсвенно добавив ссулку на воинскую часть в таблицу кораблей)
- ОК. Решение вижу в добавлении поля regiment_id в таблицу NAVY_CREWS. Но id_ship при этом останется, это во-первых позволит обыгрывать ситацию когда в одну воинскую часть входит несколько кораблей. У меня большие сомнения что, например, во времена ВМВ каждый торпедный катер типа Г-5 был отдельной в/ч - входили наверняка в какой-нибудь дивизион.
sas1975kr> Просто если говорить о истории по людям, то тогда потеряются те, кто не служит на кораблях. (Например мы потеряем историю Кэпа).
- этого мы не допустим
sas1975kr> И тогда в NAVY_REGIMENTS можно вести и штабы и т.п. Ну или в крайнем случае добавил бы возможность отслеживания службы по штабам. (Т.е. добавил regiment_id)
- О! ну вот мы и встретились
))sas1975kr> П.С. При здравом размышлении я бы воинские части с NAVY_REGIMENTS не смешивал и сделал отдельную таблицу. А то при переводе из соединения в соединение прийдется и воинскую чсть перебрасывать...
- надо обдумать. Эта тема сама по себе бездонная... не хочется в неё нырять "до дна" - кораблям ничего не достанется
Нашел очень редкую книгу в електронном виде, издания 1940 года -
Шведе Е. Е.
Военные флоты. 1939—1940 гг.
Справочник по военно-морским флотам иностранных государств
Издание седьмое
не могу не поделиться ссылочкой
кстати там еще много интересного не только по кораблям
Шведе Е. Е.
Военные флоты. 1939—1940 гг.
Справочник по военно-морским флотам иностранных государств
Издание седьмое
не могу не поделиться ссылочкой
кстати там еще много интересного не только по кораблям
"Время покажет, кто чего стоил в этой пурге" (с)
уф. что-то со временем совсем никак
Тем не менее - продолжаю по мере возможности:
sas1975kr> 1. NAVY_SPEC_PARAMS
sas1975kr> 2. NAVY_SPEC_VARIANTS
sas1975kr> 3. NAVY_SPEC_VALUES
sas1975kr> 4. NAVY_SYSTEMS
sas1975kr> 1) Как бы задумка хорошая. Но ИМХО очень сложная.
...
sas1975kr> А все остальное можно вносить на индивидуальной страничке корабля в текстовой форме.
sas1975kr> 2) С историей NAVY_SPEC_VALUES не очень понятно. А если снимается не весь соства вооружения, а только часть? Например первоначально ставим 3*3 АУ 152. Дата - с 01.01.1941. А потом кормовую 1*3 152 снимаем. Например 01.01.1950.
sas1975kr> Как при этом будет выглядеть запись?
Не придумал ничего лучше - чем прилагаемый скриншот.
Вкратце напомню:
NAVY_SPEC_PARAMS - древовидный справочник всех возможных наименований ТТХ
NAVY_SPEC_VALUES - таблица значений ТТХ с привязкой проект/время_действия_характеристики
NAVY_SPEC_VARIANTS - таблица значений ТТХ - для случаев когда существует строго определённый ряд значений, предназначена исключительно для уменьшения рутинных операций при работе с каталогом
NAVY_SYSTEMS - каталог морских систем в широком смысле слова (вооружения, средства навигации и связи, энергетические установки и т.д. и т.п.). В таблице NAVY_SPEC_VALUES даётся ссылка на системы из этой таблицы, в случае если система каталогизирована. Это направлени ещё нужно прорабатывать.
Примечание:
1. Таблицы NAVY_SPEC_VARIANTS и NAVY_SYSTEMS - опциональные.
2. Приведенная структура позволит получить на выходе что-то типа прилагаемого примера ТТХ из Апалькова (картинка 2). + дополнительные фичи в виде истории.
Тем не менее - продолжаю по мере возможности:
sas1975kr> 1. NAVY_SPEC_PARAMS
sas1975kr> 2. NAVY_SPEC_VARIANTS
sas1975kr> 3. NAVY_SPEC_VALUES
sas1975kr> 4. NAVY_SYSTEMS
sas1975kr> 1) Как бы задумка хорошая. Но ИМХО очень сложная.
...
sas1975kr> А все остальное можно вносить на индивидуальной страничке корабля в текстовой форме.
sas1975kr> 2) С историей NAVY_SPEC_VALUES не очень понятно. А если снимается не весь соства вооружения, а только часть? Например первоначально ставим 3*3 АУ 152. Дата - с 01.01.1941. А потом кормовую 1*3 152 снимаем. Например 01.01.1950.
sas1975kr> Как при этом будет выглядеть запись?
Не придумал ничего лучше - чем прилагаемый скриншот.
Вкратце напомню:
NAVY_SPEC_PARAMS - древовидный справочник всех возможных наименований ТТХ
NAVY_SPEC_VALUES - таблица значений ТТХ с привязкой проект/время_действия_характеристики
NAVY_SPEC_VARIANTS - таблица значений ТТХ - для случаев когда существует строго определённый ряд значений, предназначена исключительно для уменьшения рутинных операций при работе с каталогом
NAVY_SYSTEMS - каталог морских систем в широком смысле слова (вооружения, средства навигации и связи, энергетические установки и т.д. и т.п.). В таблице NAVY_SPEC_VALUES даётся ссылка на системы из этой таблицы, в случае если система каталогизирована. Это направлени ещё нужно прорабатывать.
Примечание:
1. Таблицы NAVY_SPEC_VARIANTS и NAVY_SYSTEMS - опциональные.
2. Приведенная структура позволит получить на выходе что-то типа прилагаемого примера ТТХ из Апалькова (картинка 2). + дополнительные фичи в виде истории.
Прикреплённые файлы:
Это сообщение редактировалось 21.07.2009 в 03:06
....
sas1975kr> 1) Как бы задумка хорошая. Но ИМХО очень сложная.
sas1975kr> Тогда прийдется еще хранить варианты отображений данных в виде набора значений которые будут отображаться в том или ином случае. Наворотил в общем...
- не совсем понял вот это "варианты отображений данных"... Если имеется ввиду списки вариантов значений для отдельных ТТХ (где это вообще применимо) - то тут особой сложности не вижу (NAVY_SPEC_VARIANTS), и заметь - эти варианты можно использовать в очень и очень ограниченном количестве случаев... слёту даже в голову ничего простого не приходит. Ну например тип ГЭУ.
... или проясни что имеется ввиду.
sas1975kr> Может хорошенько продумать состав таблиц? Ведь для поиска и сравнения много данных не нужно.
- проблема в том что этот самый состав может быть самым разным. Я сначала хотел выделить несколько таких блоков характеристик - но у меня так ничего и не вышло. Если есть предложения - готов обсудить.
sas1975kr> А все остальное можно вносить на индивидуальной страничке корабля в текстовой форме.
- эту текстовую форму каждый будет городить на свой вкус, а значит порядка не будет.
sas1975kr> 3) Плохо, что у тебя привязка идет к проекту. Я бы все таки привязывал это к кораблю. Потому как история изменения вооружения индивидуальна для корабля, а не проекта. Просто в таблице проектов ссылался бы на головной корабль серии.
sas1975kr> И выводил характеристики по нему. Для не спущенных на воду заводил бы "корабль проекта №". И вносил бы все характеристики не по проекту, а по кораблю.
- как быть с кораблями строившимися крупной серией? Насколько выгода от такой "аптечной точности" в плане ТТХ оправдывает возню с ТТХ для каждого корабля? Не проще ли отличия указывать "на индивидуальной страничке корабля в текстовой форме" (в предлагаемой структуре - это можно как-то обыграть в navy_ship_history) или в общей информации по проекту? Если акцентировать внимание на отечественном послевоенном флоте - то как правило изменения вооружения кораблей в серии и значительние модернизации были связаны с изменением № проекта (например - 56,68...) - а это значить отдельный проект в предлагаемой структуре.
sas1975kr> 4) Не совсем понятно как ты будешь решать например увязку РЛС, ПУ и АСУ в один комплекс ЗРК например. А это по крайней мере для ЗРК очень хотелось бы видеть. Плюс опять же есть например СУ. В сосав входят котлы, ТЗА, винты и т.д. Не понятно как это будет выглядеть в предложенном варианте таблиц.
- см. картинку №1 в предыдущем посте (navy_spec_params_&_values.jpg), там где "Количество АУ" и "Боекомплект".
sas1975kr> П.С. Насколько уж я извращенец, но на такое в своей базе не решился. Может все же упростить?
- я обеимим руками за упрощение Только всё моё "упрощение" вылилось в предлагаемую структуру. Не вижу я простоты в разведении неизвестного количества специализированных таблиц под отдельные блоки ТТХ и выкидывании того что не в них не ложится - в текстовые заметки. Может быть я не прав. Готов обсудить любые альтернативные варианты.
sas1975kr> 1) Как бы задумка хорошая. Но ИМХО очень сложная.
sas1975kr> Тогда прийдется еще хранить варианты отображений данных в виде набора значений которые будут отображаться в том или ином случае. Наворотил в общем...
- не совсем понял вот это "варианты отображений данных"... Если имеется ввиду списки вариантов значений для отдельных ТТХ (где это вообще применимо) - то тут особой сложности не вижу (NAVY_SPEC_VARIANTS), и заметь - эти варианты можно использовать в очень и очень ограниченном количестве случаев... слёту даже в голову ничего простого не приходит. Ну например тип ГЭУ.
... или проясни что имеется ввиду.
sas1975kr> Может хорошенько продумать состав таблиц? Ведь для поиска и сравнения много данных не нужно.
- проблема в том что этот самый состав может быть самым разным. Я сначала хотел выделить несколько таких блоков характеристик - но у меня так ничего и не вышло. Если есть предложения - готов обсудить.
sas1975kr> А все остальное можно вносить на индивидуальной страничке корабля в текстовой форме.
- эту текстовую форму каждый будет городить на свой вкус, а значит порядка не будет.
sas1975kr> 3) Плохо, что у тебя привязка идет к проекту. Я бы все таки привязывал это к кораблю. Потому как история изменения вооружения индивидуальна для корабля, а не проекта. Просто в таблице проектов ссылался бы на головной корабль серии.
sas1975kr> И выводил характеристики по нему. Для не спущенных на воду заводил бы "корабль проекта №". И вносил бы все характеристики не по проекту, а по кораблю.
- как быть с кораблями строившимися крупной серией? Насколько выгода от такой "аптечной точности" в плане ТТХ оправдывает возню с ТТХ для каждого корабля? Не проще ли отличия указывать "на индивидуальной страничке корабля в текстовой форме" (в предлагаемой структуре - это можно как-то обыграть в navy_ship_history) или в общей информации по проекту? Если акцентировать внимание на отечественном послевоенном флоте - то как правило изменения вооружения кораблей в серии и значительние модернизации были связаны с изменением № проекта (например - 56,68...) - а это значить отдельный проект в предлагаемой структуре.
sas1975kr> 4) Не совсем понятно как ты будешь решать например увязку РЛС, ПУ и АСУ в один комплекс ЗРК например. А это по крайней мере для ЗРК очень хотелось бы видеть. Плюс опять же есть например СУ. В сосав входят котлы, ТЗА, винты и т.д. Не понятно как это будет выглядеть в предложенном варианте таблиц.
- см. картинку №1 в предыдущем посте (navy_spec_params_&_values.jpg), там где "Количество АУ" и "Боекомплект".
sas1975kr> П.С. Насколько уж я извращенец, но на такое в своей базе не решился. Может все же упростить?
- я обеимим руками за упрощение
Только всё моё "упрощение" вылилось в предлагаемую структуру. Не вижу я простоты в разведении неизвестного количества специализированных таблиц под отдельные блоки ТТХ и выкидывании того что не в них не ложится - в текстовые заметки. Может быть я не прав. Готов обсудить любые альтернативные варианты.
Ув. коллеги!
Много идей крутится в голове по-поводу того что хотелось бы иметь в этом перспективном каталоге, хочу некоторые озвучить для дальнейшего обсуждения:
1. Возможность сохранения раздела каталога в формате pdf (например по конкретному проекту). Этакая pdf-справочка
2. Для членов профсоюза - аналитическая консоль запросов: заточенный под неискушенного в базах данных пользователя интерфейс, позволяющий делать выборки из каталога, а-ля "сравнение ТТХ кораблей такого-то класса с водоизмещением от .... до .... и датой ввода в строй с .... по ....", или "спуск кораблей таким-то ССЗ в период с .... по .... в разрезе классов"
3. По каждому классу, кроме кораблей которые были заложены/построены - допустим в отдельной "закладке" - нереализованные проекты, это целый пласт информации.
Высказывайте ваши пожелания!
Много идей крутится в голове по-поводу того что хотелось бы иметь в этом перспективном каталоге, хочу некоторые озвучить для дальнейшего обсуждения:
1. Возможность сохранения раздела каталога в формате pdf (например по конкретному проекту). Этакая pdf-справочка
2. Для членов профсоюза - аналитическая консоль запросов: заточенный под неискушенного в базах данных пользователя интерфейс, позволяющий делать выборки из каталога, а-ля "сравнение ТТХ кораблей такого-то класса с водоизмещением от .... до .... и датой ввода в строй с .... по ....", или "спуск кораблей таким-то ССЗ в период с .... по .... в разрезе классов"
3. По каждому классу, кроме кораблей которые были заложены/построены - допустим в отдельной "закладке" - нереализованные проекты, это целый пласт информации.
Высказывайте ваши пожелания!
Ув. коллеги!
Представляю третью итерацию структуры БД.
Файл с прорабатываемой структурой:
http://navy.balancer.ru/navy.zip [zero size or time out]
Если не будет возражений и дополнений влекущих кардинальные переработки - то дальше займусь практической реализацией.
Для просмотра используем:
Также прилагаю вариант в GIF.
Пояснения в следующем посте.
Представляю третью итерацию структуры БД.
Файл с прорабатываемой структурой:
http://navy.balancer.ru/navy.zip [zero size or time out]
Если не будет возражений и дополнений влекущих кардинальные переработки - то дальше займусь практической реализацией.
Для просмотра используем:
MySQL :: Download MySQL Workbench
Login | Register USA: +1-866-221-0634 Canada: +1-866-221-0634 Germany: +49 89 143 01280 France: +33 1 57 60 83 57 Italy: +39 02 249 59 120 UK: +44 207 553 8447 Japan: 0120-065556 China: 10800-811-0823 India: 0008001005870 Brazil: +55 11 5189-1097 More Countries » Contact Us Online » MySQL open source software is provided under the GPL License. OEMs, ISVs and VARs can purchase commercial licenses. MySQL Workbench provides DBAs and developers an integrated tools environment for: The Community (OSS) Edition is available from this page under the GPL. // Дальше — dev.mysql.comТакже прилагаю вариант в GIF.
Пояснения в следующем посте.
Прикреплённые файлы:
Изменения в структуре:
1. Таблица NAVY_REGIMENTS
- добавлено поле ARTICLE - статья по данному подразделению
2. Таблица NAVY_SHIPS
- добавлено поле ARTICLE - статья по данному кораблю
3. Добавлена таблица NAVY_PHOTOS - фотокаталог
`SHIP_ID` INT(11) NULL COMMENT 'ID корабля' ,
`NAVY_SYSTEM_ID` INT(11) NULL COMMENT 'ID системы (Таблица NAVY_SYSTEMS)' ,
`PERSON_ID` INT(11) NULL COMMENT 'ID персоны' ,
`PHOTO_DATE_BEGIN` DATE NOT NULL COMMENT 'Дата начала события' ,
`PHOTO_DATE_END` DATE NULL COMMENT 'Дата окончания события' ,
`ARTICLE` TEXT NULL COMMENT 'Описание фотографии' ,
`AUTHOR_ID` INT(11) NULL COMMENT 'ID Автор фото' ,
`COLLECTOR_ID` INT(11) NULL COMMENT 'Фото предоставил ...' ,
`PHOTO_SIZE_CATEGORY` INT(1) NULL COMMENT 'Категория по размеру фото (Большие, маленикие, Высокого разрешения...)' ,
`PHOTO_ALBUM_ID` INT(11) NULL COMMENT 'ID альбома (тематической подборки)' ,
`SOURCE_ID` INT(11) NULL COMMENT 'ID источника (книга, сайт, частное собрание)' ,
`PERIOD_TYPE ` INT(11) NULL COMMENT '(Тип периода: День, Месяц, Квартал ....)'
`PERIOD_NOTE ` INT(11) NULL COMMENT '(уточнение периода: точно, приблизительно, прогноз ...)'
4. Таблица NAVY_SHIP_HISTORY
- Добавлено поле PERIOD_TYPE (Тип периода: День, Месяц, Квартал ....)
- Добавлено поле PERIOD_NOTE (уточнение периода: точно, приблизительно, прогноз ...)
5. Таблица NAVY_SHIP_PROJECTS
- Добавлено поле NON_REALIZED (число 0/1) - Признак "Проект нереализован"
6. Добавлена таблица NAVY_PHOTO_ALBUMS - альбомы и тематические подборки фото и графики
7. Добавлена таблица NAVY_PERSONS
`ID` INT(11) NOT NULL AUTO_INCREMENT ,
`BEGIN_DATE` DATE NOT NULL COMMENT 'Дата рождения' ,
`END_DATE` DATE NULL COMMENT 'Дата смерти' ,
`NAME` VARCHAR(100) NOT NULL COMMENT 'Имя' ,
`SECONDNAME` VARCHAR(100) NULL COMMENT 'Отчество' ,
`LASTNAME` VARCHAR(100) NOT NULL COMMENT 'Фамилия' ,
`ID_COUNTRY` INT(11) NOT NULL COMMENT 'ID страны' ,
`ARTICLE` TEXT NULL COMMENT 'Содержательная часть' ,
`NOTE` TEXT NULL COMMENT 'Примечание' ,
8. Таблица NAVY_CREWS
- убраны поля NAME, SECONDNAME, LASTNAME - в связи с тем что информация по персоналиям
выносится в отдельную таблицу NAVY_PERSONS
9. Таблица NAVY_SHIPS (Морские системы: вооружение, механизмы и т.п.)
- добавлено поле ARTICLE - статья по данной системе
10. Добавлена таблица NAVY_AUTHORS (Авторы: "Фотографы, писатели, историки...")
`title` VARCHAR(255) NOT NULL ,
`email` VARCHAR(45) NULL ,
`url` VARCHAR(150) NULL ,
`is_photographer` INT(1) NULL COMMENT 'Признак \"Фотограф\"' ,
`is_writer` INT(1) NULL COMMENT 'Признак \"Писатель\"' ,
11. Добавлена таблица NAVY_SOURSES (Источники информации (книги, сайты...))
`id` INT(11) NOT NULL AUTO_INCREMENT ,
`title` VARCHAR(255) NOT NULL ,
`url` VARCHAR(150) NULL ,
`id_author` INT(11) NULL ,
`id_author2` INT(11) NULL ,
`id_author3` INT(11) NULL ,
`id_author4` INT(11) NULL ,
`id_author5` INT(11) NULL ,
`note` TEXT NULL ,
12. Добавлена таблица NAVY_REFERENCES (Ссылки на источники информации)
`id` INT(11) NOT NULL AUTO_INCREMENT ,
`article_type` INT(1) NOT NULL COMMENT 'Тип ссылающейся статьи (Проект, Персона, Система...)\n' ,
`id_article` INT(11) NOT NULL COMMENT 'ID статьи (материала)' ,
`id_sourse` INT(11) NOT NULL COMMENT 'ID источника' ,
`note` TEXT NULL COMMENT 'Примечание' ,
`hotlink` VARCHAR(150) NULL COMMENT 'Ссылка на страницу интернет-источнка' ,
1. Таблица NAVY_REGIMENTS
- добавлено поле ARTICLE - статья по данному подразделению
2. Таблица NAVY_SHIPS
- добавлено поле ARTICLE - статья по данному кораблю
3. Добавлена таблица NAVY_PHOTOS - фотокаталог
`SHIP_ID` INT(11) NULL COMMENT 'ID корабля' ,
`NAVY_SYSTEM_ID` INT(11) NULL COMMENT 'ID системы (Таблица NAVY_SYSTEMS)' ,
`PERSON_ID` INT(11) NULL COMMENT 'ID персоны' ,
`PHOTO_DATE_BEGIN` DATE NOT NULL COMMENT 'Дата начала события' ,
`PHOTO_DATE_END` DATE NULL COMMENT 'Дата окончания события' ,
`ARTICLE` TEXT NULL COMMENT 'Описание фотографии' ,
`AUTHOR_ID` INT(11) NULL COMMENT 'ID Автор фото' ,
`COLLECTOR_ID` INT(11) NULL COMMENT 'Фото предоставил ...' ,
`PHOTO_SIZE_CATEGORY` INT(1) NULL COMMENT 'Категория по размеру фото (Большие, маленикие, Высокого разрешения...)' ,
`PHOTO_ALBUM_ID` INT(11) NULL COMMENT 'ID альбома (тематической подборки)' ,
`SOURCE_ID` INT(11) NULL COMMENT 'ID источника (книга, сайт, частное собрание)' ,
`PERIOD_TYPE ` INT(11) NULL COMMENT '(Тип периода: День, Месяц, Квартал ....)'
`PERIOD_NOTE ` INT(11) NULL COMMENT '(уточнение периода: точно, приблизительно, прогноз ...)'
4. Таблица NAVY_SHIP_HISTORY
- Добавлено поле PERIOD_TYPE (Тип периода: День, Месяц, Квартал ....)
- Добавлено поле PERIOD_NOTE (уточнение периода: точно, приблизительно, прогноз ...)
5. Таблица NAVY_SHIP_PROJECTS
- Добавлено поле NON_REALIZED (число 0/1) - Признак "Проект нереализован"
6. Добавлена таблица NAVY_PHOTO_ALBUMS - альбомы и тематические подборки фото и графики
7. Добавлена таблица NAVY_PERSONS
`ID` INT(11) NOT NULL AUTO_INCREMENT ,
`BEGIN_DATE` DATE NOT NULL COMMENT 'Дата рождения' ,
`END_DATE` DATE NULL COMMENT 'Дата смерти' ,
`NAME` VARCHAR(100) NOT NULL COMMENT 'Имя' ,
`SECONDNAME` VARCHAR(100) NULL COMMENT 'Отчество' ,
`LASTNAME` VARCHAR(100) NOT NULL COMMENT 'Фамилия' ,
`ID_COUNTRY` INT(11) NOT NULL COMMENT 'ID страны' ,
`ARTICLE` TEXT NULL COMMENT 'Содержательная часть' ,
`NOTE` TEXT NULL COMMENT 'Примечание' ,
8. Таблица NAVY_CREWS
- убраны поля NAME, SECONDNAME, LASTNAME - в связи с тем что информация по персоналиям
выносится в отдельную таблицу NAVY_PERSONS
9. Таблица NAVY_SHIPS (Морские системы: вооружение, механизмы и т.п.)
- добавлено поле ARTICLE - статья по данной системе
10. Добавлена таблица NAVY_AUTHORS (Авторы: "Фотографы, писатели, историки...")
`title` VARCHAR(255) NOT NULL ,
`email` VARCHAR(45) NULL ,
`url` VARCHAR(150) NULL ,
`is_photographer` INT(1) NULL COMMENT 'Признак \"Фотограф\"' ,
`is_writer` INT(1) NULL COMMENT 'Признак \"Писатель\"' ,
11. Добавлена таблица NAVY_SOURSES (Источники информации (книги, сайты...))
`id` INT(11) NOT NULL AUTO_INCREMENT ,
`title` VARCHAR(255) NOT NULL ,
`url` VARCHAR(150) NULL ,
`id_author` INT(11) NULL ,
`id_author2` INT(11) NULL ,
`id_author3` INT(11) NULL ,
`id_author4` INT(11) NULL ,
`id_author5` INT(11) NULL ,
`note` TEXT NULL ,
12. Добавлена таблица NAVY_REFERENCES (Ссылки на источники информации)
`id` INT(11) NOT NULL AUTO_INCREMENT ,
`article_type` INT(1) NOT NULL COMMENT 'Тип ссылающейся статьи (Проект, Персона, Система...)\n' ,
`id_article` INT(11) NOT NULL COMMENT 'ID статьи (материала)' ,
`id_sourse` INT(11) NOT NULL COMMENT 'ID источника' ,
`note` TEXT NULL COMMENT 'Примечание' ,
`hotlink` VARCHAR(150) NULL COMMENT 'Ссылка на страницу интернет-источнка' ,
Несколько комментариев к v.003 "человеческим" языком:
1. Добавлен каталог фотографий с привязкой к кораблю/морской_системе/персоне. Возможно использование всех трёх привязок сразу (если сюжет фотографии/изображения того требует).
2. Добавлены таблицы для хранения источников информации (таблица авторов, таблица источников, таблица ссылок на источники с привязкой к статье каталога).
3. Персоналии вынесены в отдельную таблицу.
Таким образом, если всё сложится хорошо - то будет четыре взаимосвязанных справочника:
- "База данных по кораблям"
- "База данных по морским системам (вооружения, корабельные системы)"
- "База данных по военно-морским частям и соединениям"
- "База данных по персоналиям"
Можно также "углубить и расширить" такие направления как "Судостроительные заводы" и "Порты и военно-морские базы".
Жду ваши замечания и пожелания. Не стесняйтесь!
1. Добавлен каталог фотографий с привязкой к кораблю/морской_системе/персоне. Возможно использование всех трёх привязок сразу (если сюжет фотографии/изображения того требует).
2. Добавлены таблицы для хранения источников информации (таблица авторов, таблица источников, таблица ссылок на источники с привязкой к статье каталога).
3. Персоналии вынесены в отдельную таблицу.
Таким образом, если всё сложится хорошо - то будет четыре взаимосвязанных справочника:
- "База данных по кораблям"
- "База данных по морским системам (вооружения, корабельные системы)"
- "База данных по военно-морским частям и соединениям"
- "База данных по персоналиям"
Можно также "углубить и расширить" такие направления как "Судостроительные заводы" и "Порты и военно-морские базы".
Жду ваши замечания и пожелания. Не стесняйтесь!
Serge_Kuzmin> Можно также ...."Судостроительные заводы" и "Порты и военно-морские базы".
ИМХО,было бы не плохо,особенно по заводам...
Serge_Kuzmin> Жду ваши замечания и пожелания. Не стесняйтесь!
проделанная работа впечатляет ....
ИМХО,было бы не плохо,особенно по заводам...
Serge_Kuzmin> Жду ваши замечания и пожелания. Не стесняйтесь!
проделанная работа впечатляет
....
Capt(N)> проделанная работа впечатляет ....
Кэп, спасибо за оценку Правда должен сказать что это примерно 2-3% от объёма всей задачи
Так что лучшее - впереди.
Serge_Kuzmin>> Можно также ...."Судостроительные заводы" и "Порты и военно-морские базы".
Capt(N)> ИМХО,было бы не плохо,особенно по заводам...
ОК, буду прорабатывать уже на практике, в первую очередь заводы (туда же войдут и КБ).
Пока подожду, может кто-то ещё выскажется.
....Кэп, спасибо за оценку
Правда должен сказать что это примерно 2-3% от объёма всей задачи Так что лучшее - впереди.
Serge_Kuzmin>> Можно также ...."Судостроительные заводы" и "Порты и военно-морские базы".
Capt(N)> ИМХО,было бы не плохо,особенно по заводам...
ОК, буду прорабатывать уже на практике, в первую очередь заводы (туда же войдут и КБ).
Пока подожду, может кто-то ещё выскажется.
Serge_Kuzmin> Пока подожду, может кто-то ещё выскажется.
Я б высказался, да "не понимаю я по-вашему нихрена" (с)
Я б высказался, да "не понимаю я по-вашему нихрена" (с)
Serge_Kuzmin>> ...может кто-то ещё выскажется.
Вованыч_1977> Я б высказался, да "не понимаю я по-вашему нихрена" (с)
Так высказывайтесь "по-своему"!))
Интересуют в том числе и пожелания с точки зрения пользователя.
Я вообще планирую сделать страничку с задачами проекта, начиная от чего-то типа "миссии" в пару абзацев, и до перечня возможностей каталога. Вывешу это как статическую страничку-"знамя" и будем "туда" стремиться.
Вованыч_1977> Я б высказался, да "не понимаю я по-вашему нихрена" (с)
Так высказывайтесь "по-своему"!
))Интересуют в том числе и пожелания с точки зрения пользователя.
Я вообще планирую сделать страничку с задачами проекта, начиная от чего-то типа "миссии" в пару абзацев, и до перечня возможностей каталога. Вывешу это как статическую страничку-"знамя" и будем "туда" стремиться.
Serge_Kuzmin>> Пока подожду, может кто-то ещё выскажется.
Вованыч_1977> Я б высказался, да "не понимаю я по-вашему нихрена" (с)
и я Вована поддерживаю..нефига непонять..хоть какой график или обзац покажите..
чтоб было все удобоворимо..
Сергей дай одну любую страничку...как из книги тогда будет понятно..
Вованыч_1977> Я б высказался, да "не понимаю я по-вашему нихрена" (с)
и я Вована поддерживаю..нефига непонять..хоть какой график или обзац покажите..
чтоб было все удобоворимо..
Сергей дай одну любую страничку...как из книги тогда будет понятно..
Дорогу осилит идущий.
Анатолий> и я Вована поддерживаю...
Анатолий> Сергей дай одну любую страничку...как из книги тогда будет понятно..
ОК Следующий этап - практическая реализация. Будет вам страничка! Много!
Анатолий> Сергей дай одну любую страничку...как из книги тогда будет понятно..
ОК
Следующий этап - практическая реализация. Будет вам страничка! Много!
- Capt(N) [15.12.2010 12:59]: Перенос сообщений в Амурская флотилия ВМФ
starpom176
новичок
Молодцы парни, создавайте базу. Вражеская разведка отдыхает и ждет ваших трудов. Хотя, уверен, на основании ваших отзывов и фото, они уже давно такую базу создали
Вопрос к землякам. А скажем по американскому, английскому,тому же турецкому флоту кто то проводит в инете такие исчерпывающие исследования? Если да,подскажите где почитать?
Реклама Google — средство выживания форумов :)
max81> Вимпел очень хороший справочник, жаль что у нас такого нет
есть идея сделать справочник и на Балансере http://navy.balancer.ru/catalogue/ но пока не реализована...
есть идея сделать справочник и на Балансере http://navy.balancer.ru/catalogue/ но пока не реализована...
Copyright © Balancer 1997..2018
Создано 25.04.2009
Связь с владельцами и администрацией сайта: anonisimov@gmail.com, rwasp1957@yandex.ru и admin@balancer.ru.
Создано 25.04.2009
Связь с владельцами и администрацией сайта: anonisimov@gmail.com, rwasp1957@yandex.ru и admin@balancer.ru.
