Сделаем наш ресурс по дип-скаям!

[Pluto]

>>Мне кажется, что в предложенная shandrik-ом система таблиц не очень удачна - слишком громоздка, что-ли?

Она просто чудовищно громоздка.
По моему, от наблюдателя требуются следующие данные:

1. Ник (или ФИО).
2. Место наблюдения (Область, город, село широта наблюдения, долгота по желанию).
3. Дата и местное время наблюдения. Юлианская дата совершенно не нужна, т.к. ее основное назначение – точное измерение промежутка времени между двумя событиями (наблюдениями), что в случае Deep Sky не актуально.
4. Апертура и относительное отверстие телескопа. Тип (производитель, монтировка и т.п.) по желанию.
5. Применяемое увеличение, применяемые фильтры (характеристики окуляров – по желанию).
6. Состояние атмосферы (ясно, дымка, бегущие облака и т.п.), положение Луны, предельная звездная величина. Температура, влажность и т.п. по желанию.
7. Собственно описание объекта. Описание ИМХО должно состоять из обязательной и произвольной частей. В обязательной указывается относительная яркость объекта, форма, богатство скопления и т.д. (здесь есть предмет для обсуждения). В произвольной части, наблюдатель высказывает свои дополнения, ассоциации, проблемы с поиском объекта, оценку “эффектности” и т.п.
8. Зарисовка объекта, если наблюдатель их делает.

Категорически против поисковых карт и тем более фотографий.

Сама база данных объектов должна быть заготовлена заранее и должна содержать номер по каталогу (за основу взять NGC и IC), тип объекта, созвездие, координаты, блеск, размеры, поверхностную яркость, позиционный угол для галактик, альтернативное название, желательно описание Дрейера.

И еще, вопрос к инициаторам. Как будет обеспечиваться достоверность факта наблюдения в таком общедоступном проекте, ведь у некоторых “наблюдателей” может возникнуть соблазн списать чужое описание, не утруждая себя наблюдениями.
Как будет обеспечиваться равномерность данных по объектам. Неизбежно накопление огромного массива данных по легким, популярным объектам (М31,М13 и т.п.) и дефицит данных по слабым, трудным объектам (коих подавляющее большинство).

[shandrik]

Начнем обсуждение.
Прошу относиться к моим ответам не как к придиркам с целью продвинуть мои идеи.
Ведь это самое начало проекта, просто макет, будем вместе его улучшать.

Мне кажется, что в предложенная shandrik-ом система таблиц не очень удачна - слишком громоздка, что-ли?
t_manufacturer - влияние производителя инструмента на вид конкретного дипа много меньше, чем уровня засветки на месте наблюдения и скорости ветра. Зачем тогда усложнять себе жизнь? Мы ведь не инструментами собираемся меряться, а впечатлениями от дипов.

...

t_country и t_city - не думаю, что нужны, полноценный справочник по городам и странам не организовать все равно для описания наблюдателя достаточно пары соответсвующих строковых полей

Кроме главного назначения проекта - быстрого доступа к описанию нужного объекта, можно будет получить очень интересную статистическую информаци. Простым запросом можно увидеть распределение по наблюдателей по странам и городам. Нагляднейший пример - я случайно наткнулся на сайт "Астрономия в Новосибирске" Маслова Михаила. Написал ему письмо. И что вы думаете - живет он в 15-20 минутах ходьбы от моего дома и мы теперь вместе наблюдаем. "Это же урбанизация, какая-то!.." (с) Ахиджакова.
Можно сделать выборку по инструменам/изготовителям и, с учетом скилла наблюдателя, сделать вывод об их пригодности для своих нужд в свете дальнейшей покупки. Вообще тут такой простор для статистики - аж дух захватывает.

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

Окуляр окуляру рознь, я полагаю, это не надо объяснять. Как минимум, ещё поле нужно, т.к. Аш и Хи Персея в 40-градусный Плессл НПЗ и 68-градусный Паноптик того же фокусного расстояния - чуть ли ни разные объекты.

