还有什么更好的?多张小桌子还是一张大桌子?

很难说,这是基于应用程序的需求。我会说去调查 Database Normalization 因为它将向您展示如何规范化数据库,并且它将阐明您希望将哪些内容分离到它们自己的表中等等。

我参加了正规化训练营。

以下是一些让您入门的提示:

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

在开发数据库布局时,您可能会发现必要的代理键(或者至少有用) 还有一些其他属性。

查看要管理的每个属性。提出以下问题: 任何给定的人对此属性只有一个值吗?

例如,每个人 只有一个“出生日期”。但是他们怎么可能有“爱好”?可能是零对多。 单值属性(如出生日期、身高、体重等)是进入 公用表 个人ID 作为钥匙。每个表中的属性数不应 在这一点上要引起关注。

嗜好等多重价值属性需要稍有不同 治疗。您可能需要为每个多值属性创建单独的表。把业余爱好作为 示例您可以创建下表 PersonHobby(PersonId, Hobby) . 此表中的一行可能会 比如: (123, "Stamp Collecting") . 这样你可以录制尽可能多的 每个人的业余爱好,每行一个。对“兴趣”、“技能”等也要这样做。

如果有相当多的多值属性 其中的组合 PersonId + Hobby 别想别的了(你没有什么有趣的事 记录下这个人的“爱好”或“兴趣”或“技能”),你可以把他们 一种属性值表,其结构类似于 PersonAV(PersonId, AttributeName, Value) . 这里可能会有一排 看起来像: (123, "Hobby", "Stamp Collecting") .

如果你走这条路,最好换一个 这个 AttributeName 在 PersonAV 代理项的表,并创建另一个与此相关的表 其描述的键。 比如: Attribute(AttributeId, AttributeName) . 这张表中的一行看起来像 (1, "Hobby") 和相应的 个人 行可以是 (123, 1, "Stamp Collecting") . 这是 通常这样做,如果你需要知道 AttributeNames 在数据库/应用程序中有效 你有地方找他们。考虑如何验证“interest”是否为 属性名 或者没有-如果你没有记录下某人有这种情况 属性名 那就是 没有这方面的记录 属性名 在您的数据库上-您如何知道它是否应该存在?好吧,查一下 Attribute 桌子!

有些属性可能有多个关系,这也会影响表的规范化方式。我没有 在您的示例中看到这些依赖项中的任何一个,请考虑以下内容:假设我们有一个仓库 全是零件, PartId 确定其 WeightClass , StockCount 和 ShipCost . 这表明有一张桌子 比如: Part(PartId, WeightClass, StockCount, ShipCost) . 但是,如果 那么,非关键属性应该被分解出来。例如,假设 重量等级 直接地 确定 运费 . 这意味着 重量等级 独自一人就足以决定 运费 和 运费 应该从 Part 桌子。

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

我鼓励你花时间 在构建数据库之前,请进一步研究规范化。在这里呆了几天 将不仅仅是为自己付出代价。尝试在谷歌/维基百科上搜索 “功能依赖”、“规范化”和“数据库设计”。阅读、学习、学习,然后正确地构建它。

我在规范化数据库设计方面提出的建议只是关于您可能需要采取的方向的提示。在没有对您试图在应用程序中管理的所有数据有很强的了解的情况下,这里给出的任何建议都应该用“盐粒”来表示。

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

只有在绝对需要的时候才能正常化,并用逻辑的方式思考。由于您在上面提供的信息有限,我将选择三个表:

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

还有其他一些技术可以加速性能,如集群等,您可以根据需要使用这些技术。

根据你所描述的,我肯定会把它分成多个表。不过,我不会对任意数量的列进行拆分,而是尝试考虑列的逻辑集合,这些列要么组成一个实体,要么与要用来访问数据的访问模式相匹配。

在我看来,更重要的是要担心存储数据的质量,而不是您需要的表的数量。

例如,是否需要跟踪更改?如果约翰在2007年1月是5尺2寸,在2010年10月是5尺11寸,你想知道吗?如果是这样,你需要把这个人从高处分为两张桌子。

业余爱好怎么样?他们只允许有3个业余爱好吗?他们能多多少少吗?这是您将来要查询的内容吗?如果是这样,您需要一张单独的桌子。

您应该了解数据库设计和规范化(这个站点本身有几个优秀的线程)。

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

除非每个人都有相同数量的爱好(即每个人都有2个列出的爱好),否则应该将其规范化。

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

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

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

没有一个数据库组织是100%正确的,只有一个对您的目的足够好。如果您没有预见到将来会超过一个好的数据库服务器的能力,那么规范化数据并使用大量的约束,例如外键、级联删除等等,这将使您的数据库工作起来非常愉快。另一方面,如果您查看许多具有数十亿请求的应用程序的数据库,您会发现它们以性能和可伸缩性的名义放弃了许多这些细节。

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