我们公司有许多不同的实体，但这些数据库实体中有很大一部分是人。因此，我们有客户，员工，潜在客户，承包商和提供商，所有这些都有一些共同的属性，即姓名和联系电话号码。
我可能已经过度使用面向对象的思维，但现在我正在制作一个包含所有人的“Person”表，其中flags /子表“扩展”该模型并将基于角色的属性添加到联结表有必要的。如果我们说有250,000人（在MySQL和ISAM上）会对性能产生如此大的影响，以至于未来的DBA会永远诅咒我吗？我们最常见的搜索是姓名/姓氏组合。
对于，例如像Salesforce这样的公司，客户/潜在客户/员工都在一个集中的表中，有子视图（想要更好的术语），还是分成不同的表？
警告：这个问题与“我们发现在现实世界中做得更好”而不是理论设计有关。我喜欢上述解决方案，并且相信通过视图，正确的大小和准确的索引，性能不会受到影响。我也觉得上面不算是一个MUCK，只是一张相当大的桌子。
答案 0 :(得分：1)
由于您有许多不同的“类型”人员，为了进行规范化设计，使用适当的外键约束，最好使用超类型/子类型模式。一个Person表（包含所有属性的共同表）和许多子类型表（Employee，Contractor，Customer等），所有这些都与之形成1：1的关系主人员表，以及每种人员的必要细节。
@Branko查看此答案的示例：Many-to-Many but sourced from multiple tables
答案 1 :(得分：1)
一个'人'表是最灵活，最有效，最无故障的方法。
您可以轻松进行有限的搜索 - 例如，查找具有此姓氏的所有人以及谁是客户。但是当你不知道它们是什么时，你可能还会发现你必须找一个人 - 当你有一个'人'表时，这将是最简单的。
但是，你必须考虑一个人对你来说是多件事的可能性 - 一个顾客，因为买了一些东西和一个承包商，因为你雇用了他们的工作。因此，最好有一个“连接”表，它可以为您提供多对多的关系。
create person_type (
person_id int unsigned,
person_type_id int unsigned,
date_started datetime,
date_ended datetime,
[ ... ]
)
（当然，你需要添加索引和外键.person_id是'人'表的FK;'person_type_id'是所有可能的人类型的参考表的FK。我添加了两个日期字段，这样你就可以确定某人何时对你有用。）
答案 2 :(得分：0)
数据库的250.000条记录不是很多。如果您正确设置索引，您将永远不会发现任何问题。
您应该为用户设置类型。这些类型应该在不同的表中，因此您可以看到类型的含义（使其成为TINYINT或类似）。如果您需要为每个用户类型添加其他字段，您确实可以为其创建不同的表。
这种方法听起来对我很好
答案 3 :(得分：0)
理论上，有可能成为您工作的公司的客户。
但如果不是这种情况，那么你可以根据他们的角色将人们存储在不同的表中。
然而，像Topener所说，250.000并不多。所以我个人觉得把每个人都存放在一张桌子里是安全的。然后为每个角色（员工，客户等）设置一个列
答案 4 :(得分：0)
即使您最终得到一个表解决方案（对于核心人员属性），您也希望使用视图对其进行抽象并添加一些约束。
您要做的最后一件事是向客户发送机密信息，因为有人没有正确加入，这些信息只会发送给员工。或意外的交叉加入导致收入在报告中翻倍（但仅限于特定客户，其中也有员工以某种方式联系）。
这实际上取决于您希望图层的外观以及哪些组件将访问哪些图层以及如何访问。
另外，我想你想重新选择MyiAM而不是InnoDB。