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

Количество типов событий довольно большое - в районе 500 типов.
Самих событий тоже много, за месяц - приблизительно милион.

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

Какие еще есть варианты реализации для такой задачи (реализация будет на MSSQL)?

Паганель,

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

И еще, насколько я Вас понял, если единая процедура селект, то как минумум светит динамический SQL, что по скорости не совсем хорошо, на таких объемах данных.

Паганель,

1. Чеки констрайнты проходят, только для простых проверок внутри таблицы, а если сложные, выходящие за рамки таблицы?

2. Стоп, а что даст UNION ALL если в этих таблицах РАЗНЫЕ поля (общие и так в отдельной таблице)?

MasterZiv,

Можно поподробнее, что такое EAV? Может ссылочку?

Паганель,

Селект с юнион - это просто жесть. Представьте себе 500 таблиц и полей так 3000+ (кстати, вам хватит ширины вьюшки? а добавить новое событие?). Вы бы сделали такую систему? А ресурсов под нее сколько нужно было бы?

С чего вы взяли что такая выборка нужна? Нужно как раз другое, скармливаем ИД получаем набор специфических параметров, то есть для каждого типа, своя структура на выходе итого, если одна процедура селект, то динамического СКЛ не избежать.... или куча мелких и быстрых процедур.

SERG1257,

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

Отчетность строится по группам событий, тоесть по факту соединяем главную таблицу и до 5 подчиненных.

Для каждого события есть load, save, delete, check процедуры - потому их получается довольно много, зато для клиента все в принципе прозрачно - есть тип собития, дабавляем его к load и грузим данные.

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