どのデータベースにも、ディメンションとファクトという大きく 2 種類のテーブルがあります。

1. 寸法は構成表です。これらのテーブルは頻繁に変更されることはなく、通常は単一の現在のスナップショット値です (履歴の変更が含まれる可能性があります。詳細は後述します)。最も一般的な操作はテーブルの編集です。これらを構成またはマスターと考えることもできます。
2. ファクトは、時間の経過とともにほぼ直線的に増加するテーブルです。通常、これらのエンティティは時間の経過とともに定期的に生成され、生成されたファクトの更新は一般的ではなく、詳細なコンテキストについては通常、ディメンションを参照します。

データベース スキーマを設計する場合、次のガイドラインのいくつかは、データベース スキーマを適切に設計するのに役立ちます。

まずはノーマル

データベースが SQL であるか NoSQL であるかに関係なく、エンティティ / オブジェクト、つまりテーブルを正規化されたスキーマの観点から一度考えると便利です。正規化されたスキーマにより、エンティティ、関係、およびフィールドが明確になります。これからの非正規化または NoSQL への変換は簡単であり、意識的な設計になる場合があります。

現実世界のエンティティをミラーリングする

たとえユースケースやレポートが不明確であっても、スキーマエンティティは現実世界のユースケースを反映している必要があります。通常、このようなスキーマは堅牢です。

一般に、さまざまなエンティティ、つまりテーブルを識別して作成する場合は、次のいずれかが当てはまります。

1. 論理的に分離されたエンティティ (データセットとステーションなど) は、独立して存在する可能性があり、相互にリンクすることなく存在できます。
2. 相互に多対多の関係または 1 対多の関係を持ちます (例: e コマース会社、注文と顧客)。

クエリ、検索、または並べ替えで使用されているフィールドがある場合は、デフォルトでそのフィールドのインデックスを追加します。これらのフィールドには最大の利点があるため、単純なインデックスをデフォルトでオンにする必要があります。インデックスを追加しないことは、デフォルトの状態ではなく、意識的に選択する必要があります。

適切なフィールド タイプを使用する

1. オプション値の固定セットを持つフィールドの列挙型と文字列型: 列挙型はバイトとして実装されるため、必要なスペースが少なくなり (例: 1 ～ 4 バイトの長さの byte/long/int と 128 バイトの文字列)、インデックスや検索します。大きなテーブルの場合、スペースとパフォーマンスの要件も増加します。デフォルトでは列挙型を使用します。
2. 主キー (ID) タイプ: パフォーマンスとストレージの観点から、常に固定サイズのキー、つまり整数または UUID を使用することをお勧めします。
3. 共通テーブル フィールド: 一部のフィールドは、変更できるすべての ORM エンティティで提案されています (created_at、updated_at、created_by、updated_by など)。さらに、外部キーのリンクが頻繁にあり、めったに削除されないエンティティの場合は、論理的な削除を使用することが提案されます。

Drishti のクエリは複数の結合を伴う複雑になる場合があります。データベースは、インメモリ結合と計算用に最適化されています。可能な限り、ORM レイヤーへの追加、適切なクエリ、またはスキーマの再設計を通じて、データベース内でこれらの結合または計算を実行してください。経験則として、アプリケーション コードでの大規模な結果の結合は、データベースがメモリ内で実行できない場合 (たとえば、データベース間の結合など) にのみ検討する必要があります。

履歴テーブルを追加するタイミングは?

トランザクションベースのシステムには、主要なエンティティのすべての変更の基本的なログが必要です。ディメンション テーブルは API を通じて構成/変更されるため、これは特にディメンション テーブルに当てはまります。

これらを維持するには 2 つの方法があります。

1. 属性変更の汎用抽象化を維持します。この変更履歴のすべての行は、エンティティ タイプ、属性、エンティティ ID、古い値と新しい値を指します。利点: エンティティごとに新しいテーブルを必要としません。
2. 値の変更ごとにエンティティごとの履歴テーブルを維持します。利点: 複数のフィールドの変更をアトミックなトランザクションとしてキャプチャし、顧客にそのように表示します。したがって、フロントエンドまたはその他の方法でユーザーによって実行されるトランザクションの概念は維持されます。