1. у нас есть параметры (много)
2. у нас есть ограниченное количество типов данных которые могут принимать параметры
строковые,
целые
плавающей точкой
дата и время

тогда может попробовать следующее:














Поставить триггер (ограничение) на то чтобы нельзя было вставлять
параметр с типом ПлавТочка в таблицу ДанныеИзмеренийЦелое к примеру.

Далее в программе расскидываете данные по таблицам.

Преимущество данной структуры в том что все ваши параметры типизированы
и в бд. храняться с явным указанием типа.

Возможно есть лучший вариант, подумайте.

--
PS
Не нужно генерировать таблицы в триггерах.
А то на этот ваш вопрос никто не ответит в последствии:
авторКак выбирать данные из таблиц хранилищ? STORE_1......N c полем p_val разного типа при помощи VIEW? PROCEDURE? и привязать их сущностям для удобства програмимрования?

g_box[quot Курочка Ряба]
Вероятно нужно подойти с середины задачи и промоделировать какие необходимы сущности, как с ними программно работать и выбирать данные и после этого переложить на структуру таблиц БД?


Можно использовать и такой подход ef -> db, но ясно лишь одно entity framework не работает с динамическими объектами которые вы хотите генерить триггером (я про хранилища). После нового сгенеренного хранилища нужно обновить EF модель программисту.

авторпри чем 1500 параметров которые нужно хранить неделю являются оперативными и вносяться в БД с частотой раз в 30 сек, и при этом данные выбираются для различных UI и отчетов? а таблица одна

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

в ms sql server например есть уровень изоляции снепшот set transaction isolation level snapshot
позволяет считывать данные из таблицы даже во время их вставки, т.е. совершенно не блокируя таблицы.

g_boxВладимир Затуливетер
Вы боитесь блокировок на таблицу, т.е. различные приложения будут бороться за доступ к ней?


Вы правы это настраивается, есть опасение разрастания таблицы через 2-3-4 года не хотелось бы иметь несколько миллионов записей

Вы на форум оракла это напишите, уверен что на вас обрушится куча людей.
Таблицы могут хранить очень большое количество строк сотни милионов, милиарды.
Для доступа к необходимым данным вы используете выборки.
Выборки с определенными фильтрами, к примеру по датам за последнюю неделю.
Далее в ход идут ИНДЕКСЫ которые вы не забыли создать в своей БД.
За чет них выбираются только нужные данные, только те 10000 записей которые необходимы.
Игнорируя и даже не обращаясь к остальным 10 милионам.


Если вы не полагаетесь на механизмы СУБД то можете реализовать архивные таблицы,
т.е. каждая из таблиц у вас разделяется на 2, архив и текущие данные и время от времени
не нужные данные перебрасываются в архив.

Вы про усреднение ранее не говорили, замечу.

Это таже история что с архивированием,
только у вас больше таблиц,
причем каждая последующая содержит более сжатые данные.

Для некоторых систем это не подходит, всегда нужны оригинальные (не сжатые данные).

При таком подходе "сжатия данных" вам потребуется время на обработку.
Т.е для переброски данных в архивные таблицы нужны ресурсы, и время, это нужно учесть при проектировании.

Можно создать в своей БД несколько таблиц.
К примеру вариант такой, всегда оставлять первоначальные данные в таблице
И на основе ее заполнять таблицы сжатых данных
10 мин, 1 час, 24 часа... и тд.
Благодаря этому вы всегда можете получить доступ к первоначальным данным, кото знает может скоро они вам понадобятся.

Можно рассмотреть варианты с OLAP.

К той структуре которую я вам предлагал ранее с 6 таблицами

Таблица ПараметрыСправочник
Таблица Измерения
Таблица ДанныеИзмеренийЦелое
Таблица ДанныеИзмеренийСтрока
Таблица ДанныеИзмеренийПлавТочка
Таблица ДанныеИзмеренийДатаВремя

добавляются еще таблицы:

Таблица ДанныеИзмеренийЦелоеСжатые10мин
Таблица ДанныеИзмеренийСтрокаСжатые10мин
Таблица ДанныеИзмеренийПлавТочкаСжатые10мин
Таблица ДанныеИзмеренийДатаВремяСжатые10мин

Таблица ДанныеИзмеренийЦелоеСжатые60мин
Таблица ДанныеИзмеренийСтрокаСжатые60мин
Таблица ДанныеИзмеренийПлавТочкаСжатые60мин
Таблица ДанныеИзмеренийДатаВремяСжатые60мин

Таблица ДанныеИзмеренийЦелоеСжатые24часа
Таблица ДанныеИзмеренийСтрокаСжатые24часа
Таблица ДанныеИзмеренийПлавТочкаСжатые24часа
Таблица ДанныеИзмеренийДатаВремяСжатые24часа

и т.д...

Если необходимо предусмотреть связь сжатых данных с несжатыми.

Вариантов тут куча, главное таблиц не генерить динамических.
Не создавать изначально проблем, чтоб героически их потом решать ;)