我有一个数据库，它将存储关于个人的配置文件。这些人有大约50个可能的领域。什么更好 - 许多小桌子或一张大桌子？
一些常见的事情，如名字，姓氏，电子邮件，电话号码。
其他事情一样的爱好，技能，兴趣
有些是身高，体重，皮肤的颜色。
这些组中的每个组都由系统在不同的时间使用。就能够通过数据库进行谈判而言，我倾向于每个约8个字段有7个表格。最佳做法是什么？
编辑：该数据将用于搜索引擎，用于查找配置文件匹配。这会影响我在做什么吗？
这很难说，而且是基于应用程序的要求。我会说，看看Database Normalization，因为它会告诉你如何规范化数据库，它应该阐明你想分离出他们自己的表格等。
这个问题没有正确的答案因为它很大程度上取决于何时以及如何使用数据，数据的更改频率以及数据库的使用量。
我个人的做法是将数据组织到逻辑实体中，并根据这些实体创建表。这至少是我要开始的地方。
我不会担心使用量与数据质量一样多。 – 2010-11-03 17:43:44
许多小表即标准化在这里最好。它提供了灵活性，减少冗余和更好的数据库组织。
从你所描述的我肯定会把它分成多个表。我不会在任意数量的列上分割，而是尝试考虑组成实体的列的逻辑集合，或者匹配您要用来访问数据的访问模式
是的，这个数字仅仅是一个例子，数据将被语义分组。 – Ash 2010-11-03 17:48:45
有不是100％正确的数据库组织，只有一个足够满足您的需求。如果您未来预计未超越单个优质数据库服务器的功能，那么将数据规范化并使用大量限制，例如外键，级联删除等，这将使您的数据库处理起来更加愉快。另一方面，如果您查看许多具有数十亿请求的应用程序的数据库，则会发现它们以性能和可伸缩性为名放弃了许多这些细节。
您是我第一个听到的人说“级联删除是与我一起工作的快乐” – 2010-11-03 17:42:27
IMO，更重要的是担心所存储数据的质量，而不是您需要的表的数量。
例如，您是否需要跟踪更改？如果约翰在2007年1月为5英尺2英寸，2010年10月为5英尺11英寸，你想知道吗？如果是这样，你需要把这个人从高度分成两个表格。
爱好如何 - 他们只允许有3种爱好吗？他们可以有更多/更少？这是你将来想要查询的东西吗？如果是这样，你需要一个单独的表。
您应该阅读数据库设计和规范化（本网站上有几个优秀的线程）。
除非每个人都拥有相同数量的爱好（IE每个人都有2周所列的爱好），应该归。
与该人总是1对1的字段应位于同一个表中。年龄例如。没有人会有两个不同的年龄。
我会推荐几张桌子。过度规范化很难管理，最终你会写出复杂的查询，最终导致性能下降。
只有在绝对需要时才进行标准化，并按逻辑方式进行思考。随着你在上面提供的信息有限，我会去三个表：
表1： PersonalDetails 表2：活动 表3：其他
还有其他一些技术来加快性能如群集等，您可以根据您的需要使用。
我与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表中分解出来。
标准化是一个相当微妙的艺术。您需要确定数据模型中所有属性之间存在的功能依赖关系 ，以便正确执行。只需要 提出的功能依赖需要一定的思想和考虑 - 但它是 是进行正确的数据库设计的关键。
我建议您在构建数据库之前多花点时间到 研究规范化。在这里花费了几天的时间，其余的花费将超过本钱。尝试做一些谷歌/维基百科搜索 “功能依赖”，“规范化”和“数据库设计”。阅读，学习，学习，然后建立它的权利。
我对数据库设计规范化提出的建议只是提示您可能需要采取的方向。如果您没有很好地掌握您在应用程序中试图管理的所有数据，那么在此提供的任何建议都应该以“一粒盐”来进行。
用于标准化的+1 – 2010-11-03 17:41:40
该数据将被用于搜索引擎中，用于查找配置文件匹配。这会影响我在做什么吗？ – Ash 2010-11-03 17:50:19
如果您将从RDBMS中检索，那么请正常化。它会以积极的方式影响您的工作 – Randy 2010-11-04 20:37:57