データベースの構造/設計

一般的な規則やベストプラクティスはなく、外部キーはnull許容であってはなりません。多くの場合、あるエンティティが別のエンティティと関係を持たないことは完全に理にかなっています。たとえば、追跡しているアーティストのテーブルがあるが、現時点では、それらのアーティストによって録音されたCDはありません。

音楽/オーディオまたはソフトウェアのいずれかであるメディア（CD、DVD、BluRay）を使用する場合、共通の情報を含むテーブルと、各拡張テーブル（AudioDataおよびSoftwareData）に1つずつ、2つの外部キーを使用できます。 NULLである必要があります。これは、とりわけ、排他的アークと呼ばれる状況を示します。これ一般的に...問題があると考えられています。

JavaやC++などのオブジェクト指向言語のスーパークラスと2つの派生クラスについて考えてみてください。リレーショナルスキーマでそれを表す1つの方法は、次のとおりです。

create table Media(
    ID      int not null, -- identity, auto_generated, generated always as identity...
    Type    char( 1 ) not null,
    Format  char( 1 ) not null,
    ... <other common data>,
    constraint PK_Media primary key( ID ),
    constraint FK_Media_Type foreign key( Type )
        references MediaTypes( ID ), -- A-A/V, S-Software, G-Game
    constraint FK_Media_Format foreign key( Format )
        references MediaFormats( ID ) -- C-CD, D-DVD, B-BluRay, etc.
);
create unique index UQ_Media_ID_Type( ID, Type ) on Media;
create table AVData( -- For music and video
    ID       int not null,
    Type     char( 1 ) not null,
    ... <audio-only data>,
    constraint PK_AVData primary key( ID ),
    constraint CK_AVData_Type check( Type = 'A',
    constraint FK_AVData_Media foreign key( ID, Type )
        references Media( ID, Type )
);
create table SWData( -- For software, data
    ID       int not null,
    Type     char( 1 ) not null,
    ... <software-only data>,
    constraint PK_SWData primary key( ID ),
    constraint CK_SWData_Type check( Type = 'S',
    constraint FK_SWData_Media foreign key( ID, Type )
        references Media( ID, Type )
);
create table GameData( -- For games
    ID       int not null,
    Type     char( 1 ) not null,
    ... <game-only data>,
    constraint PK_GameData primary key( ID ),
    constraint CK_GameData_Type check( Type = 'G',
    constraint FK_GameData_Media foreign key( ID, Type )
        references Media( ID, Type )
);

映画を探している場合は、AVDataテーブルを検索してから、Mediaテーブルと結合して、残りの情報などをソフトウェアやゲームで検索します。 ID値はあるが、その種類がわからない場合は、Mediaテーブルを検索すると、Type値により、3つ（またはそれ以上）のデータテーブルのどれに結合するかがわかります。重要なのは、FKがを参照しているということです。ジェネリックテーブルからではなく、ジェネリックテーブル。

もちろん、映画、ゲーム、またはソフトウェアは複数のメディアタイプでリリースできるため、Mediaの間に交差テーブルを作成できます。テーブルとそれぞれのデータテーブル。おと、それらは一般的に異なるSKUでラベル付けされているので、それらを異なるアイテムとして扱いたい場合もあります。

ご想像のとおり、コードはそれほど悪くはありませんが、かなり複雑になる可能性があります。 Otoh、私たちの設計目標は、コードの単純さではなく、データの整合性です。これにより、たとえば、ゲームデータを映画アイテムと混合することができなくなります。そして、1つだけが値を持ち、他はnullでなければならない一連のフィールドを持つことを取り除きます。