外键

如何解决外键

我对数据库中的外键列使用空值与默认值有疑问。在设计数据库时，我发现有关空值和默认值的许多相反意见，但并非完全针对外键（主要优点和缺点）。 目前，我正在设计一个新的数据库，该数据库将为不同的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的行，并且在其方法中具有特殊的代码以使其易于处理特殊情况。 一个问题可能是，在该外键上进行外部联接将变得更加困难。 编辑：不，外部联接应该没有问题，因为没有必要进行外部联接。