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

Question

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

Ash*_*Ash 38 mysql database database-design database-schema

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

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

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

有些是身高,体重,肤色.

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

编辑:数据将用于搜索引擎,用于查找配置文件匹配.这会影响我在做什么吗？

Answer 1

Jim*_* W. 34

很难说,并且基于应用程序的要求.我会说要研究数据库规范化,因为它会告诉你如何规范化数据库,并且它应该阐明你想要分离到他们自己的表等.

Answer 2

Nea*_*alB 25

我和Normalize训练营在一起.

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

从一个过程开始,为每个"人"分配一些任意唯一标识符.称之为PersonId或类似的东西.该标识符称为代理键.代理关键的唯一目的是保证它与现实世界中真人之间的1对1关系.将某些其他属性的值与数据库中的"人员"相关联时,请使用代理键.

在开发数据库布局时,您可能会发现某些其他属性所需的代理键(或至少是有用的).

查看要管理的每个属性.提出以下问题:任何给定的人只有一个该属性的值吗？

例如,每个人只有一个"出生日期".但他们怎么可能有"爱好"？可能是零到多.单值属性(例如,出生日期,身高,体重等)是PersonId作为关键进入公共表的候选者.此时,每个表中的属性数量不应该受到关注.

诸如Hobby之类的多值属性需要稍微不同的处理.您可能希望为每个多值属性创建单独的表.以Hobbies为例,您可以创建下表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表中考虑.