问(有点)复杂的数据库结构和简单的空字段

EN

问得好。

这适用于您可能选择实现的任何抽象，无论是在代码中还是在数据库中。您是为Facebook用户和“普通”用户编写单独的类，还是在一个类中处理这两种情况？

第一个选择是更复杂的。为什么这么复杂？因为它更容易扩展。您可以轻松地包括其他身份验证方法(例如，用于Twitter ID的表)，或者扩展Facebook表以包括.其他一些facebook的特定信息。您已经将特定于每个身份验证方法的信息提取到它自己的表中，允许每个方法单独使用。这太棒了！

交换条件是，查询需要更多的精力，选择和插入需要花费更多的精力，而且可能会变得更加混乱。对于十几种不同的身份验证方法，您不需要一打表。而且，除非您从两个验证方法中获得了一些好处，否则您并不真正需要两个表。你需要这种灵活性吗？身份验证方法都是相似的--它们将有一个用户名和密码。这个抽象允许您存储更多特定于方法的信息，但是该信息存在吗？

第二种选择正好相反。更简单，但是您将如何处理未来的身份验证方法，如果您需要添加一些特定于身份验证方法的信息呢？

就我个人而言，我试图评估这个身份验证组件对系统的重要性。记住YAGNI -你不会需要它的-并且不要过度设计。除非您需要第一个选项提供的扩展性，否则请使用第二个选项。如果有必要的话，你可以随时提取它。

首先是柯克说的话。它很好地总结了每一种备选设计的可能后果。第二，知道其他人对同一个问题做了什么是值得的。

您所描述的情况在ER建模圈中称为"ER专门化“。专门化只是子类概念的不同措辞。您呈现的图表是在SQL表中实现子类的两种不同方法。第一个名称是“类表继承”。第二个表的名称是“单表继承”。

如果您确实使用了Class表继承，那么您将需要应用另一种技术，即“共享主键”。在此技术中，facebookuser和copies用户的id字段将是来自用户的id字段的副本。这有几个优点。它强化了这种关系的一对一性质。它在子类表中保存额外的外键。它自动提供使联接运行更快所需的索引。它允许一个简单、容易的连接，将专门的数据和广义数据放在一起。

您可以在此处查找"ER专门化“、”单表继承“、”类表继承“和”共享主键“作为标记。或者你也可以在网上搜索相同的主题。你将学到的第一件事是柯克总结得很好。除此之外，您还将学习如何使用每种技术。

这取决于您正在使用的数据库。例如，Postgres的表继承对于您的示例来说是很好的，下面看一看：http://www.postgresql.org/docs/9.1/static/tutorial-inheritance.html

现在，如果您没有表继承，您仍然可以创建视图来简化查询，所以这里的“复杂”示例是一个可行的选择。现在，如果您有无限的时间，而不是第一个(对于这个简单的例子，更喜欢使用表继承)。

然而，这使得事情变得更加复杂，因此您将花费更多的时间来实现和维护。如果您有许多这样的表层次结构，那么它也会对性能产生影响(因为您必须连接许多表)。我曾经开发过一个数据库模式，它过度使用了这种层次结构(概念上)。最后，我们决定在概念上保留层次结构，但在实现中将层次结构夷为平地，因为它变得如此复杂，不再可维护。

当您将层次结构扁平化时，您可能会考虑不使用null值，因为这也会使事情变得更加困难(或者您可以使用-1或其他什么的)。

希望这些想法能帮助你！