Дизайн базы данных

Question

Наша база данных является частью (специализированного) настольного приложения. Основная цель - сохранить данные об определенных событиях .

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

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

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

Создание таблиц, таких как

Таблица событий
Стол Группа Месяца 1
Стол Группа Месяца 2
...

Таблица событий имеет:
Первичный ключ, чей каскад удаления удаляет строки с внешними ключами, ссылающимися на него
Обнуляемый ключ foreighn для каждой таблицы группы данных

Каждая таблица группы данных имеет:
Первичный ключ, удаление которого каскадно обнуляет внешние ключи, ссылающиеся на него
Столбцы для данных в этой группе
Не обнуляемый внешний ключ обратно на событие

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

Есть предложения?

P.S. Мы используем SQL Express или SQL Compact (в настоящее время мы экспериментируем с тем, который нам больше подходит)

Answer 1

Почему бы не использовать в основном подход с одной таблицей и сохранить изменяющиеся данные о событиях в виде XML в столбце XML? Вы даже можете использовать схемы XSD для учета изменяющихся типов данных и добавлять индексы для данных XML, если требуется высокая производительность запросов для некоторых данных XML.

Постоянно изменяющаяся схема БД на самом деле не была бы вариантом, если бы я реализовал такую ​​базу данных.

Answer 2

Храните ваши данные на как можно более детальном уровне.Это может быть так просто:

EventSource int FKEventType int FKПродолжительность intПроизошло на дату и время

Получите правильные и максимально простые данные, а затем

1. Агрегируйте с помощью представлений или запросов.Ваши инстинкты верны в отношении постоянно меняющейся природы столбцов - лучше контролировать это в T-SQL, чем в DDL.

2. Я столкнулся с этой проблемой несколько лет назад с файлами журналов для массовыхармии медиаплееров, и в конечном итоге я взял эти данные и создал из них куб OLAP.OLAP - это еще один подход к проектированию баз данных, где важнее всего оптимизировать его для составления отчетов и обеспечения «ломкости».Похоже, вы находитесь на этом треке, где было бы очень полезно иметь возможность быстро просмотреть данные за месяц, затем за квартал и затем вернуться к недельным.Это то, для чего предназначен OLAP.

Технология Microsoft для этого - службы Analysis Services, входящие в состав Sql Server.Если вы не хотите делать полный шаг (у OLAP довольно крутая кривая обучения), вы также можете посмотреть на выборочно денормализованную базу данных, которую вы каждую ночь заполняли ETL из исходной базы данных.

HTH.

Answer 3

В таблице событий не должно быть внешних ключей для каждой таблицы группы данных.

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

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