Vladimir A.K.Для информации под аналитику одна таблица, в которой:
250 полей типа float - аналоговые входы.
250 полей типа smallint - дискретные входы\выходы.
И еще несколько служебных полей: время измерения, время записи в БД, идентификаторы типа АСУ (символьный), идентификатор объекта, на котором стоит АСУ (символьный) и т.п.

Для информации, хранящейся постоянно, другая таблица:
50 полей типа float, плюс служебная информация.

У каждого типа АСУ есть своя конфигурация, в которой описаны все входы-выходы. Причем конфигурация хранится в другом файле БД.

У одного АСУ м.б. 200 аналоговых каналов и 200 дискретных, у другого 100 и 100 соответственно, т.д.
У одного АСУ во вторую таблицу пишется 10 параметров, у второго 20.

В связи с этим таблицах с данными измерений (и в первой и второй) огромная избыточность. Большинство полей после вставки - NULL
И по факту имеется куча отдельных файлов БД, в которые заносится информация за месяц и делается кое-какая, на данный момент элементарная, обработка. Следующий месяц - следующий файл. И т.д.

1) В архиве нет смысла хранить все, что приходит из "поля". Разумно сохранять все значения 1 раз в час, к примеру, а в остальное время в базу писать только те значения, что изменились.
2) Для аналоговых каналов нет необходимости хранить все значения. Они обычно "дребезжат", и можно ввести зону нечувствительности, изменениями в рамках которой можно пренебречь. К примеру, для значений тока 32,521 А и 32,522 А вполне возможно отбросить последний разряд.
3) Vladimir A.K.250 полей типа smallint - дискретные входы\выходы. В этих полях значения находятся в каждом бите числа, или это всего 250 бит (250 входов/выходов)? Если второе, то их можно упаковать.

Поищите описания работы СУБД, используемых для хранения тегов в АСУ ТП. К примеру, Wonderware Historian.
Кстати, требования в железу и СУБД, при использовании подходов, принятых в специализированных СУБД, средние. Тот же Wonderware еще 10 лет назад, если не ошибаюсь, гарантировал запись 100 000 тегов в сек. на своей базе, построенной на основе MS SQL 2000.

Vladimir A.K.йцуке1) В архиве нет смысла хранить все, что приходит из "поля". Разумно сохранять все значения 1 раз в час, к примеру, а в остальное время в базу писать только те значения, что изменились.

Не получится. Тепловоз :) Подавляющее большинство измеряемых параметров постоянно изменяются.

В АСУ тоже подавляющее большинство параметров постоянно меняются. Подход с загрублением аналоговых параметров и сохранением только изменений позволяет хорошо сэкономить на объеме записываемых данных.

[quot Vladimir A.K.]йцукеЯ описал, что есть сейчас: эдакий образчик "проектантского нигилизма" :)
А мне надо найти оптимальную структуру.

Спроектируйте нормализованную базу, проведите тесты, по результатам, при необходимости, денормализуйте.

Vladimir A.K.Да, спасибо. Cегодня ХЕ качать не стал. Но, что пойду по этому пути, уже определился.
Неплохо бы было начать с проектирования. Посчитать общий объем базы, количество инсертов в секунду, прикинуть типовые запросы, определиться с индексами. По результатам выбрать сервер.
Скорей всего, запросы будут простенькими, а проблема будет только в размере таблиц, скорости вставки и скорости выборки. И, в результате, подойдет любой сервер, хоть MySQL.
Если для вас не проблема покупка оракла, то почему бы не посмотреть на промышленные решения, используемые в АСУ. Они оптимизированы именно под работу с большими массивами аналоговых/дискретных параметров.
И форум для вопросов вы неудачно выбрали. Спрашивать надо на форумах асушников. Для них это типовая задача.

Vladimir A.K.,

О, нашел древнюю, 1999 г., статью об асушном решении

Цитаты:
"Что делает IndustrialSQL Server?
Сохраняет некритичную во времени информацию в БД Microsoft SQL Server. Вся технологическая информация сохраняется в специальных таблицах расширения.

Поддерживает пропускную способность, т.е. обеспечивает сохранение огромных потоков информации с высокой разрешающей способностью.

Поддерживает целостность данных, то есть обеспечивает запись больших объемов информации без потерь.

Добавляет в Microsoft SQL Server свойства сервера реального времени.

...Уменьшение объема хранения IndustrialSQL Server позволяет хранить данные на пространстве, составляющем небольшую долю от соответствующего объема обычной РБД. Фактический размер требуемого для хранения производственной информации дискового пространства определяется размером и сущностью операций предприятия, а также интервалом хранения предыстории его функционирования. Например, двухмесячный архив предприятия с 4000 параметров, опрашиваемых с периодичностью от нескольких секунд до нескольких минут, будет занимать около 2 Мбайт дискового пространства. Используемый алгоритм упаковки информации является алгоритмом сжатия без потерь, сохраняющим высокое разрешение и качество данных."

Vladimir A.K.1. Разделение "подзадач" на две БД (возможно с разными СУБД, физически разнесенных и т.п.) обдумано, обсуждено и утверждено.
Сокращенная информация с длительным сроком хранения будет вынесена в отдельную БД.

Если какие-либо данные в первой или во второй базе могут правиться руками, то со временем базы начнут "ехать". Например, один тепловоз обозвали по-разному в разных базах и т.д..

Vladimir A.K.Имеем: несколько конфигураций.
Каждая i-я конфигурация содержит Ni аналоговых параметров и Mi дискретных параметров.
Все-таки, что видится оптимальным:
- общая таблица с количеством полей, равным максимальному количеству полей из всех конфигураций. С учетом подсказки SERG1257 о том, что хранение избыточных NULL не занимает большого места.
Попробуйте загрузить, и оцените рост базы. Было бы интересно посмотреть. Загрузка ежесекундных данных один-в-один, и без оптимизаций.
Vladimir A.K.- раздельные таблицы для каждой конфигурации.
Если потребуется сравнивать параметры разных конфигураций, может быть неудобно.