t_filters и t_filters_type - соображения аналогичное вышеприведенному, помноженное на редкость применения фильтров (достаточно одного опционального поля в таблице наблюдений)

А много ли, скажем, Телевьюшных окуляров было у местного населения год назад? А сейчас? Растем, ребята, обзаводимся хорошими аксессуарами. Думаю, фильтры скоро будут гораздо более распространенными. Эффект от них велик, и будущие наблюдатели смогут выбрать, что именно им нужно. Вот если бы мы не отказывались зарисовывать увиденное...

t_telescopes, t_telescope_type, t_mount и t_mount_type - много данных которые неважны для понимания условий наблюдения но мало для полноценного review. Достаточно одной таблицы, где хранится знач. апертуры, ссылка на владельца и опионально относительное отв., производитель (строка), схема (строка), описание особенностей (текст), линк на подробное описание или даже таблица линков со ссылкой на t_telescopes.

Насчет t_mount я уже говорил, что не уверен в её нужности, но вот конкретный инструмент указать, мне кажется, стоит. Вот как только быть с самодельными телескопами?  
Изготовитель должен быть в отдельной таблице - как Вы себе представляете заполнение базы в противном случае. Появятся записи с "МИД", "MID", "MEAD", "MEADE". Нет, все должно выбираться из справочников, которые можно сделать за пару дней.

t_observer - таблица чрезмерно усложнена (см. данные по участнику этой конференции)

Возможно, но см. выше. Иногда эти данные могу пригодится.

(t_country не содержит ничего, кроме своего названия, t_city еще и координаты независимо от того, где наблюдает observer),
...
t_observ_place - полезная таблица хотя и чрезмерно детализированная, достаточно, наименования, высоты над уровнем моря, описания и опциональных координат

Ой! Я не туда широту и долготу вставил
Я же хотел не в t_city, а в t_observ_place - им там место.

t_object - должна быть дополнена таблицей ссылок на внешние данные, каждая запись которой ссылается на соотв. запись в t_object

Не понял, поясните, пожалуйста.

t_object_type, t_object_subtype - избыточны, достаточно соотв. строкового поля в t_object

Я - за атомарность! Зачем дублировать текстовые поля в обной таблице, если можно разнести?

t_search_map - просто пара ключей - ссылка на t_object и линк на интернет-ресурс с опциональным описанием

Тоже не понял.

t_observ_session - обычная календарная дата обязательно, юлианская дата - опционально, дополнить ссылкой на инструмент

Разумеется, пользователь будет видеть (и вводить) календарную дату. Встроенная функция будет конвертить дату в нужный формат. Очень удобно, что за ночь наблюдения целая часть юлианской дате не меняется.
А насчет инстрмента - их может быть и не один, т.ч. инструменту место в t_observ.

t_observ - JD - можно отбросить, дипы довольно малоизменчивы - достаточно даты в t_observ_session и, возможно, дополнения к описанию в виде засечки момента времени, если это потребуется

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

[shandrik]

>>Мне кажется, что в предложенная shandrik-ом система таблиц не очень удачна - слишком громоздка, что-ли?

Она просто чудовищно громоздка.
По моему, от наблюдателя требуются следующие данные:

Борис, так только эти данные и будут вводить наблюдатели. Все остальные будут поставляться(справочники), либо вводятся при установке клиентской части: дефолтное место наблюдения, будет первым в справочнике таких мест, данные о наблюдателе. Надо бы с помощью спецполей пометить имеющееся оборудование и аксессуары, чтобы пользователь, по умолчанию, выбирал только из них.
Результаты наблюдений будут вводится следующим образом.
Описываем сессию - дата, время, погоду. Если место отлично от дефолтного - выбирается.
Собственно наблюдение: Выбирается объект, если инструмент отличается от дефолтного, то он выбирается, выбирается окуляр, фильтр (если он есть). Вводится описание - Вы правильно разбили на обязательное и произвольное. Итого - пяток кликов на попуп-менюшках и заполнение текстового поля описания. Не смотрите на громоздкость базы - она будет скрыта от пользователя и не помещает его работе, а вот хорошо структурированная структура сделает базу прозрачной и масштабируемой.

