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

Question

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

В ландшафте без битпотемпа мы будем моделировать его как отношения родитель-ребенок. Мой вопрос: в бимпоральном мире, должен ли такой прецедент по-прежнему моделироваться как отношения между родителями и дочерними элементами из двух таблиц с 4 временными столбцами на обеих таблицах? Я не вижу причины, почему это невозможно сделать, но вопрос о том, «должно ли это быть сделано», в моем сознании довольно туман. Любые гуру, чтобы помочь мне с обоснованием выбора?

Плюсы:

1. Нормализация

Минусы:

1. Дополнительные таблицы и временные столбцы, чтобы поддерживать и управлять ими с помощью DAO-х
2. Определение производительным условий соединения

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

Заранее благодарен!

Answer 1

Bitemporal управление данными и внешние ключи могут быть довольно сложными. Для отношений между хозяином и спутником между битпоральными таблицами в основной таблице необходимо ввести «искусственный ключ», который не является уникальным, но идентичным для разных временных или исторических версий объекта. Этот ключ ссылается со спутника. При объединении двух таблиц битпоральный контекст (T_TIME, V_TIME), где T_TIME - время транзакции, а V_TIME - действительное время, необходимо указать для соединения. Присоединиться бы что-то вроде следующего:

SELECT m.*, s.* 
    FROM master m 
    LEFT JOIN satellite s 
    ON m.key = s.master_key 
    AND <V_TIME> between s.valid_from and s.valid_to 
    AND <T_TIME> between s.t_from and s.t_to 
WHERE <V_TIME> between m.valid_from and m.valid_to 
    AND <T_TIME> between m.t_from and m.t_to 

В этом запросе действительный период задается колоннах valid_from и valid_to и период транзакции данных по столбцам t_from и t_to как для мастера и спутникового стола , Искусственный ключ в ведущем задается столбцом m.key и ссылкой на этот ключ на s.master_key. Левое внешнее соединение используется для извлечения также тех записей главной таблицы, для которых нет соответствующей записи в спутниковой таблице.

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

Таким образом, вопрос, который вы задаете, сводится к компромиссу между требованиями к пространству и сжатым кодом. Объем пространства, который вы жертвуете решением с одним столом, зависит от количества столбцов вашей спутниковой таблицы. Вероятно, я бы выбрал решение с одной таблицей, так как это намного легче понять.

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

https://github.com/1123/bitemporaldb

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