数据库设计，同一张表多类型客户答案

【问题标题】：Database design, multiple types of customers in the same table数据库设计，同一张表多类型客户
【发布时间】：2011-12-18 19:26:47
【问题描述】：

业务场景：

技术上：在 Customer 表中没有“自然地”进行 PK。无论如何，即使没有自然的PK，我也总是使用人工PK。我担心这最终会导致搜索、完整性等方面的问题。不过，我无法确切确定会出现什么问题。

我认为开发人员不会期望电子邮件列允许 null，他们会创建忽略这种情况的程序。

请记住，整个系统，以及大部分数据库都会依赖于客户数据，如果客户表出现问题，很可能会被其他表继承。

两种类型的客户的存在在我的大脑中引发了异常，但我无法弄清楚异常的信息。你怎么看？现在是不是更好地找到出路？或者你认为，没关系，一直这样直到出现问题，因为它不太可能导致问题，记住问题不是必要的错误，它可能是可维护性或开发复杂性？

谢谢

【问题讨论】：

【解决方案1】：

将这些数据放在同一个表中是否有特定的原因？ CRM“客户”和电子商务客户是否共享此数据库中的许多其他表？

老实说，我不会将电子商务客户放在这个数据库中。尽管您可以创建视图来轻松分离电子商务和 CRM 数据，但这对我来说似乎完全没有必要。此外，您还没有描述电子商务和 CRM 数据需要存在同一个数据库中的任何特定原因。也许您没有在问题中包含一个原因，但是如果您问我，这已经很臭了。

根据您在此处包含的信息，我认为您为电子商务客户创建单独的数据库和表并不会丢失任何重大信息。将不相关的数据分开。

编辑：

为了更清楚地说明这一点：如果您的电子商务客户不与 CRM 客户共享大量数据，请创建新的客户表。如果他们确实共享大量数据，那么一个空列可能不是世界末日。

【讨论】：

系统已经有了，我没有参与这个设计。所以你同意我的观点，总有一天会惹出麻烦，我必须做点什么，否则你就这样一直等到真的出了问题。
新的电子商务客户会与CRM客户共享大量数据吗？您没有在原始问题中包含有关此内容的详细信息。 如果答案是肯定的，那么我认为将电子商务客户放在同一张表中是可以的——空电子邮件列并不是世界末日。 如果答案是否定的，那么您需要考虑创建一个单独的电子商务数据库和客户表。
电子商务应用程序需要电子商务客户电子邮件，但是 CRM 应用程序不需要 CRM 客户电子邮件，是的，这两个应用程序几乎共享所有内容。所以我把两者放在同一张桌子上，我的设计不会真正强制电子商务应用程序的完整性......同意吗？
确实如此，但还有很多其他方法可以强制执行不包括表级设计的数据完整性。您可以编写一个检查客户类型的约束，然后如果客户是电子商务客户，则需要电子邮件地址。
现在你说话.....谢谢，但是很抱歉我不清楚，我试图通过大家的回答来确定我是否高估了设计问题。所以我会问你一个直接的问题：你认为它不需要所有的思考吗？