Категорически против поисковых карт и тем более фотографий.

Но почему??? Без фотографий обойтись можно, но карты-то будут очень полезны.

Сама база данных объектов должна быть заготовлена заранее и должна содержать номер по каталогу (за основу взять NGC и IC), тип объекта, созвездие, координаты, блеск, размеры, поверхностную яркость, позиционный угол для галактик, альтернативное название, желательно описание Дрейера.

Как раз все это я и привел в t_object

И еще, вопрос к инициаторам. Как будет обеспечиваться достоверность факта наблюдения в таком общедоступном проекте, ведь у некоторых “наблюдателей” может возникнуть соблазн списать чужое описание, не утруждая себя наблюдениями.
Как будет обеспечиваться равномерность данных по объектам. Неизбежно накопление огромного массива данных по легким, популярным объектам (М31,М13 и т.п.) и дефицит данных по слабым, трудным объектам (коих подавляющее большинство).

Новое поле moderator_level в t_observ будет иметь дефолтное значение "Ноль", и будет меняться координаторами-модераторами, дабы удалять хулиганские выходки и выставление уровня ценности. На клиентской части будет стоять ответный параметр, управляющий выводом записей, отробажая их в соответствии с желанием пользователя. Пока стоит "0" запись доступна только модераторам.

[shandrik]

Комментарии:

t_eyepieces и t_eyepieces_type, t_filters и t_filters_type, t_telescopes и t_telescopes_type, t_mount и t_mount_type  руки чешутся объединить. Не надо структуру приводить к 5 НФ  

Что такое 5 НФ?
Обилие справочников не будет мешать, наоборот поможет стандартизировать базу.

Честно говоря, не совсем понятно зачем использовать t_object_type и t_object_subtype - типичные "слабые сущности", гораздо проще и понятнее использовать отдельные поля в t_object типа:
type - тип объекта (GALXY,OPNCL,GLOCL,PLNNB,BRTNB,DRKNB и пр.)

Я категорически против дублирования текстовых полей - только ссылки. ЕЩЁ РАЗ ПОВТОРЯЮ - ЭТО НЕ НАПРЯЖЕТ, НЕ УСЛОЖНИТ БАЗУ, а сделает её структурированней.

class - класс объекта в соответствии с общепринятой классификацией

Ой, а что под классом подразумевается?

[Doof]

Что такое 5 НФ?
Обилие справочников не будет мешать, наоборот поможет стандартизировать базу.

Советую почитать
http://oralib.h1.ru/ora1/oraclepr_04.htm

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

Я категорически против дублирования текстовых полей - только ссылки. ЕЩЁ РАЗ ПОВТОРЯЮ - ЭТО НЕ НАПРЯЖЕТ, НЕ УСЛОЖНИТ БАЗУ, а сделает её структурированней.

А где дублирование-то? Каждому объекту однозначно соответствует его тип. А все отношения 1:1 в теории БД обычно сводятся к одной таблице.
Еще раз повторю, совсем не обязательно хранить все списки в виде отдельных таблиц, тем более, если размерность этих списков заранее известна.

Ой, а что под классом подразумевается?

Ну, скорее классификация: SBa или IV 2 n и пр.

[shandrik]

Советую почитать
http://oralib.h1.ru/ora1/oraclepr_04.htm

Спасибо за ссылку! Как раз сейчас с Ораклом разбираюсь.

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

