Должен ли я нормализовать подобную схему, даже если данные могут быть концептуально не связаны? - PullRequest
Новая
       27

Должен ли я нормализовать подобную схему, даже если данные могут быть концептуально не связаны?

1 голос
/ 31 марта 2011

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

Базовая схема может выглядеть так: 

Things
  - ID
  - ThingName
  - CreatedOn
  - CreatedBy
  - CreatedIn
  - LastModifiedOn
  - LastModifiedBy
  - LastModifiedIn
  - HiddenOn (nullable)
  - HiddenBy (nullable)
  - HiddenIn (nullable)

Это немного беспокоит меня. Исходя из ООП и учитывая, что эти данные будут в основном использоваться linq-to-sql, создается впечатление, что я мог бы извлечь повторяющиеся поля в отдельную структуру, которая также будет действовать как своего рода контракт схемы: 

Actions
  - ID
  - ExecutedOn
  - ExecutedBy
  - ExecutedIn

Things
  - ID
  - ThingName
  - CreatedAction -> Actions.ID
  - LastModifiedAction -> Actions.ID
  - HiddenAction (nullable) -> Actions.ID

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

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

  • Может ли это стать источником конфликта вставки (Работа с SQL Server 2008)?

  • Не станет ли поиск по этим полям более дорогим, потому что будет намного больше строк, и можно ли это уменьшить, проиндексировав его на дискриминаторе?

  • В общем, хорошая идея или плохая?

Спасибо

1 Ответ

1 голос
/ 31 марта 2011

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

  • Вы отслеживаете множество сущностей: множество видов вещей и сущность «Действие».Действие больше не является частью вещи, это его собственная вещь.(К счастью, вам не нужно вводить действие, чтобы регистрировать работу, выполненную в действии, верно?)
  • Если вы хотите быстро выполнить действия, предпринятые для одного определенного вида вещей, вы можете захотеть иметьстолбец (ваш «дискриминатор») в таблице «Действия», обозначающий вид того, что было предпринято.(Необходимость объединения на N разных таблицах вещей просто для определения типа приводит к снижению производительности.)
  • Может ли одно действие повлиять на более чем одну вещь (скажем, создать новую вещь и изменить существующую вещь)?Это было бы более сложно моделировать.
  • Здесь вы регистрируете все действия, выполняемые над чем-либо, в таблице действий, а в таблице вещей записываете только самые последние действия, выполненные из 3 действий.типы (Создать, Изменить, Скрыть).Когда выполняется новое действие одного из этих типов, последнее (если оно есть) удаляется из таблицы вещей ... но это "старое" событие действия все еще записывается в таблице действий.Для ваших бизнес-целей полезны или нерелевантны данные?
  • Что касается конфликта вставок, он будет зависеть от используемой вами СУБД.Это старая старая проблема, и большинство современных систем справляются с ней довольно хорошо.Сборка, тестирование, отслеживание блокировок и проблем с длительными транзакциями, и у вас все будет хорошо.
  • Если таблица становится большой, постройте индексы.Если вы часто выполняете поиск или фильтруете по типу действия, добавьте этот столбец дискриминатора и включите его в индекс (опять же, разные СУБД имеют разные функции индексации, прочитайте документацию, чтобы узнать, что может работать лучше для вас.)

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

...