alreves Очень не хочется создавать таблицы для каждого прибора индивидуально. Однако это единственный честный способ.
alreves Параметры изменяются во времени.Вы записываете снимок (вчера, в восемь утра там было пять) или историю (с ... по ... значение было пять)?
alreves Есть мысли хранить связки [прибор] - [параметр] - [дата] - [значение]. Причём [значение] в неком универсальном формате (binary, byte[]).
Здравствуй EAV
alreves И как делать выборки мне не понятно.Создаете вьюхи и с ними работаете.
Только потом возникает вопрос - а зачем мне вьюхи, когда то же самое можно хранить в таблицах.
alreves Может есть какие-то типовые решения для таких задач?Сильно зависит от - количества типов параметров, вероятности появления новых, объемов данных и требованиям ко времени отклика, жизненного цикла данных: вставка (по одной, скопом), изменения (возможны ли вообще), удаления (архивация) и запросы (дай все за период, дай все по типу, дай все где поле инструмент равно "Кувалда" и поле заготовка равна "палец").
При наличии ВСЕЙ информации (плюс прогноз ближайшего будущего) можно начертить оптимальную структуру. Пока вы перечислили задачу хоть как-то сохранить.

alreves есть всего 2 типа приборов, у каждого из которых по 3 разнотипных параметра.
alreves Самая частая выборка будет вида - выбрать для всех приборов типа PP значение параметра NN в момент времени TT или на интервале от TT1 до TT2.И вы все еще сомневаетесь?
Не вижу смысла смешивать все в одну таблицу. Если сильно нужно создайте вьюху для объединения.

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

alreves Почему не хотелось бы делать таблицы для каждого прибора. Есть такая идея - протокол каждого прибора - есть некая dll. В каждой dll есть строго определённый набор операций (например получи значение параметра N). Система опроса может подключать произвольные библиотеки данного типа. При подключении библиотека будет "рассказывать" системе опроса, какие операции она может совершать. Давайте ближе к телу. Итак клиент решил сохранить что-то в базе. Код для сохранения (один или несколько вызовов хранимки или insert) вы хотите засунуть в эту самую dll, вместо написания "умной" вставлятельной хранимки так?

alreves Пока типов приборов немного (2 шт.). Но в будущем это точно изменится и количество возрастёт (ну по крайней мере до 10-12 шт.) Вы бы перечислили всю экзотику.
Например - группы значений. Как это дело должно обрабатываться в отчете/запросе, можно ли их объединить например по времени снятия или искусственного кода группы параметров одного измерения. В общем чем подробнее вы опишите задачу (на всем пути жизни данных) тем лучше. Не исключено что и помощь форума уже не понадобится

baracs Но когда-то придется делать по этой базе отчеты. Обслуживать ее в конце концов...
Веселенькое это будет занятие, когда данных поднакопится.Именно. После вставки все только начинается, а по статистике данные живут дольше программ.