Здрассте. А я про что? Я же говорю - распределившись, делаем справочники за пару дней. Сайты известны, нужные параметры доступны. В чем проблема-то? Я за субботнее дежурство могу сделать базу окуляров и телескопов. Дежурства на это не жалко. С фильтрами и монтировками (так нужны они или нет?) пусть более знающие разбираются.

Я категорически против дублирования текстовых полей - только ссылки. ЕЩЁ РАЗ ПОВТОРЯЮ - ЭТО НЕ НАПРЯЖЕТ, НЕ УСЛОЖНИТ БАЗУ, а сделает её структурированней.

А где дублирование-то? Каждому объекту однозначно соответствует его тип. А все отношения 1:1 в теории БД обычно сводятся к одной таблице.
Еще раз повторю, совсем не обязательно хранить все списки в виде отдельных таблиц, тем более, если размерность этих списков заранее известна.

Про известную размерность списков, похоже, правильное замечание.
Но меня раздражает запись "ШарСкопл", когда можно поставить красивую и приятную глазам субэдэшника единицу или двойку Единообразие, доведенное до безобразия и есть порядок!

[Doof]

Shandrik! Если ты СУБДшник, ты должен понимать, что нет ничего приятнее для программиста, как все данные в ОДНОЙ таблице. А по поводу избыточности... нельзя же все доводить до абсурда. Ну какая может быть избыточность в таблице с отсилы 20000 записей (это я про объекты)? Гораздо важнее актуальность и непротиворечивость этих данных.
А всякие там GALXY и OPNCL (или Glx и Ocl) это общепринятые сокращения.



 

[Ernest]

>Что такое 5 НФ?

5-ая нормальная форма. То есть высшая (почти) степень нормализации таблиц базы данных. Очень хороша для реализации быстрых транзакция типа Insert/Update, но существенно тормозит при запросах типа Select/Delete. Обычно строгая нормализация вредит проектам типа Datamarts/Datawarehouse. В нашем случае мне такое обилие справвочных таблиц так-же кажется излишним. Однако, если есть амбиции замахнуться на большее, чем просто базы данных отечественных наблюдений дипов. Скажем - создать базу обзоров инструментов, окуляров, проч. аксессуаров. Я не думаю, что это целесообразно - она по количеству записей не сможет конкурировать с Excelsis и просто будет непредставительной.

>Обилие справочников не будет мешать, наоборот поможет стандартизировать базу.

Зачем? Оттого, что кто-то ошибется в название и напишет в описании своего инструмента Mid вместо Meade, как это повлияет на главное - описание дипа?

>Я категорически против дублирования текстовых полей - только ссылки. ЕЩЁ РАЗ ПОВТОРЯЮ - ЭТО НЕ НАПРЯЖЕТ, НЕ УСЛОЖНИТ БАЗУ, а сделает её структурированней.

Зачем ей в нашем случае быть "структурированней"? Какая от этого польза? (На всякий случай замечу, что участвовал в разработке многих баз данных, в том числе и для таких заказчиков, как Simens.)
Что касается "НЕ НАПРЯЖЕТ" - то это не так, именно напряжет, во-первых, программиста (а каким ресурсом мы здесь располагаем, пока не известно), но отчасти и пользователя. Тут и прописывание реляционной целостности с которой у MySQL не все просто, и усложнение форм on-line ввода, и требование предварительного импорта более свежих справочников на клиента для удаленного заполнения. Пополнение этих справочников...

>Без фотографий обойтись можно, но карты-то будут очень полезны.

Присоединяюсь - опциональные ссылки на графику по объекту (и карты, и фотографии) должны быть предусмотрены. Если их вынести в отдельную таблицу, то они ни как не будут усложнять таблицу t_object.

>Простым запросом можно увидеть распределение по наблюдателей по странам и городам.

Запрос только упростится, если название города/страны ввести как текстовые поля в t_observer.

>Вообще тут такой простор для статистики - аж дух захватывает.

