哪个更好 - 许多小桌子或一张大桌子？答案

【问题标题】：What's better - many small tables or one big table?哪个更好 - 许多小桌子或一张大桌子？
【发布时间】：2011-05-04 15:22:21
【问题描述】：

我有一个用于存储个人资料的数据库。这些人有大约 50 个可能的领域。

有些是常见的东西，例如名字、姓氏、电子邮件、电话号码。

其他是诸如爱好、技能、兴趣之类的东西

有些是身高、体重、肤色。

系统在不同时间使用这些组中的每一个。就能够通过数据库进行协商而言，我希望有 7 个表，每个表大约 8 个字段。最佳做法是什么？

编辑： 数据将在搜索引擎中用于查找配置文件匹配项。这会影响我的工作吗？

【问题讨论】：

标签： mysql database database-design database-schema

【解决方案1】：

很难说，取决于应用程序需要什么。我想说看看Database Normalization，因为它将向您展示如何规范化数据库，并且它应该阐明您想要将哪些内容分离到他们自己的表等中。

【讨论】：

该数据将用于搜索引擎，用于查找配置文件匹配项。这会影响我的工作吗？
如果您要从 RDBMS 中检索，请进行规范化。它会以积极的方式影响你正在做的事情

【解决方案2】：

这个问题没有正确答案，因为它在很大程度上取决于您将在何时以及如何使用数据、数据的更改频率以及数据库上的使用量。

我个人会做的是将您的数据组织成逻辑实体并基于这些实体创建表。这至少是我要开始的地方。

【讨论】：

我不会像数据质量那样担心使用量。

【解决方案3】：

许多小表，即规范化在这里是最好的。它提供了灵活性、减少了冗余和更好的数据库组织。

【讨论】：

【解决方案4】：

根据您的描述，我当然会将其分解为多个表格。不过，我不会拆分任意数量的列，而是尝试考虑组成实体或匹配您将用于访问数据的访问模式的列的逻辑集合

【讨论】：

是的，该图只是一个示例，数据将按语义分组。

【解决方案5】：

没有 100% 正确的数据库组织，只有一个足以满足您的目的。如果您没有预见到将来会超越单个优秀数据库服务器的功能，那么规范化数据并使用大量约束，例如外键、级联删除等，这将使您的数据库成为一种愉快的工作。另一方面，如果您查看许多具有数十亿请求的应用程序的数据库，您会发现它们以性能和可扩展性的名义放弃了很多这些细节。

【讨论】：

你是我听到的第一个说“级联删除很愉快”的人

【解决方案6】：

IMO，担心存储的数据质量比您需要的表数量更重要。

例如，您需要跟踪更改吗？如果约翰在 2007 年 1 月是 5 英尺 2 英寸，在 2010 年 10 月是 5 英尺 11 英寸，你想知道吗？如果是这样，您需要将人与身高分开到两张表中。

爱好怎么样？他们只能有 3 个爱好吗？他们能有更多/更少吗？这是您将来要查询的内容吗？如果是这样，您需要一个单独的表。

您应该阅读数据库设计和规范化（本网站本身有几个优秀的主题）。

https://stackoverflow.com/questions/tagged/normalization

【讨论】：

【解决方案7】：

除非每个人都有相同数量的爱好（即每个人都有列出 2 个爱好），否则应该标准化。

与人员始终为 1 对 1 的字段应位于同一个表中。以年龄为例。没有人会有两个不同的年龄。

【讨论】：

【解决方案8】：

我会推荐几张桌子。过度规范化很难管理，您最终会编写复杂的查询，从而导致性能下降。

仅在绝对需要时进行规范化，并以逻辑方式思考。由于您在上面提供的信息有限，我会选择三张桌子：

表 1： 个人详细信息 表 2： 活动 表 3： 其他

还有其他技术可以提高性能，例如集群等，您可以根据需要使用这些技术。

【讨论】：

【解决方案9】：

我在标准化阵营。

这里有一些提示可以帮助您入门：

从一个进程开始，为每个进程分配一些任意的唯一标识符 “人”。将此称为PersonId 或类似名称。这个标识符被称为一个代理键。代理键的唯一目的是保证它与现实世界中的真人之间的一对一关系。使用将某些其他属性的值与“人”相关联时的代理键你的数据库。

当您开发数据库布局时，您可能会发现代理键是必要的（或至少有用）也适用于其他一些属性。

查看您要管理的每个属性。问以下问题：任何给定的人是否对该属性只有一个值？

例如，每个人有一个“出生日期”。但是他们怎么可能有“爱好”呢？可能是零到很多。单值属性（例如出生日期、身高、体重等）是进入以PersonId 为键的公用表。每个表中的属性数不应该在这一点上值得关注。

Hobby 等多值属性需要稍有不同治疗。您可能希望为每个多值属性创建单独的表。使用爱好作为例如，您可以创建下表PersonHobby(PersonId, Hobby)。此表中的一行可能看起来类似：(123, "Stamp Collecting")。这样你可以录制尽可能多的爱好按每个人的需要，每排一个。对“兴趣”、“技能”等做同样的事情。

如果有相当多的多值属性 PersonId + Hobby 的组合没有其他决定（即你没有任何有趣的东西记录这个人做这个“爱好”或“兴趣”或“技能”）你可以把他们归为一类具有类似PersonAV(PersonId, AttributeName, Value) 的结构的属性值表。这里可能有一排看起来像：(123, "Hobby", "Stamp Collecting")。

如果你走这条路，替换也是一个好主意 PersonAV 表中的 AttributeName 作为代理键并创建另一个表来关联这个其描述的关键。类似：Attribute(AttributeId, AttributeName)。此表中的一行看起来像 (1, "Hobby") 和对应的 PersonAV 行可以是 (123, 1, "Stamp Collecting")。这是通常这样做是为了如果您需要知道哪些AttributeNames 在您的数据库/应用程序中是有效的你有一个地方可以查到它们。考虑如何验证“兴趣”是否是有效值 AttributeName 与否 - 如果您还没有记录某人拥有 AttributeName，那么有在您的数据库中没有 AttributeName 的记录 - 您如何知道它是否应该存在？在Attribute 表中查找！

某些属性可能有多个关系，这也会影响表的规范化方式。我没有在您的示例中查看这些依赖项中的任何一个，因此请考虑以下内容：假设我们有一个仓库充满零件，PartId 确定其WeightClass、StockCount 和ShipCost。这表明一个表类似：Part(PartId, WeightClass, StockCount, ShipCost)。但是，如果之间存在关系非关键属性，那么它们应该被分解出来。例如直接假设WeightClass 确定ShipCost。这意味着仅WeightClass 就足以确定ShipCost 和ShipCost 应该被排除在Part 表之外。

规范化是一门相当微妙的艺术。您需要确定功能依赖关系存在于数据模型中的所有属性之间，以便正确执行。只是提出功能依赖关系需要相当多的思考和考虑 - 但它对于进行正确的数据库设计至关重要。

我鼓励你花时间在构建数据库之前多研究规范化。在这里度过了几天将来会为自己付出更多的代价。尝试做一些谷歌/维基百科搜索 “功能依赖”、“规范化”和“数据库设计”。阅读、研究、学习，然后正确构建它。

我就规范化数据库设计提出的建议只是对您可能需要采取的方向的提示。如果对您试图在应用程序中管理的所有数据没有深入了解，那么这里给出的任何建议都应该“持保留态度”。

【讨论】：