外键

我对数据库中的外键列使用空值与默认值有疑问。在设计数据库时,我发现有关空值和默认值的许多相反意见,但并非完全针对外键(主要优点和缺点)。 目前,我正在设计一个新的数据库,该数据库将为不同的Web应用程序和具有不同数据访问方法(ORM,存储过程)的其他系统存储大量数据,我想在最低级别上实现通用规则(数据库) 。 (因此,以后不必在应用程序中担心此规则)。 举个例子,假设我有一个用户
User
表,他的国籍为
NationalityID
,带有外键列,这是表
Country
的主键
CountryID
。 现在我有两个/三个选项: 答:我允许
NationalityID
列(以及数据库中所有其他类似的外键列)为空,并且始终遵循检查空无处(在应用程序中应用规则)的通用方法 要么 B:我为每个外键都指定一个默认值,比如说“ -1”,并在每个关系表中以“ -1”作为键,所有其他数据都作为“否”。数据\”(对于本示例,在“ 3”表中,我将“ CountryID”列设置为“ -1”,对于“ 6”,我将其设置为“无数据”)。因此,每次我想知道用户的国籍时,我总是会得到没有附加代码规则的结果(无需我检查它是否为null)。 要么 C:我可以禁止外键使用null值。但这确实是我要避免的事情。 (如果没有其他数据(用户国籍),我需要选择至少存储基本数据(用户名)) 那么B是好的方法吗?我在这里想念什么?通过这种方法,我会失去更多的收益吗?我可能会遇到哪些问题(除了要小心,始终在关系表中使用ID值为“ -1”表示“没有数据”的其他列)? 您对外键默认值的好/坏经历是什么? 谢谢     
已邀请:
如果将其标准化,将不会有问题。 不要将国籍放在“ 7”表中,而是创建“ 8”表,将用户链接到另一个表中的“ 9”。 如果他们在该查找表中有一个条目,那就太好了。如果不是,则无需存储
NULL
或默认值。 您需要强制执行FK关系,并允许
NULL
相反。您也不想只填充一个字段就构成不正确的信息,这否定了首先需要该字段的观点。 使用查找表,您可以完全绕开它。 这也将使您改变主意,并在将来选择一种选择。 如果使用视图,则可以选择将丢失的数据视为“ 10”或默认值,而无需更改基础数据。     
就个人而言,我认为即使数据库中的非输入项的键值为-1,您仍将进行检查以查看是否要为每个人显示“无数据”领域。 我会坚持使用NULL。 NULL意味着没有数据,在这里就是这种情况。     
B是一个可怕的方法。记住处理空值比必须弄清楚您使用了哪个幻数要容易得多,然后您仍然必须处理它们。使用数字1。但是我最喜欢JNK的想法。     
我建议使用选项D。如果不是所有用户都具有定义的国籍,则该信息不属于用户表。创建一个名为UserNationality的表,该表键入UserId。     
我喜欢您的B解决方案。也许可以将这些值映射到其他实体,因此您拥有Country和NullCountry来扩展Country并被映射到id = -1的行,并且在其方法中具有特殊的代码以使其易于处理特殊情况。 一个问题可能是,在该外键上进行外部联接将变得更加困难。 编辑:不,外部联接应该没有问题,因为没有必要进行外部联接。     

要回复问题请先登录注册