Которой может поиграть те несколько человек, кто имеет доступ непосредственно к базе данных. Однако не стоит забывать, что ради этого удовольствия придется усложнить импорт/экспорт/ввод данных, что в свою очередь существенно увеличит объем работы программистов и усложнит жизнь всем потенциальным участникам/пользователям проекта.

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

Это все так, только 90% наблюдений дипов (в том числе и у НИХ) производится без использования фильтров. А в случае использования вполне достаточно, как мне кажется, упомянуть в описании, эффект применения, скажем, UHC от Lumicon. То есть фильтр добавляет такие-то детали, а без фильтра лучше видны такие-то. Другими словами, фильтр это не атрибут наблюдения, а один из нескольких приемов наблюдения, типа покачивания трубы, бокового зрения, игры увеличениями. Эти приемы не исключают, а взаимодополняют друг друга, в одном визуальном наблюдении они могут быть использованы в комплексе - это не фотография.

>>t_object - должна быть дополнена таблицей ссылок на внешние данные, каждая запись которой ссылается на соотв. запись в t_object

>Не понял, поясните, пожалуйста.

t_object не должна содержать ссылку на графику, должна быть таблица t_object_external_link с полями t_object_ref (ссылка на запись в t_object), link (полная интернет ссылка на графические или текстовые материалы). Можно добавить поле с указанием типа ссылки (поисковая карта, фотография, рисунок, описание). Ссылка может быть как внешней, так и на графический материал хранящийся в базе данных.

Аналогично можно поступить с t_search_map.

[Doof]

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

Здрассте. А я про что? Я же говорю - распределившись, делаем справочники за пару дней. Сайты известны, нужные параметры доступны. В чем проблема-то? Я за субботнее дежурство могу сделать базу окуляров и телескопов. Дежурства на это не жалко. С фильтрами и монтировками (так нужны они или нет?) пусть более знающие разбираются.

А каким образом знание монтировки, на которой установлен телескоп, может помочь начинающим любителям наблюдений дип-скай? Есть очень большое подозрение, что большинство наблюдений будет сделано на самодельных Добсонах или на немецких монтировках, используемых в "добсоновском режиме".  
Да и информация по фильтрам мне кажется не столь существенна...

А вот по окулярам интересный справочник может получиться... еще бы хорошо сравнить "рекламные" значения c реальными.

[shandrik]

Мне надо подумать над Вашими доводами, Ernest. Они мне кажутся правильными.
Беру денек-другой тайм-аута.

[Роман Чириков]

 Ребят, по-моему вы всё слишком усложнили со структурой проекта.
Не проще ли сделать механизм вывода всей имеющейся информации по данному объекту на одной странице, где будут и фотографии, и рисунки (ну их можно и нужно представить как thumbnails), и абзацы, начинающиеся со слов "а в 150-мм телескоп это выглядит так...".
Информацию сделать обновляемой любыми пользователями с проверкой доверенных лиц.
И всё! Будет динамично, не так трудно и полезно. Не понадобятся всякие поисковики, и т.д.

Кто согласен - поднимите руку!

Я бы это сделал, да вот в школу иду...

[Belatrix]

Прилагаю свой вариант. На авторство Шандрика не претендую, я всего лишь удалил из его структуры лишнее на мой взгляд.

По поводу Access. Я его тоже не люблю, на работе используем SQL Server, но в данном случае речь идет только о локальной БД и движке, а сам клиент может быть на дельфях, которые я очень уважаю и имею огромный опыт (8 лет, огромный проект - система контроля и управлением доступа, обслуживающая многие наши АЭС и другие важные объекты). Так что какую-то часть клиента я реализовал бы (как это принято говорить, на высоком профессиональном уровне), жаль времени в обрез мало, но что успею - сделаю, так что Шандрик обращайтесь.

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

Иначе мне кажется игра свечь не стоит - узкопрофильная база сама по себе неинтересна.

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

