Вопрос о дизайне битемпоральной базы данных

Question

Я проектирую базу данных, в которой нужно хранить время транзакции и действительное время, и я пытаюсь решить, как эффективно хранить данные и следует ли полностью нормализовать время атрибутов. Например, у меня есть таблица Client, которая имеет следующие атрибуты: ID, имя, ClientType (например, корпорация), RelationshipType (например, клиент, проспект), RelationshipStatus (например, активный, неактивный, закрытый). ClientType, RelationshipType и RelationshipStatus являются изменяющимися во времени полями. Производительность является проблемой, так как эта информация будет ссылаться на большие наборы данных из устаревших систем. В то же время структура базы данных должна легко обслуживаться и изменяться. Я планирую разделить контрольный журнал и историю за определенный период времени на отдельные таблицы, но я борюсь с тем, как лучше всего это сделать.

У меня есть несколько идей:

1) Три таблицы: Client, ClientHist и ClientAudit. Клиент будет содержать текущее состояние. ClientHist будет содержать любые ранее действительные состояния, а ClientAudit будет использоваться для целей аудита. Для удобства обсуждения давайте забудем о ClientAudit и предположим, что пользователь никогда не допустит ошибку при вводе данных. Делая это таким образом, у меня есть два способа обновить данные. Во-первых, я всегда мог потребовать от пользователя указать дату вступления в силу и сохранить запись в ClientHist, что приведет к записи записи в ClientHist при каждом изменении поля. В качестве альтернативы я мог бы потребовать, чтобы пользователь предоставлял дату вступления в силу только при изменении одного из изменяющихся во времени атрибутов (то есть ClientType, RelationshipType, RelationshipStatus). Это приведет к записи записи в ClientHist только при изменении изменяющегося во времени атрибута.

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

Есть мысли?

Answer 1

вы можете попробовать одну таблицу клиента с 4 столбцами даты для обработки 2 временных измерений. Что-то вроде (client_id, ..., valid_dt_start, valid_dt_end, audit_dt_start, audit_dt_end). С этим дизайном очень просто работать, и я попробую посмотреть, как он масштабируется, прежде чем перейти к чему-то более сложному.

Answer 2

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

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