一些数据库设计问题

Question

如果我有一个客户表，它将存储姓名，地址，电子邮件地址，电话号码，甚至可能存储有关客户的一些详细信息，如年龄，偏好等。

如果我将其分成较小的表，我会做一件好事吗？例如。 customer_contact包含联系人字段，并在原始Customer表中保留名称，出生日期等。

另外，对于查找表，它们只是从单独的表到一个大表的字段的组合，对吧？

另外，在我自己的系统中，我有一个代表产品的表，但它拥有的只是一个ID。该表的唯一字段是适用于许多产品的字段/属性（如果它是道路合法的），并且这是另一个表的字段，因此两个表之间存在约束（关系）。我假设一个查找表将这两个表合并在一起，对吗？

由于

Answer 1

在大多数情况下，分解通常会更好。当然，对于您列出的所有内容。

尝试将数据库设计看作是像Java这样的语言的OOP程序，其中复杂的对象是链接的。任何可以“链接”到您的实体的东西，特别是如果它可以链接到多个实体，可能是候选对象，因此是一个表格。

仅向主要客户表提供有关个人的核心信息，以便像您建议的那样识别他。

然后，所有其他元数据和辅助数据都可以绑定到它。例如，地址或电话号码或电子邮件是良好的候选对象值得拥有自己的表，特别是因为它们可能具有其他属性。然后，另一个表可以将地址与客户相关联（例如，如果您有一个整个家庭使用您的系统，那该怎么办）。

Answer 2

我认为数据库设计完全是关于平衡和判断。如果您看不到数据库变得非常大，那么将其标准化。如果你可以看到它变得非常大，那么IMHO会继续进行规范化，除非它必要的IE不使用映射表，因为无论有人说什么扁平的数据库运行得更快。

我会将地址存储在同一个表中，除非您觉得客户可能需要地址历史记录或单独的结算和送货地址。我永远不会打破联系方式和生日，因为它们不是真正的重点。

我使用像枚举这样的查找表，实际上大多数都成为枚举。

每个人都有自己关于数据库设计的想法......

Answer 3

你问的是正确的问题。将数据划分为可重用表的概念称为“规范化”。典型的客户关系管理器（CRM）系统有一些表，如Phone，Address，Person ......非常通用的表，可以重复用于各种目的。

例如，电话和地址不仅可以用于客户，也可以用于托运人，供应商，员工等。

一旦有了基本结构，就可以开始将客户链接到地址和电话了。请记住，每个客户都可以拥有ShippingAddress，BillingAddress，HomePhone，BillingPhone，MobilePhone等。您将创建CustomerAddress和CustomerPhone等表格，以便将客户与其各自的信息进行匹配。

Answer 4

取决于。

当每个客户可能有多个（未知）联系行数时，customer_contacts表将会被使用。另一方面，如果您确定每个客户有3个联系方式，您可以将其存储在与客户相同的表格中。

Answer 5

一般来说，如果你有大量的列（在这种情况下，重新设计可能是有序的），或者你对不同的数据有不同的安全要求，你只会（垂直）分区表。 SSN或工资数据与正常数据分开）。

当你说“查找表”时，我认为你实际上指的是“外键”。如果您有一个包含产品可用性的表，那么每一行都会有一个ProductID，指向所有其他产品信息。

Answer 6

通常，术语查找表被过度使用。如果再考虑标准编程，查找表相当于使用常量来引用幻数或常量对象。

因此，您为另一个通常为原子的实体使用唯一标识符，因为它不包含其他对象（例如，状态，地址，产品详细信息等）。在核心表中，您将拥有ID而不是实际的详细信息。

如果一个表引用一个中心实体，最好用关系而不是查找表来思考。

Answer 7

这是一种平衡行为，将所有列放在一个表中（非规范化）将导致更少的连接和更好的性能，但如果您以后必须更改内容将会很难维护。作为Uri mentioned，从OOP角度考虑您的数据库设计将帮助您确定哪些表应该是独立的。我强烈建议学习如何组合一个简单的Entity-Relationship Diagram。这将允许您绘制数据库设计并计算出所有内容将如何链接在一起，然后再过度实施。

Answer 8

有人比我更聪明曾经说过：“正常化直到它受到伤害，反正常直到它起作用”

将长表分成较小的语义块是明智的，这些语义块通过一对一的关系连接起来。然后，您可以通过视图调用它们。甚至许多ORM都是View友好的

但是，如果您的数据库获得许多匹配，这些额外的连接会对您造成伤害，就像在Web或Intranet场景中那样。

如果你想在高压力情况下将表分开，你可能想要使用在许多公共Web项目中使用的脏兮兮的作弊，并通过委托主表上的列来创建虚假视图来存储集合中的相关数据。