Jan*_*nez 3 sql-server nhibernate database-design foreign-keys default-value
我有一个关于对数据库中的外键列使用null与默认值的问题.在设计数据库时,我发现了很多关于null与默认值的相反意见,但不完全是外键(主要优点和缺点).
目前我正在设计一个新的数据库,它将为不同的Web应用程序和其他具有不同数据访问方法(ORM,存储过程)的系统存储大量数据,并且我希望尽可能在最低级别实现一般规则(数据库).(所以不要在以后的应用程序中担心这个规则).
举个例子,假设我有一个用户表,User其中包含国籍的外键列,NationalityID这是CountryID表的主键Country.
现在我有两个/三个选项:
答:我允许NationalityID列(以及数据库中所有其他类似的外键列)为空,只需坚持使用常见的方法检查null(在应用程序中应用规则)
要么
B:我为每个外键指定一个默认值,让我们说"-1",并在每个关系表中添加"-1"作为键,其他所有数据作为"无数据"(对于本例中的Country表格)我把CountryID为"-1"的列和CountryName我设置为"No data"的列.因此,每次我想知道用户的国籍时,我总是会得到没有额外代码规则的结果(我不需要检查它是否为空).
要么
C:我可以禁止外键的空值.但这确实是我想要避免的.(如果不是附加数据(用户国籍),我需要有一个存储至少基本数据(用户名)的选项)
那么B好的做法是不是？我在这里错过了什么？我通过这种方法获得了更多的收益吗？我可以遇到哪些问题(除了要小心在ID值为"-1"的关系表中总是有额外的列,表示"没有数据")？
您对外键默认值的好/坏经历是什么？
谢谢
如果你正常化,这将不是一个问题.
不要将国籍放在USER表中,而是创建一个User_Nationality将用户链接到Country_ID另一个表中的表.
如果他们在该查找表中有一个条目,那很好.如果不是,则无需为其存储NULL或默认值.
您需要强制执行FK关系,并且允许NULL违反该关系.您也不希望仅仅为填充字段而构建可能不准确的信息,从而否定了首先要求字段的要点.
使用查找表,您可以完全绕过它.
这也可以让您改变主意,选择其中一个选项.
如果使用视图,则可以选择将缺失数据视为NULL默认值或默认值,而无需更改基础数据.