SQLテーブルの正規化

Question

私はプロジェクト用のテーブルをいくつか作成していますが、テーブルの多くは同じ構造（Id、Name）を持っていますが、異なるものに使用されていることがわかりました。正規化をどこまで行う必要がありますか？私はそれらをすべて1つのテーブルに構築するか、より良い理解のためにそれらを分けておく必要がありますか？どのようにパフォーマンスに影響を与えますか？

例1：（ログのアクションのタイプに使用）

（ログ内のオブジェクトのタイプに使用）TableObjectType

Id Name 
1 User 
2 MobileDevice 
3 SIMcard 

TableAction

Id Name 
1 Create 
2 Edit 
3 Delete 

TableStatus（使用デバイスが持つことができるステータスの場合）

Id Name 
1 Stock 
2 Lost 
3 Repair 
4 Locked 

---

例2：私のテーブルは他の名前を持っているよう

TableConstants

Id Name 
1 User 
2 MobileDevice 
3 SIMcard 
4 Create 
5 Edit 
6 Delete 
7 Stock 
8 Lost 
9 Repair 
10 Locked 

---

は、ネーミングを無視し、私は明確化のためにこれらを使用しています。

すべての定数に1つのテーブルを使用することの欠点は、後ほど追加したい場合は、実際には「グループ」には入りませんが、SQLでは、特定の順序に依存しないでください。データを使用します。

Answer 1

テーブルが別のテーブルと類似の構造を持っているという理由だけで、同じエンティティを説明するデータを格納するわけではありません。

は2

まず例に行くにはないいくつかの明白な理由があり、有効なオブジェクト型である値にあなたのObjectTypeID列の値を制限することもできます。これを行う明白な方法は、ObjectTypeテーブルへの外部キー関係を作成することです。 TableConstantsの同様のチェックを作成する方がはるかに難しくなります（ほとんどのデータベースエンジンでは、このように外部キー制約を使用することはできません）。

第2に、データベースを自己説明的にします。スキーマを検査している人は、 "オブジェクトタイプ"がビジネスドメインで意味のある概念であることを理解します。これは、長寿命のアプリケーションや大規模な開発チームを持つアプリケーションにとって重要です。

第3に、これらの参照で特定のビジネスロジックを取得することがよくあります。たとえば、「ステータス」では、「ステータスがロックされているレコードを変更できません。このビジネスロジックでは、追加のデータ属性を格納する必要があります。これは、「定数」テーブルでは実際には不可能です。

第4に、「定数」を管理する必要があります。大きなスキーマを使用している場合、非常に迅速に人々はわずかに異なる概念を反映するために定数を再利用し始めます。あなたの「作成」定数は、ビジネス要求とログイベントを格納するテーブルに適用される可能性があります。これはほとんど理解できなくなります。ビジネスが「作成」を意味するのではなく「書き込み」すると判断した場合、ビジネストランザクションはすべて間違って見えるようになります。

はとすることができます。多くのロジックを持たない名前を格納することのない属性をモデル化するために、多くのデータベースエンジンがこれをサポートするENUMを使用します。これによりリスク1,2、および4は削除されますが、ロジックがデータベーススキーマにエンコードされていることを意味します。新しいオブジェクトタイプを追加することは、データ挿入ではなくスキーマの変更です。

Answer 2

一般的に、テーブルを分けておく方が良いと思います。特定のケースでは（あなたの選択です...）、類似するすべてのテーブルを1つにマージすることができます（もちろん、他のカラムをTAB_TYPEとして別個に追加することもできます）。これにより、アプリケーションの開発や全体的なテーブルの数（これはあなたにとって問題です）。
すべてが比較的小さいテーブル（レコードが少ない）の場合は、パフォーマンスに問題がないはずです。