В двух словах, ваше приложение, в частности, гетерогенная структура сообщений , полученных от устройств GPS, подталкивает ваш дизайн к структуре хранилища данных EAV (при этом сущность является сообщением Атрибут является «MessageData.DataType», а значение систематически удваивается.)
Схема трех таблиц, которую вы обрисовали в общих чертах в вопросе, однако, похоже, немного отличается от традиционной реализации EAV, в том смысле, что существует неявная последовательность для способа хранения MessageData, посредством которого все данные точки для данного сообщения последовательно нумеруются (DataId), и ссылка из сообщения на его точки данных будет управляться DataId в пределах диапазона.
Это плохая идея !
Многие проблемы с этим, примечательным является то, что это создает ненужное узкое место для вставки сообщений. Не удается начать вставку второго сообщения, пока не будут указаны все точки данных для предыдущего сообщения.
Другая проблема заключается в том, что это затрудняет индексацию отношения между сообщением и точкой данных (базовая СУБД не будет эффективной в этом).
==> Предложение. Сделайте MessageId внешним ключом в таблице MessageData . (и, возможно, вообще удалите PK DataId из таблицы MessageData, просто для экономии места за счет необходимости использовать составной ключ для ссылки на конкретную запись в этой таблице, например, в целях обслуживания)
Еще одно предложение - хранить наиболее распространенные атрибуты (точки данных) на уровне таблицы сообщений . Например, Lat и Long, но, возможно, также Course или Some alarms и т. Д. Причиной правильности этой информации в сообщении является оптимизация запросов к данным (ограничение количества самостоятельных объединений, необходимых с помощью таблицы MessageData.
Поскольку таблицы «Сообщения» и «MessageData» могут не содержать часть сообщения, вы также можете переименовать последнюю таблицу «MessageDetail» или другое имя.
Наконец, может быть хорошей идеей будет разрешить значения данных, отличные от значений типа double . Я предполагаю, что некоторые предупреждения являются просто логическими и т. Д. Помимо разрешения принимать различные типы точек данных (скажем, короткие строки сообщений об ошибках ...), это также может дать вам возможность разделить точки данных по нескольким таблицам «подробностей»: одна для двойников, один для логических значений, один для строк и т. д. Этот способ усложняет схему в том смысле, что вам необходимо встроить некоторые из этих деталей в способ создания запросов, но он может обеспечить некоторый потенциал для производительности / масштабирования. прибыли.