現在、フラット DB テーブル設計を使用してもよいのはいつですか。これまで？私が言いたいのは、リレーショナル データベース設計の知恵を放棄し、リンクを組み込んでいないフラットなテーブル構造に戻し、データを追加するために余分な列を追加して、複数の行を格納するために別のテーブルへのキーを作成する必要がある場合です。 .
私は、製品管理チームと話し合うためのいくつかのアイデアに取り組んでいます。最初に「なぜこれらのテーブルはすべてフラットなのですか」という質問をしたとき、「読み取り中心のデータベースは、フラットなテーブル構造を使用するとパフォーマンスが向上する」と言われました。
私はこの説明に苦労しています。なぜなら、フラットデザインは道を進むのに非常に多くの障壁を提示するからです。
考え？
「読み取り中心のデータベースは、フラットなテーブル構造でパフォーマンスが向上します。」このステートメントは、テーブルが操作の挿入/更新/削除に使用されない/めったに使用されないことを示しています。その場合、良好なパフォーマンスを得るには、テーブルに適切にインデックスを付ける必要があります。いかなる種類の結合も存在しないため、テーブルは where 句で多くのフィルターを使用することになるため、適切に使用するためにインデックス作成が非常に重要です。
この種のシナリオは通常、データ ウェアハウスで使用されます。倉庫を設計するときは、通常、主キー/外部キーを排除し、ビジネス主キーを使用します。これは、倉庫内の巨大なデータベースによるものです。
一度もない。
リレーショナル データベース理論を無視することで解決しようとしている問題が何であれ、より多くの扱いにくい問題を生み出すだけです。さらに、リレーショナル理論を無視して回避しようとする元の問題は、いずれにせよ、常に誤解に基づいています。