ほとんどの列値に Lookup/Enum 参照を使用するテーブルが多数あります。例:
Person テーブル - PersonID | レースコード | ヘアカラーコード | ヘアスタイルコード | TeethConditionCode
ロケーション テーブル - LocationID | サイズコード | エクステリアカラーコード | ConditionCode
Race、Size、Color、Condition などは、Code ルックアップ テーブルへの外部キー参照にすぎません。このコード テーブルには他のフィールドがありますが、私の質問には重要ではありません。データベースは SaaS アプリケーション用です。これは、各クライアントが独自の色、人種、状態などのリストを持つことができることを意味します。クライアントが変更できない静的なコードがいくつかあります。
1 つのコード テーブルまたは 2 種類のコード テーブル (顧客が定義したものには DynamicCodeTable、1 つの変更に対しては StaticCodeTable) を使用する方が良いですか、それとも各コード タイプ (RaceCodeTable、HairColorTable、Condition など) に対してテーブルを使用する必要がありますか?
私が最も心配しているのは、すべての sql 結合です。私が使用している Person テーブルには、これらのコード属性が 20 以上あります。20 の異なるテーブルに参加するときと、同じテーブルに 20 回参加するときのパフォーマンスに違いはありますか? 複数のテーブルを持つということは、各テーブルが小さくなり、ルックアップにかかる時間が短縮されることを意味します。しかし、単一のテーブルを持つことも簡単です。助言がありますか？
4 に答える
このトピックは、「One True Lookup Table」（略してOTLT）というテーマで、過去15年間にわたって詳細に議論されてきました。このようなアプローチの利点は、データベースの初心者に飛躍します。欠点は時間の経過とともに現れます。OTLTの欠点については、次のリンクを参照してください。
- http://tonyandrews.blogspot.com/2004/10/otlt-and-eav-two-big-design-mistakes.html
- http://web.archive.org/web/20100130062850/http://www.dbazine.com/ofinterest/oi-articles/celko22
または、検索しOTLTてさらにディスカッションを見つけてください。
多くのルックアップテーブルとそれらのメンテナンス画面を作成する場合、すべてのコード、すべての説明、およびコードと説明のペアが格納されているテーブルの名前を含む巨大なUNIONを作成することにより、OTLTをシミュレートするビューを作成できます。 。自分が何をしているのかを知っていれば、半自動の方法を使用してそのような和集合を生成することが可能です。半自動メソッドを使用すると、数百のルックアップテーブル用の単一のメンテナンス画面を作成し、その画面とテーブルの間にロジックを配置して、正しいテーブルに新しいコードを挿入できるようになると思います。
ユーザーが新しいコードの値だけでなく、新しいコードのタイプを導入できるようにすることに関しては、ワームの大きな缶全体が開かれます。EAVについて説明している上記の記事を参照してください。これは、ユーザーが独自の基礎となるデータ構造を設計できるため、非常に魅力的です。パフォーマンスを無視すると、これはしばらくの間かなりうまく機能します。ユーザーや対象分野の専門家からデータ構造を学ぶことなく、完全に一般的なデータベースを取得できます。
それが本当の悲しみにぶつかるときは、それが統合されたデータベースであるかのようにデータを使おうとするときであり、データについてのばらばらな意見の寄せ集めではありません。この時点で、顧客が定期的なレポート生成を期待しているときに、深刻なデータ考古学に取り組んでいます。幸運を。
（「データマイニング」を「データ考古学」に変更するために編集）
アプリケーションや要件について詳しく知らなくても、コードの種類ごとに 1 つの表を作成することをお勧めします。IMOデータベースの設計は、コードの種類ごとに外部キーを持つことで、より明確になり、自己文書化されます。
潜在的なパフォーマンスの違いがあります。
わずか 2 行のテーブルでは、これら 2 つの小さな行のためにキャッシュ内の多くの領域が占有されます。
1 つのテーブルに多数のルックアップ値がある場合、効果的には、それらの値をより密にキャッシュに詰め込みます。
かなり幅の広いテーブルを再設計する際に、これらすべてのルックアップ テーブルが優れたアイデアであると考えるのは間違いでした。非常に多くの柔軟性などがありますが、コード化するのがはるかに難しくなり、ナビゲートすることが不可能になり、ただのお尻の痛みでした.
それで、私は何を学びましたか？
- 静的な値の場合は、列挙型を使用するだけです。これははるかに高速で便利です。この決定は、同じ変数を参照する可能性のある他のテーブルの数に応じて行う必要があります。
- 考えられる限り多くのルックアップ テーブルを作成するのではなく、少数のルックアップ テーブルに固執してください。JOIN ははるかに遅くなります。
- ナビゲートしやすいように、データベース VIEW を設計します。それはあなたの人生をずっと楽にしてくれます。
- おまけとして、クライアントが特定のテーブル (つまり、静的テーブル) に触れたり、enum 列の値に触れたりしたくない場合は、MySQL (たとえば) のきめの細かいパーミッションを使用して、特定のテーブルの特定の列への変更を無効にすることができます。 . 多くの人は、これらのアクセス許可がどれほど柔軟になるかを理解していません。