авторСкорее будут вариации селекта: выбрать поля A, B, X, XY ... ZZZ в интервале времени при такх-то значенияз входов D, E ...
или просто в заданном интервале времени.Если при этом поля A, B, X, XY ... ZZZ и D, E будут в одной таблице то это выполнится быстрее чем если в нескольких.
Vladimir A.K.И все-таки, правильно ли я понимаю, что EAV, это растащить мою задачу на таблицу, где каждая запись:
id_записи, время_измерения, id_параметра, измеренное_значение?Да. Пожалуй я бы добавил id_объекта до кучи. Такая структура позволяет легко добавлять новые параметры, другими словами, добавление нового параметра не приводит к DDL операциям. Это ее основное достоинство, ну и входной файл имеет похожую структуру - импорт будет легко делать. Недостатки я описал.
Vladimir A.K.Мне показалось, что мое решение может быть походим: отдельный прибор (у меня АСУ) - отдельная таблица. Это уже лучше предыдущего подхода с одной таблицей на всех. Каждой такой таблице добавьте первичный ключ вида время_измерения + id_объекта и получите базу с вертикальным секционированием .

С другой стороны я не верю, что все параметры равнозначны. Например на приборной панели автомобиля водитель гораздо чаще смотрит на спидометр, чем на уровень бензина или километры пробега. Поработайте с пользователями чтобы объединить наиболее часто встречающиеся комбинации в общую таблицу типа время_измерения, id_объекта, параметр, параметр .... (см A, B, X, XY ... ZZZ и D, E выше). Остальное (менее популярное) можно сделать отдельными таблицами.
Vladimir A.K.У меня на входе файл с несколькими тысячами записей (в каждой более сотни измеренных параметров на одно и то же время) с одного тепловоза (одна конфигурация). Потом другой файл. Может с этого, а может с другого тепловоза.Именно. Я предостерегал от соблазна устроить цикл по записям.
Предположим что входной файл имеет структуру типа время_измерения, id_объекта, параметр, тогда для заполнения таблицы с несколькими параметрами параметр1 и параметр2 запрос будет типа


и уже этот запрос вы сливаете ( merge ) с вашей базой.

Vladimir A.K.В принципе задумка: при создании в приложении-менеджере формируется конфигурация АСУ: все входы выходы, с требуемыми характеристиками (коэффициенты, масштабирования, нумерация байт в записи из входного файла, типы и т.п.). По окончании в обоих базах делаются Create table по правилам каждой СУБД. В случае необходимости изменения конфигурации АСУ: считали из БД в мэнеджер, изменили, проверили корректность: alter table.Плохая идея. Нет, независимость от субд это, конечно, большой плюс для приложения, ошибкой является думать что достаточно правильно сделать Create table. У вас, по любому, будет отдельное приложение для каждой поддерживаемой СУБД. В общем, задача сложнее, чем кажется, советую сейчас с этим не заморачиватся.