什么更好 - 许多小桌子或一张大桌子？

Question

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

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

其他人喜欢爱好，技能，兴趣

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

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

编辑：数据将用于搜索引擎，以查找个人资料匹配项。这会影响我在做什么吗？

Answer 1

很难说，并且基于应用程序的要求。我会说要调查Database Normalization，因为它会告诉你如何规范化数据库，并且它应该阐明你想要分成他们自己的表等的东西。

Answer 2

我和Normalize训练营在一起。

以下是一些帮助您入门的提示：

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

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

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

例如，每个人 只有一个“出生日期”。但他们怎么可能有“爱好”？可能是零到多。 单值属性（例如，出生日期，身高，体重等）是进入a的候选者 以PersonId为密钥的公用表。每个表中的属性数量不应该 在这一点上要引起关注。

诸如Hobby之类的多值属性需要略有不同 治疗。您可能希望为每个多值属性创建单独的表。使用兴趣爱好 例如，您可以创建下表PersonHobby(PersonId, Hobby)。该表中的一行可能看起来像 类似于：(123, "Stamp Collecting")。这样你就可以记录多少 每个人需要的爱好，每排一个。为“兴趣”，“技能”等做同样的事。

如果有很多多值属性 PersonId + Hobby的组合决定了什么（即你没有任何有趣的东西） 记录这个人做这个“爱好”或“兴趣”或“技能”），你可以把它们混为一谈 属性值表，其结构类似于PersonAV(PersonId, AttributeName, Value)。这可能是一行 看起来像是：(123, "Hobby", "Stamp Collecting")。

如果你走这条路，替换也是个好主意 代理键的AttributeName表中的PersonAV，并创建另一个表来关联它 其描述的关键。 类似于：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表中计算出来。

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

我鼓励你抽出时间 在构建数据库之前，再学习规范化。在这里度过了几天 将不仅仅是在路上付出代价。尝试进行一些Google / Wikipedia搜索 “功能依赖”，“规范化”和“数据库设计”。阅读，学习，学习，然后正确构建。

我对数据库设计规范化的建议只是提示您可能需要采取的方向。如果您没有充分掌握您在应用程序中尝试管理的所有数据，那么此处给出的任何建议都应该带有“一丝不苟”。

Answer 3

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

仅在绝对需要时进行标准化并以逻辑方式思考。由于您在上面提供的信息有限，我会选择三个表格：

表1： PersonalDetails 表2：活动 表3：其他

还有其他技术可以加快集群等性能，您可以根据需要使用它们。

Answer 4

从你所描述的内容来看，我肯定会把它分成多个表格。我不会拆分任意数量的列，而是尝试考虑构成实体的列的逻辑集合，或者匹配您将用于访问数据的访问模式

Answer 5

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

例如，您是否需要跟踪更改？如果约翰在2007年1月是5英尺2英寸，在2010年10月是5英尺11英寸，你想知道吗？如果是这样，你需要将人从高处分成两个表。

爱好如何 - 他们只允许有3个爱好吗？他们可以有更多/更少？这是您将来要查询的内容吗？如果是这样，你需要一个单独的表。

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

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

Answer 6

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

与人总是1对1的字段应位于同一个表中。年龄例如。没有人会有两个不同的年龄。

Answer 7

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

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

Answer 8

没有数据库组织100％正确，只有一个对您的目的足够好。如果您预计未来不会超越单个良好数据库服务器的功能，那么将数据规范化并使用大量约束，例如外键，级联删除等，这将使您的数据库变得愉快。另一方面，如果你看一下有数十亿个请求的很多应用程序的数据库，你会发现它们以性能和可伸缩性的名义放弃了很多这些细节。

Answer 9

许多小表，即归一化最好。它提供灵活性，减少冗余和更好的数据库组织。