Работая над программным обеспечением для термодинамического моделирования (на C++), мне нужно сохранять свойства жидкости при разных температурах. Эти точки данных используются для построения простой функции интерполяции, чтобы оценить значения свойств также при температурах, для которых у нас нет полных экспериментальных данных.
Жидкость просто идентифицируется по ее названию и концентрации (%) (последнее часто не имеет значения). Если вам интересно, интерес представляют четыре свойства: массовая плотность, динамическая вязкость, удельная теплоемкость и теплопроводность. Для любого другого намерения и цели это всего лишь 4 числовых свойства, назовите их A, B, C и D. Таким образом, функция для конкретной жидкости выглядит примерно так: (A,B,C,D) = f(T), где T — температура.
В настоящее время это база данных SQLite3, и таблица жидкостей выглядит так:
+----+-------+---------------+
| id | name | concentration |
+====+=======+===============+
| 1 | Water | 100 |
+----+-------+---------------+
| 2 | ..... | ... |
И есть таблица свойств:
+----------+-------------+---------+-----------+--------------+----------+
| fluid_id | temperature | density | viscosity | conductivity | capacity |
+==========+=============+=========+===========+==============+==========+
| 2 | 373.15 | 1045.48 | 0.412 | 1.415 | 0.845 |
| 3 | 273.15 | 1105.0 | 2.113 | 0.4688 | 0.849 |
| 3 | 283.15 | | 1.678 | 0.4859 | 0.8503 |
| 3 | 293.15 | 1098.0 | 1.353 | 0.5015 | 0.5833 |
| 3 | 303.15 | | 1.08 | 0.5164 | |
| 3 | 313.15 | 1090.0 | 0.893 | 0.532 | 0.8561 |
| 3 | 323.15 | | 0.748 | 0.5432 | |
| 3 | 333.15 | 1080.0 | 0.644 | 0.5543 | 0.8577 |
| 3 | 343.15 | | 0.563 | 0.564 | |
| 3 | 353.15 | 1068.0 | 0.499 | 0.5722 | 0.8612 |
| 3 | 363.15 | | 0.44 | 0.5796 | |
| 3 | 373.15 | 1054.0 | 0.39 | 0.5856 | |
+----------+-------------+---------+-----------+--------------+----------+
Вставка данных вручную для тестирования была в порядке. Это также будет интуитивно понятным интерфейсом для графического интерфейса редактора Fluid Editor.
Однако в коде интерполяция выполняется отдельно для каждого свойства. Более того, поскольку я не могу использовать значения NULL, не все температуры (строки) относятся ко всем свойствам. Чтобы адаптировать вещи с точки зрения кода, я создал четыре идентичных представления — по одному для каждого свойства. Например:
+----+-----------+---------------+-------------+-------+
| id | name | concentration | temperature | value |
+====+===========+===============+=============+=======+
| 2 | Sea Water | 22 | 373.15 | 0.412 |
| 3 | Sea Water | 14 | 273.15 | 2.113 |
| 3 | Sea Water | 14 | 283.15 | 1.678 |
| 3 | Sea Water | 14 | 293.15 | 1.353 |
| 3 | Sea Water | 14 | 303.15 | 1.08 |
| 3 | Sea Water | 14 | 313.15 | 0.893 |
| 3 | Sea Water | 14 | 323.15 | 0.748 |
| 3 | Sea Water | 14 | 333.15 | 0.644 |
| 3 | Sea Water | 14 | 343.15 | 0.563 |
| 3 | Sea Water | 14 | 353.15 | 0.499 |
| 3 | Sea Water | 14 | 363.15 | 0.44 |
| 3 | Sea Water | 14 | 373.15 | 0.39 |
+----+-----------+---------------+-------------+-------+
Теперь, когда я постепенно перехожу от прототипирования к созданию правильного программного обеспечения, я пытаюсь подумать, как любой из этих подходов впишется в перспективу ORM. Будет ли это модель для каждого свойства (например, мои представления) или одна модель для всех свойств (например, используемая в настоящее время таблица). Третьей альтернативой может быть оставить базу данных такой, какая она есть, и построить модели поверх представлений (вместо реальных таблиц), но это не способ ORM.
Я даже рассматривал возможность переноса этого набора данных в решение NoSQL (например, MongoDb), но не мог придумать, как решить проблему двойной перспективы.
Я признаю, что здесь нет проблем ни со временем выполнения, ни с производительностью пространства, и что объем данных, которые нужно хранить и обрабатывать, в любом случае ничтожен. В час может быть всего два запроса, каждый из которых загружает набор данных для конкретной жидкости в память приложения и работает с ним там (интерполяция и расчеты на основе оценок). Так что я соглашусь, если вы думаете, что я слишком напрягаюсь по этому поводу.
В противном случае я хотел бы услышать ваши мысли и рассмотреть любой другой подход, который вы могли бы предложить. Я что-то упускаю? Как насчет избыточности ключей (жидкости и температуры), которая может возникнуть при разделении таблицы? Кроме того, это может быть интересно тем, у кого есть ограничения.
