没有一般规则或最佳实践，外键不应为空。很多时候，一个实体与另一个实体没有关系是完全合理的。例如，您可能有一张您跟踪的艺术家表，但目前您没有这些艺术家录制的 CD。
对于可以是音乐/音频或软件的媒体（CD、DVD、蓝光），您可以有一个包含公共信息的表，然后是两个外键，每个扩展表一个（AudioData 和 SoftwareData） ，但必须是NULL。这提出了一种称为排他弧的情况。 这通常被认为是...有问题的。
想一想Java 或C++ 等OO 语言中的一个超类和两个派生类。在关系模式中表示它的一种方法是：
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 值将告诉您要连接三个（或更多）数据表中的哪一个。关键是 FK 指的是 to 通用表，而不是来自它。
当然，电影、游戏或软件可以在多个媒体类型上发布，因此您可以在Media 表和相应的数据表之间建立交集表。 Otoh，它们通常标有不同的 SKU，因此您可能还希望将它们视为不同的项目。
正如您所料，代码可能会变得相当复杂，但还算不错。 Otoh，我们的设计目标不是代码简单，而是数据完整性。例如，这使得无法将游戏数据与电影项目混合。并且您摆脱了一组字段，其中只有一个必须有值，其他必须为空。