[shandrik]

Вечерком я обдумал высказанное и вот что решил.

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


1. Удалил таблицы t_object_type и t_object_subtype. Новых типов и подтипов не предвидится, кроме того, таблица t_object будет сделана одинажды и навсегда, только редактирование без добавлений, т.е. ошибок типа Mid не будет, т.ч. пишем тип и классификацию объекта прямо в t_object.
2. По этим же причинам удалена таблица t_constellation и замена сылки в t_object на два строковых поля constell_rus и constell_lat.
3. Удалены таблицы t_city и t_country, в t_observer удалены поля city, country, которые заменены строковым полем residence пусть наблюдатель сам пишет, где живет.
4. Из t_observer удалено поле фамилии наблюдателя surname - фамилию занесем в observer_name.
5. Удалены таблицы t_mount и t_mount_type и соответствующее им поле id_mount из t_observ.
6. Удалены таблицы t_filters и t_filter_type и поле id_filter из t_observ. Я все больше склоняюсь к дополняемости наблюдений с фильтром и без, а не взаимоисключение разнесением в разные записи, предполагается отмечать это в описании.
7. Удалено поле JD из t_observ – Луну и высоту объекта наблюдатель сам опишет, при необходимости.
8. Два "лунных поля" в t_observ_session объеденены в одно описательное Moon.
9. Удалены сомнительные поля посадочного диаметра и линейного поля окуляра.
10. Удалена таблица t_eyepieces_type и ссылка на неё в t_eyepieces.
11. Удалено поле id_manufacturer из t_eyepieces. Фирму-изготовителя указываем в eyep_name (Celestron Ultima 18mm).
12. Удалил-таки t_manufacturer, но надо договориться, как и где описать телескопы. Не хочется терять тип телескопа.
13. Удалено поле object_altitude из t_observ.


Итого, удалена большая половина таблиц – из 20 осталось 9  


Приписка на первом листе написана моей женой, пока я курить выходил. Решил не убирать - может это будущее имя проекта?



А куда у нас Vitaly пропал – все ещё ангина мучает? Но больше всего меня беспокоит молчание Андрея Остапенко.

[shandrik]

Вот хотел же вчера попросить-предупредить - не надо её в компьютерный раздел переносить. Столько потенциальных участников-наблюдателей потеряем.  

Ну ладно, как с базой разберемся и будет готов бланк, заведу новую тему в наблюдениях.

[shandrik]

Прилагаю свой вариант. На авторство Шандрика не претендую, я всего лишь удалил из его структуры лишнее на мой взгляд.

Я обошелся с базой гораздо более жестоко
Изначально большое число таблиц явилось следствием опыта работы с бухгалтерами-материальщиками, которые при возможности произвольного доступа быстро приводят базу в нечитабельное состояние - возможность агрегации по не ключевым полям становится невозможным. Я давал им править только справочники - если и ошибутся, то агрегирование все равно будет доступно. А у нас справочники непополняемые, т.ч. соглашаюсь со здравым смыслом.

обслуживающая многие наши АЭС и другие важные объекты). Так что какую-то часть клиента я реализовал бы (как это принято говорить, на высоком профессиональном уровне), жаль времени в обрез мало, но что успею - сделаю, так что Шандрик обращайтесь.

Это не опечатка - АЭС - не АЗС?
Обратимся, конечно.

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

Есть такое опасение, конечно. Надо не давать народу расслабится и перенос темы может отрицательно сказаться на перспективах. Я, например, раз в месяц в этом разделе бываю.

[Doof]

Леня! Хватит делать что попало! (с)  

Объясни мне, зачем нужен t_telescope_type? Почему нельзя в t_telescope указать, например:

"ТАЛ 100Р", 100, 1000, "Рефрактор ахромат", "НПЗ" или
"Супер Доб", 1000, 5000, "Рефлектор Ньютона","сам сделал"...

