複数のデータベーステーブルまたは1つに結合

Question

データベースアーキテクチャに関する質問があります。

私たちはCMSを構築しています。あらかじめ設定された選択肢を持つフィールドはたくさんあります。例としては、顧客の信用状態が「良い」、「悪い」、「不明」、「預金を取る」などがあります。このプロジェクトの仕様では、これらの事前設定された選択項目は動的であるため、管理者はバックエンド経由で新しい値を追加できます。だから私はこれらの値をデータベースに保存する必要があります。

私は、リストの種類ごとのテーブルを持っている）の二つのアプローチ

1の間で決めるのに苦労しています。例としては、list_CrediStatus、list_Branches、list_Marketsなどの表があります。

利点は、表が巨大ではなく、互いに離れていることです。したがって、1つのテーブルのデータとクエリの負荷が他のテーブルに影響することはありませんか？欠点は、それらの多くが存在するということです。おそらく30？また、テーブルごとにクエリを行う必要があります。

2）2つのテーブルがあります。すべての異なるリスト名（list_CreditStatus、list_Branchesなど）を定義するための説明テーブルがあります。他のテーブルには、すべてのリストのすべての値と、各行を説明テーブルの識別子にリンクする外部キーが含まれています。

利点は、テーブルが少なく、クエリと統一されたフォーマットが1つです。欠点はパフォーマンスにあります。この表には多くの質問が必要です。それは多くの行と多くのデータを持っています。

誰にもアドバイスがありますか？私はオプション2に向かっています。これが意味をなさないかどうか私にも教えてください。はっきりと書くのは難しい質問でした。

おかげで、 ジェド

Answer 1

常に1つのテーブルにあるようにして、別のテーブルにあるものとは異なります。これは、オプション1と一緒に行くことを意味します。覚えておいてください：フィールド名に基づく類似の類似性は、それらが物事のようなものであることを意味しません。

シンプルに見えるので魅力的ですが、そうではありません。これらを分離しておく必要があるコードはかなり複雑になります。

さらに、適切な外部キーを使用することはできません。どのようにORDERに誰かがBlood Type（またはその他の）値を落とすことなく、リストテーブルを参照するCREDIT_STATUS列を持っているとしますか？

Answer 2

は、私はタイプごとにテーブルを持っているでしょう。どうして ？他の理由の中でも、これらのデータタイプは徐々に追加の情報、具体的にはそのタイプのが徐々に発生していることがわかります。すべてが1つのテーブルに統合されている場合は、それを満たすのが非常に難しいでしょう。

（免責事項：月、日、種類の商品、真偽（はい！）、休日の日付などを含むテーブルでこのようなシステムに取り組んだことは、基本的には巨大な雑用バッグでした。 Celestial Emporium of Benevolent Knowledge）

テーブルあたりのクエリについて心配する必要はありません。これがデータベースの優れた点であり、あまり早くには最適化しません。問題や問題が発生するまでは、

Answer 3

あなたが話していることは、それが実際に名前を持っているのでとても悪いです。これは一般的に、アンチパターンとして知られているもので、避けるべきソフトウェア開発のパターンです。

名前はOne True Lookup Tableです。

1つのリンクが含まれていますが、その用語を他のものに使用してください。

テーブルが良好であり、参照整合性が良好です。

必要に応じて両方を使用します。

Answer 4

ドメイン制約のテーブルについて話しているように私には聞こえるが、間違っている可能性がある。実際、ドメインの制約について話しているなら、それぞれのドメインの制約がそれぞれのテーブルに必要です。両方のこれらのテーブルは、

cr_status  cr_status_abbr cr_status 
--    ------------------------- 
Good      G  Good 
Bad      B  Bad 
Unknown (or Unkn)   U  Unknown 

防御であり、双方は、その主キーとして整数を使用して、ドメイン制約を実装テーブルより（IMO）に優れています。 （このような各テーブルは人間が利用できる情報を得るために追加の結合が必要なので）