Проблема проектирования реляционных таблиц

Question

Как сохранить исторические реляционные данные, если строки изменены? В этом примере пользователям разрешено редактировать строки в таблице свойств в любое время. Тесты могут иметь любое количество свойств. Если они редактируют поле «Имя» в таблице свойств или удаляют строку в таблице свойств, строки теста могут не содержать условий во время теста. Измените ли вы дизайн таблицы Test, добавив столбец имен свойств и отбросив таблицу сопоставления TestProperty? Столбец с именами свойств должен быть чем-то вроде списка строк с разделителями. Как обычно решается проблема?

3 таблицы:

Test:
  TestId     AUTONUMBER, 
  Name       CHAR,
  TestDate   DATE

Property:
  PropertyId AUTONUMBER, 
  Name       CHAR

TestProperty:  (maps properties to tests)
  TestId
  PropertyId

Answer 1

Не думаю, что на вопрос был дан полный ответ.

Если они редактируют поле «Имя» в таблице свойств ... Измените ли вы дизайн таблицы теста, добавив столбец имен свойств и отбросив таблицу сопоставления TestProperty?

Определенно нет. Это добавило бы массовое дублирование без всякой цели.

Если ваше требование состоит в том, чтобы поддерживать целостность значений данных (в свойстве) во время теста, правильный метод (база данных) - реализовать таблицу истории. Это должна быть точная копия исходной таблицы плюс один элемент: к PK добавляется столбец TIMESTAMP или DATETIME. <pre>PropertyHistory PropertyId AUTONUMBER, Name CHAR CONSTRAINT PRIMARY KEY CLUSTERED UC_PK (PropertyId)<br> PropertyHistory PropertyId INT, AuditedDtm DATETIME, Name CHAR CONSTRAINT PRIMARY KEY CLUSTERED UC_PK (PropertyId, AuditedDtm) Чтобы это было значимым и полезным, тестовой таблице также нужна временная метка, чтобы определить, на какую версию ProperyHistory ссылаться: <pre>TestProperty TestId PropertyId TestDtm DATETIME

Столбец имен свойств должен быть чем-то вроде разделенного списка строк.

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

... или поместите строку в таблицу свойств

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

Answer 2

Похоже, вы используете Test как шаблон для конкретного экземпляра теста, так и сам тест. Может быть, каждый раз, когда пользователь выполняет тест в соответствии со спецификацией в Test, создайте строку, скажем, в TestRun? Это сохранит конкретные Property с, и если записи в Property изменятся позже, то последующие TestRun с отразят новые изменения.

Answer 3

Если вы хотите сохранить имущественные отношения, даже если свойство не существует.Сделайте так, чтобы свойства не обязательно были удалены, но добавьте флаг, который указывает, является ли свойство активным в данный момент.Если имя свойства изменено, создайте новое свойство с новым именем и установите старое свойство неактивным.

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

Я бы никогда не превратил один столбец в поле, которое имитирует отношение «один ко многим» со списком, указанным через запятую. В противном случае вы не сможете использовать реляционную базу данных.