Есть задача хранить различные метеорологические данные — температуру, давление, влажность, ветер и т.п.
Для простоты все эти данные я буду перечислять списком <measures>.
Данные привязаны к определенным точкам; в разных местах города могут быть разные погодные условия. При получении метеорологических данных для определенных координат будет выбираться наиболее близкая точка, возможно будет использоваться интерполяция некоторых данных.
Какой вариант таблицы с измерениями вы бы выбрали?

location_id, datetime, <measure>
Предполагается, что будет использоваться таблица мест измерений locations и подчиненная таблица измерений measures с указанными полями. Каждое измерение привязано к своему месту измерения. Но если вдруг происходят изменения с местами измерений (добавляется новое или убирается существующее), то нужно эти изменения отразить в таблице locations и возможно обновить таблицу measures. С другой стороны, при таком подходе для мест измерения можно хранить дополнительную информацию (класс точности, контактная информация и т.п.).


latitude, longitude, datetime, <measure>
Место измерения фиксируется непосредственно в таблице измерений. Часть данных в таблице может дублироваться (одинаковые координаты), однако при таком способе добавление или удаление места измерения будет происходить очень просто (если добавляется или удаляется метеорологическая станция, то никаких подготовительных процедур делать не нужно). Дополнительная информация по метеорологическим станциям будет храниться в отдельной таблице, напрямую никак не связанной с таблицей измерения (FK по полям latitude,longitude не используется).


latitude, longitude, range, datetime, <measure>
То же, что предыдущий пункт, но для измерения дополнительно указывается "радиус действия", в котором результаты не нуждаются в интерполяции.

________________________
Мы смотрим с оптимизмом...
...в оптический прицел.

И еще пара попутных вопросов. БД пока не определена, но допустим это будет MSSQL.
1. Нужно ли заводить кластерный индекс по datetime?
2. Допустим, суррогатный первичный ключ применяться не будет. В каком порядке включать поля в PK? Или это не важно?

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

Да, я забыл рассказать о характере использования.
В базу ежечасно будут сохраняться результаты метеорологических измерений. Измерения принадлежат метеостанции, метеостанция имеет определенные координаты, в одном населенном пункте может быть несколько метеостанций. У метеостанции также имеется высота над уровнем моря (и теоретически, по одним координатам может быть несколько метеостанций с разной высотой).
Основные процедуры работы с БД: сохранение результатом измерений для определенной метеостанции в определенное время и получение результатов измерений с определенной метеостанции за указанный период.

softwarerДо тех пор, пока метеостанция не оборудована колёсами, второй-третий варианты представляются геморроем на пустом месте.
Ну почему же, сегодня открылась одна метеостанция, через полгода закрылась другая метеостанция.
Первый вариант, помимо усложнения сценариев работы (добавления новой метеостанции, если ее еще нет) добавляет лишний джойн в запросы. Во втором варианте координаты можно рассматривать как составной ключ, они ведь всегда будут задаваться парой.

softwarerЕсли задаться вопросом "как правильно и быстро выдавать информацию по погоде в указанной точке", то я бы завёл примерно следующую таблицу: longitude_from, longutude_to, latitude_from, latitude_to, location_1, location_2, location_3. Читается так: "для координат из этого квадрата использовать интерполяцию по данным следующих трёх станций (либо двух или одной, если некоторые не заданы".
Да, вариант интересный, подумаю над ним. Правда сектора лучше хранить в отдельной таблице, а в таблице интерполяций хранить поля sector_id,location_1,location_2,location_3. Но сложный в реализации, особенно запутанной будет процедура перераспределения секторов при добавлении новой метеостанции.

Alibek B.softwarerЕсли задаться вопросом "как правильно и быстро выдавать информацию по погоде в указанной точке", то я бы завёл примерно следующую таблицу: longitude_from, longutude_to, latitude_from, latitude_to, location_1, location_2, location_3. Читается так: "для координат из этого квадрата использовать интерполяцию по данным следующих трёх станций (либо двух или одной, если некоторые не заданы".
Да, вариант интересный, подумаю над ним. Правда сектора лучше хранить в отдельной таблице, а в таблице интерполяций хранить поля sector_id,location_1,location_2,location_3. Но сложный в реализации, особенно запутанной будет процедура перераспределения секторов при добавлении новой метеостанции.

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

MasterZivЯ бы с первого взгляда делал таблицы так:
(PK)==> attributes
===========================

(location_id)==>latitude, longitude, name
(measure_id)==> meagure_name, ...
(location_id, measure_id, datetime) ==> value
EAV когда без него легко можно обойтись?

Ennor Tiegael , приветствую, с перездом!
Отдельная подготовленная БД для статистики и аналитики пока не нужна, со временем выявится, как ее лучше реализовать.
Большая часть измерений (более 90%) будут иметь уникальные координаты, т.е. совпадающих по координатам метеостанций будет мало (если вообще будут). Но измерения ежечасные и каждый год каждая координата будет получать по 8К записей.

SERG1257То бишь у вас обычное OLTP приложение, а значит нормализуйте - база боится джойна не более чем еж голой задницы.
alexeyvgВы прислушайтесь к советам, тут всё таки форрум по проектированию БД. Не бойтесь лишних таблиц, могу вам сказать, что чем больше таблиц, тем проще будет писать код, легче поддерживать систему, да и работать всё это будет быстрее.

Понятно.
Спасибо за комментарии, склонился к первому варианту.
Второй вариант я думал использовать по той причине, что по сути пара координат latitude,longitude уже представляют собой составной ключ.