例如，我有2个表:'customer'和'staff'。它们几乎是一样的，只有两个属性不同。那么，我是否应该创建另一个名为"person"的表，其中包含"customer"one_answers"staff"的所有相同属性，然后创建指向该"person"的fk键?类似于类设计中的继承。
这个方法有缺点吗?
是的，这种方法有一个缺点。连接会增加查询的复杂性(在某些情况下非常复杂)，如果不小心的话，还会增加查询时间。
相反，做这件事的标准方法(例如，当子类之间只有几个属性不同时模拟对象继承)是做一些叫做单表继承的事情。此方法以牺牲少量未使用的数据库空间为代价来防止数据库连接。
的工作原理是这样的:您创建一个包含所有属性的表，包括仅应用于其中一个或另一个属性的表，以及用于指定对象类型的type属性。例如，如果customer具有以下属性:
id, name, email, password, order_date
AND staff有属性:
id, name, email, password, hire_date
然后创建一个包含所有属性和类型的列的表:
id, type, name, email, password, order_date, hire_date
type列将始终包含"customer"或"staff"。如果type是"customer"，那么hire_date总是NULL，没有意义。如果type是"staff"，那么order_date总是NULL，并且没有意义。
您正在描述一个称为类表继承的模式。这是一个有效的设计，但像任何其他设计一样，它必须有良好的判断力。阅读Martin Fowler的"企业应用程序架构模式"，了解其优缺点的更多细节。
有些人反对使用连接，但是只有在需要特定于子类的列时才需要连接。当给定的查询只需要公共列时，可以避免额外的连接。
Pranay Rana和Ben Lee都是正确的，最终的答案是:"视情况而定"。
您必须权衡子类特定列的数量与公共列的数量，以决定哪种列适合您。单表继承不能很好地扩展:当必须引入第三种类型的子类(比如供应商)时会发生什么?
对于这个问题，你将如何对待员工，同时也是客户?查找"泛化专门化关系建模"。你会找到一些关于这个主题的好文章。大多数示例都遵循与Bill给您的类表继承链接相同的模式。
还有一个小细节。专用表(在您的示例中用于客户和员工)不自动编号其id字段。相反，在填充它们时，id字段应该获得广义表(在您的示例中是person)中id字段的副本。
这使得专门化的id执行双重任务。它们都是对一般化表中相应行的pk和fk引用。这使得连接更容易和更快。
创建将每个专门化表与通用表连接起来的视图是很方便的。或者，您可以创建一个大视图，生成与另一个响应建议的单表继承模式相同的数据。它基本上是一堆连接的并集。
我说它的设计很好，因为你没有重复数据，这就是数据规范化的原因。
只有一件事是，随着您规范化，您的join数将会增加。