Для t_observ_place предлагаю оставить

id
city (ближайший, если место наблюдения - дер. Гадюкино)
country
longitude (может и не надо)
latitude
max_mag (опытным путем установленная максимально доступная зв. величина в зените в самые лучшие ночи)
description (вот туда можно запихать все, что угодно)

В t_object  спорное поле "созвездие по-русски", лучше отдельный справочник сделать, кому надо посмотрит, а то явно 3Мб избыточности вылезает  

t_search_map - пока не ясно

t_observ_session - необходимость выглядит сомнительной. Дату, луну и погоду можно спокойно запихать в t_observ (придумать кодификаторы), а также lm - limited magnitude (либо в зените, либо в точке местоположения наблюдаемого объекта, есть разница!).



 
 

[shandrik]

Я сегодня целый день общался с банкоматом №13 и мне сегодня уже ничего не хочется. Вернее хочется только в ванну и спать. Поэтому отвечу кратко.

Леня! Хватит делать что попало! (с)  

Объясни мне, зачем нужен t_telescope_type? Почему нельзя в t_telescope указать, например:

Эта таблица - следующая, на мой взгляд, которая попадет под сокращение. Но это только на мой взгляд, а мне не нравится одному делать дело, которое будет полезно многим - как я уже говорил. Мы вместе должны обсуждать базу. Вчера особых претензий к этой таблице не было, вот она и пережила ночь. Я ещё раз взвешу - я ещё не решил, насколько будет важно относительное отверстие, а так я согласен на указание телескопа прямо в t_observ.

Для t_observ_place предлагаю оставить

id
city (ближайший, если место наблюдения - дер. Гадюкино)
country
longitude (может и не надо)
latitude
max_mag (опытным путем установленная максимально доступная зв. величина в зените в самые лучшие ночи)
description (вот туда можно запихать все, что угодно)

Это для меня самая туманная таблица - пока считаю, что координаты не нужны, можно обойтись просто расстоянием от засвечивающего города и высотой, но это можно заменить предельной величиной (я сначала об этом не подумал), но не всякий её знает. Я может все-таки собирусь на Алтай через неделю, так я пока не знаю звезд 6,5-7 величины.

В t_object  спорное поле "созвездие по-русски", лучше отдельный справочник сделать, кому надо посмотрит, а то явно 3Мб избыточности вылезает  

На 3МБ можно закрыть глаза - они перекрываются быстротой (не надо вязаться к ещё одной таблице). Если мы не собираемся прицеплять в перспективе двойные, то пусть будет в t_object.

t_search_map - пока не ясно

Ну так давайте обсудим. Вот только зря тему сюда перенесли, итак наблюдателей-несубдшников распугали, а теперь они вообще про проект забудут

t_observ_session - необходимость выглядит сомнительной. Дату, луну и погоду можно спокойно запихать в t_observ (придумать кодификаторы), а также lm - limited magnitude (либо в зените, либо в точке местоположения наблюдаемого объекта, есть разница!).

Обдумаю, но не сегодня.

P.S. Спасибо тебе, Саша.

[Belatrix]

Это не опечатка - АЭС - не АЗС?
Обратимся, конечно.

Ну что же вы меня с грязь-ю то сравниваете! АЭС, а про другие объекты я вам даже говорить боюсь - государственная тайна.

[shandrik]

Это не опечатка - АЭС - не АЗС?
Обратимся, конечно.

Ну что же вы меня с грязь-ю то сравниваете! АЭС, а про другие объекты я вам даже говорить боюсь - государственная тайна.

Извините, это было без злого умысла - неудачная шутка усталого человека.

Вот и Эрнест пропал...

[Ernest]

Не дождетесь!

По новой структуре таблиц. Пора уже определяться с ключевыми полями (имеется ввиду так называемые альтернативные ключи) и пометить опциональные  - без этого не все понятно.

