6NF и данные исторического атрибута

Question

При использовании базы данных, нормализованной по принципам 6NF, как вы храните данные исторических атрибутов?

Пусть говорят, например, мы берем this example из @PerformanceDBA, но со следующим дополнительным требованием:

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

Более практический пример:
Предположим, что диски и процессора из приведенного выше примера являются виртуальными и пользователь может изменить емкость диска по своему желанию. Как мы можем изменить базу данных, чтобы мы могли извлекать атрибуты данного диска в любое время в прошлом (конечно, после даты создания), сохраняя при этом представление 5NF достаточно быстро.

Вещей я рассматриваю

• Добавьте столбец временной метки «ChangeDate» для каждой таблицы атрибутов (это приведет к довольно сложному запросу с подзапрос и присоединиться к каждой таблице атрибутов)
• Создайте отдельный * стол истории для каждой таблицы атрибутов (может привести к огромному количеству таблицы, так как у нас есть около 70 атрибутов, распределенных по 20 типам товаров)
• Дополнительно: добавить «текущий » столбец проиндексирован для каждой таблицы атрибутов, чтобы ускорить представление 5NF

Любая помощь приветствуется!

---

Edit: Я знаю, что понятие временных баз данных, однако проблема заключается в том, что для двигателя базы данных я работаю с (PostgreSQL) временное расширение еще не полностью реализованы. Любые советы о том, как достичь этого без временных баз данных?

Answer 1

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

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

Хорошая презентация об этом в http://metadata-standards.org/Document-library/Documents-by-number/WG2-N1501-N1550/WG2_N1536_koa046-Temporal-features-in-SQL-standard.pdf.

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

Также есть дискуссионная группа «Временные данные» на сайте www.linkedin.com, посвященная точно вашему предмету.

EDIT пытается обратиться к «Любые советы о том, как достичь этого без временных баз данных?«

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

Так что добавьте ОБА как начало, так и конец даты/времени. НЕ ДЕЛАЙТЕ ИХ НОМЕРА НОМЕРОВ. Новый стандарт требует этого для его временных функций Если конечный MIT (момент времени) пока неизвестен, используйте максимальное значение применимого типа времени, например, 9999-12-31.

Вам НЕ НУЖНО «создавать отдельные таблицы истории для каждого атрибут ". одинаково возможно иметь «таблицу единичных сущностей», которая сохраняет «историю возникновения целой сущности». Недостатком является то, что будет сложно запросить, когда возникло изменение в ACTUAL к определенному атрибуту (потому что вы получаете новые исторические строки для любого изменения любого атрибута, возможно, копируя за одно и то же значение атрибута для большинства атрибутов). «Единая таблица», скорее всего, является нетерпеливым потребителем пространства, «отдельная история для каждого атрибута» может быть нетерпеливым потребителем запросов на процессорное время. Это будет балансирующий акт, и когда баланс точно зависит от вашей конкретной ситуации.

Не добавляйте индексированный текущий столбец в свои таблицы. Во-первых, они не помогут вам перейти к новым функциям, когда ваш движок имеет их, а во-вторых, столбцы Y/N являются очень плохими дискриминаторами и, следовательно, очень слабыми кандидатами для индексирования. Я бы предпочел добавить ваш индекс начала или конца к индексу, от них можно ожидать, что вы получите одинаковые выигрыши для «текущих» строк и лучший выигрыш для неточных строк, когда вам нужно запросить эти ,

Что касается принудительного использования ограничений базы данных, таких как неперекрывающиеся во временных периодах временные ключи и включение временных периодов во временный RI, хорошо, что вы просто полностью по своему усмотрению. Напишите код, который вам нужен, в триггеры или SPROC или код приложения, в порядке убывания предпочтения.

Было ли это полезно?