2

すべてルックアップテーブルであるため、同じ数の列と名前を持つテーブルがたくさんあります。たとえば、LabelTypeテーブルとTaskTypeテーブルがあります。LabelTypeテーブルとTaskTypeテーブルには、TypeID列とTypeName列があります。これらは、shippingLogテーブルを含むLabelTypeテーブルやEmployeeTaskテーブルを含むTaskTypeテーブルなどの他のテーブルで外部キーとして使用されます。

LabelType Table
TypeID TypeName
1      Fedex
2      UPS
3      USPS

TaskType Table
TypeID TypeName
1      Receiving
2      Pickup
3      Shipping

これまでに20以上のテーブルがあり、今後も増え続けると思います。私はそれで問題はありませんが、テーブルを使用するより良いまたはより賢い方法があるかどうか疑問に思っています。これらすべてのテーブルを1つのルックアップタイプテーブルとして統合し、ルックアップテーブルから外部キーを追加してそれらを区別することも考えていました。ルックアップテーブルには、Label、Taskなどのデータが含まれている場合があります。その場合、これらすべてのルックアップデータに対して1つまたは2つのテーブルが必要です。

データモデリングのより良いまたはよりスマートな方法があるかどうか教えてください。

4

2 に答える 2

6

データの構造が似ているからといって、同じ意味や同じ制約があるとは限りません。ルックアップテーブルを分離してください。これにより、外部キーが分離されたままになるため、データベースは、間違った種類のルックアップデータを参照することから自身を保護できます。1

親テーブルで基本構造を定義し、子テーブルに特定のFKを追加するだけで、リレーショナルDBMSが継承をサポートすることを望みます。現在のところ、DDLでの繰り返しに耐える必要があります...

注：「ルックアップテーブルを分離しておく」ルールの1つの例外は、システムを動的にする必要がある場合（つまり、データベースに新しい物理テーブルを実際に作成せずに新しい種類のルックアップデータを追加できる場合）ですが、そのようには見えません。あなたの質問からの方法。

1 1つの大きなルックアップテーブルでは、FKだけでは、（たとえば）ShippingLogテーブルがテーブル用の行を参照するのを停止しませんEmployeeTask。関係の識別とPKの移行を使用することで、これから身を守ることができますが、冗長性を導入し、注意深い制約を必要とすることはありません。単に正しいことを行い、ルックアップテーブルを分離しておく方が、よりクリーンで、おそらくよりパフォーマンスが高くなります。

于 2012-08-25T19:01:50.420 に答える
1

ルックアップテーブルを分離してください。ルックアップ時の方が高速であり、新しいルックアップテーブルを追加するときの間に何百万ものルックアップを実行します。

多くのテーブルは大きな問題ではありません。

于 2012-08-24T23:49:15.820 に答える