Есть около 300 тыс объектов ( например легковых автомобилей) для каждого автомобиля раз в неделю производится замер параметров ( пробег, давление в шинах, количество топлива), параметров будет в районе 20 штук, нужно все это хранить в базе.
В освновном пользователей интерисуют только последние параметры. Но иногда необходимо отвечать на вопросы типа «А как менялось давление в шинах во времени», «А какие параметры менялись на прошлой неделе»
Интуиция говорит, что наверное надо смотреть в сторону mongo, но тех задание явно говорит, что будем использовать Mysql :)
Пока родилось два варианта
1)
Первая таблица (название data)
id| object_name | param1 | param1_is_changed | param1_change_date | param2…
Вторая таблица (название data_history)
id| object_name | param1 | param1_is_changed | param1_change_date | param2… | version | change_date
При каждом изменении любого параметра, предыдущая версия записывается в data_history, у того параметра который изменился ставится влажок is_changed
2) Первая таблица (название data)
id| object_name
Вторая таблица ( хранит только последние значения)
id | object_id | param_name | param_value | date
Третья таблица ( хранит историю значений из второй таблицы)
Сейчас мы отслеживаем около 50 тыс объектов, в неделю происходит около 200 изменений в параметрах. Все параметры числовые, поэтому вопрос избыточности хранения в первом случае волнует только в плане производительности БД, но никак не места на диске. Второй метод вроде хорош, но его не очень просто реализовать используя ORM.
Ваше мнение? как спроектировать DB? как найти компромисс между эффективной БД и удобством написания приложения к ней.
My<cod/>.net
