リレーショナルデータベースを正規化する場合、複数の「タイプ」テーブルを1つに結合する必要がありますか？
Webサイトのコンテンツ、機能、デザインに大幅な変更を加える前に（私はすべてをリファクタリングし、ほぼ完全に書き直します）、以前はすべてのデータをMySQLデータベースに保持するために新しいPostgreSQLデータベースを設定しています。また、大幅にカスタマイズされたWordPressブログです。このブログに移動し、2つのサイトを効果的にマージします。Webサイトの前面のコンテンツの他に、クライアント情報、販売履歴、請求書、イベント収入など、私が自分で使用するためにデータベースに保存する他の多くの情報。慎重に検討し、再設計するために多くの時間を費やしています。データの整合性とパフォーマンスの両方を念頭に置いてデータベースを適切に管理します。
前面のWebサイトには、さまざまな「コンテンツ」タイプがあります。ページ、イベント/ギグ、マルチメディアサンプル、楽譜/チャート（これらの一部は、PDFサイト）、ブログ記事など.
私が行った変更の1つは、会場/場所の保管方法です。以前は、「venue type」テーブルを参照する「venues」テーブルと、「countries」テーブルを参照する「states/provinces」テーブルを参照する「cities」テーブルがありました。この情報のほとんどは「イベント」で使用されましたが、その後、都市テーブルを参照するために必要なクライアント情報を追加しました。さらに、私のブログ記事はすべてジオタグが付けられているため、これらの場所も参照する必要があります。すべてのテーブルに非常に類似したスキーマがあったため、私がやったことは、「id」列と「parent_id」列を持つ新しい「場所」テーブルを作成して、場所を階層形式で格納できるようにすることです。また、「places_type」テーブルもあるので、各行のparent_idを場所自体よりも上位の階層型にする必要があります。 （たとえば、都市は州または国を親タイプとして持つことができますが、都市はレストランを親タイプとして持つことができません。）
これを行う際、階層内の他のコンテンツの「タイプ」を保持するために、まったく同じスキーマ（id、parent_id、name）を持つ他の多くのテーブルを作成しました。ジャンル、支払い方法、チャートタイプ、イベントタイプ、メディアタイプ、請求書タイプなど。
すべてのテーブルがまったく同じスキーマを持っているので、これらすべてのテーブルを1つの「タイプ」テーブルに結合し、「カテゴリ」フィールドをテーブルに追加する方が良いでしょうか？
1つの「タイプ」テーブルを管理する方が、11の類似したテーブルよりもはるかに簡単だと思います。今のところ、この「types」テーブルには約60行しか格納できないと計算しました。
データベース設計の観点から、この種のベストプラクティスは何でしょうか。データは、更新/追加されるよりもはるかに頻繁に取得されます。
同時に、この1つの「タイプ」テーブルはすべてのタイプをすべて保持するため、（ビューを介して）多くのテーブルに何度も結合する必要があります。たとえば、イベント情報を取得するには、「events」テーブルを「places」、「artists」、「media」テーブルにすでに結合していますが、これらのテーブルを「types」テーブルに結合してイベントタイプを取得する必要もあります。プレイスタイプ、アーティストタイプ、メディアタイプ。それで、型テーブルを別々に保つか、それらを1つに組み合わせるのが最善でしょうか？どうして？
タイプごとに個別のテーブルを用意します。行数が非常に少ないため、どちらの方法でもパフォーマンスは考慮されません。個々のテーブルには、1ページまたは2ページしかありません。結合されたテーブルについても同様です。
どちらの方法でも、ビューを完成させるには「タイプ」テーブルを結合する必要があります。この抽象化レベルでは挿入はほとんど行われないため、どちらの方法でもロックが問題になることはほとんどありません。
しかし、私にとっては、異なるテーブルを使用すると、論理的に異なるアイテムが分離されたままになり、よりすっきりしたデザインになります。
ある種のタイプテーブルとの関係を持つさまざまなテーブルが存在します。多くの異なるタイプのテーブルがある場合、外部キーの関係は自己文書化され、DRIを介して適用されます。 1つの結合されたテーブルでは、DRIを使用して「Venue.TypeIDがType.TypeIDから来ていると言うことは困難ですが、たとえば、Type.Category = 'V'の場合のみ」です。この関係の補完的な側面-「Type.Category = 'V'のType.TypeIDはVenueテーブルでのみ使用できます」も、私が知っているRDBMSのDRIではサポートされていません。
データベースのテーブルレイアウトは、格納する情報の粒度に依存します。エンティティダイアグラムソフトウェアパッケージを使用して、新しいデータベースをライブデータで埋める前に理論的にレイアウトしてから、「うんざり」していて列やテーブルを忘れていることに気づくようにしてください。ある時点で、持っていない情報が必要な場合は、現時点で空であっても、すぐに計画してください。一方、失われた粒度を、最適化の増加と引き換えに利用する場合は、テーブルを折りたたむことが可能です。