t_Eyepieces   - это что? справочник по окулярам или список всех окуляров в наличности и наблюдателей? Если справочник окуляров (то есть 5 мм Meade 4000 серии будет присутствовать как одна запись), то нужна еще одна таблица связывающая владельца с окуляром - там можно разместить отзыв, да и при выборе окуляра с которым шло наблюдение не будет вываливаться комбо-бокс на несколько сотен позиций. Добавить поле описания (ну типа есть резиновый наглазник, исполнение для гидирования с сеткой и т.п.), а так-же, раз пошла такая пьянка, поля с размером посадки, весом, габаритами.

t_Eyepieces.id_eyepieces   integer   - рекомендую заменить ключи string и забивать чем-то более менее понятным типа 5meade4000 (5 мм Meade 4000 серии) - это не сильно скажется на задержке запросов, но облегчит работу с дампами данных и ручной работой по коррекции базы etc.
     
t_telescopes - аналогичное t_Eyepieces замечание, если это справочник моделей, то нужна таблица связи наблюдателя с телескопом, если таблица экземпляров, то нужно поле развернутого описания и foreign key на наблюдателей. Добавить текстовое поле описания.

t_telescopes.id_telescope   integer   - заменить на string см. выше
t_telescopes.id_type_telescope   integer   - заменить на string см. выше
     
t_telescope_type - добавить описание (ну там кома не исправлена, хроматизм положения огранияивает качество на оси и т.п.)
     
t_observer - может быть добавить ICQ
t_observer.id_observer   заменить на строку (nick, может совпадать со Звездочетовским), см. выше
t_observer.Sex   boolean   - можно выбросить, во всяком случае должен принимать три значения - не указан/муж/жен
t_observer.www_observer - поскольку далеко не у всех есть, а у некоторых сайтов несколько, то лучше ввести отдельную таблицу t_observer_external_links где можно по каждому наблюдателю добавить линков на любимый сайт, на домашнюю станичку, фотографию в кругу семьи, в обнимку с телескопом и т.д.
     
t_observ_place - полезная таблица. Должно быть название, высота над уровнем моря, тип площадки (центр города, окраина, поселок-дача, равнина вдали от города, горы...), тип засветки (городская со всех сторон, сильная локальная, слабая от населенных пунктов за горизонтом...), оценка качества, описание и опционально - координаты. Должна так-же быть таблица связи наблюдателя и места наблюдения, а так-же t_place_external_links со ссылками на фотографии и более развернутое описание

t_observ_place.id_observ_place   заменить на string (или если угодно краткое название), см. выше
     
t_object.id_object - перевести в string типа NGC1234 или M21, см выше
m_name,   ngcic_name, another_name - думаю лучше заменить на пару полей - имя каталога (NGC, M, IC, PK...) и ID (13, 1223, 8953, 12-3-5) - оба текстовые, можно дополнить еще и парой ссылок на альтернативный каталог (почти все из Месье входят в NGC)
t_object.Size1, Size2 - хранить в минутах или даже секундах
t_object.interesting - впечатление по 10 бальной шкале, ОК
t_object.photo - выбросить в отдельную таблицу внешних ссылок t_object_external_link: три обязательных поля - ссылка на объект, гиперссылка, тип ссылки (поисковая карта, фотография, рисунок, описание...) и опционально - описание
     
t_search_map -  можно отбросить, если будет t_object_external_link

t_observ_session - нет поля длительности наблюдений, тектового описания и ссылки на основной инструмент

t_observ_session.JD_observ - не удобна при ручной работе и расшифровке дампамов базы данных, думаю стоит заменить на календарную дату начала наблюдений
     
t_observ.id_observ integer - просто порядковый номер наблюдения в сессии (часть составного ключа)
t_observ.id_telescope - опционально (см. телескоп сессии)
t_observ.observ_object_descript_lyric - скорее уместно в таблице наблюдательных сессий