バイテンポラル データ管理と外部キーは非常に扱いにくい場合があります。バイテンポラル テーブル間のマスター/サテライト関係の場合、マスター テーブルに "人工キー" を導入する必要があります。このキーは一意ではありませんが、オブジェクトのさまざまな一時的バージョンまたは履歴バージョンに対して同一です。このキーはサテライトから参照されます。2 つのテーブルを結合する場合、バイテンポラル コンテキスト (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 内) が更新される場合、それぞれのテーブルに新しいエントリのみが必要になるため、スペース効率が高くなる可能性があります。すべてのデータに対して 1 つのテーブルを使用する場合、結合されたテーブル内のすべての列に対して新しいエントリが必要になります。また、多くの null 値を持つテーブルになってしまいます。
したがって、あなたが求めている質問は、スペース要件と簡潔なコードの間のトレードオフに要約されます。単一テーブル ソリューションで犠牲になるスペースの量は、サテライト テーブルの列数によって異なります。はるかに理解しやすいので、おそらく単一テーブルのソリューションを使用します。
データベース技術を切り替える機会があれば、ドキュメント指向データベースの方が理にかなっているかもしれません。mongodb に基づくバイテンポラル スカラ レイヤーのプロトタイプを作成しました。これは次の場所から入手できます。
https://github.com/1123/bitemporaldb
これにより、結合なしで作業でき、取引データの構造がより柔軟になります。