一位前同事坚持认为，拥有更多表且每个列较少的数据库要比拥有更少表且每个列更多的数据库更好。例如，我们将没有名称表，地址表，城市表等，而不是具有名称，地址，城市，州，邮政编码等列的客户表。

他认为这种设计更加有效和灵活。也许它更灵活，但是我没有资格评论它的效率。即使效率更高，我认为增加的复杂性可能无法抵消这些收益。

因此，具有更少列的更多表与具有更多列的更少表相比，有什么显着的好处吗？

解决方案

回答

这取决于数据库风格。例如，MS SQL Server倾向于更窄的表。这也是更"规范化"的方法。其他引擎可能更喜欢它。大型机通常属于这一类。

回答

我认为标准化是第一步，因此将城市，县，州，国家作为单独的列会更好... SQL语言的强大功能以及今天的DBMS-es允许我们稍后在需要查看数据时进行分组它以其他一些非标准化的观点来看。

在开发系统时，如果我们认为这是一项改进，则可以考虑"标准化"某些部分。

回答

我认为在这种情况下要保持平衡。如果在表中放置一列是有意义的，则将其放在表中，如果没有，则不要。同事方法一定会帮助标准化数据库，但是如果我们必须将50个表连接在一起以获取所需的信息，那可能就没有太大用处。

我想我的答案是，用你最好的判断。

回答

听起来不像是关于表/列的问题，而是关于规范化的问题。在某些情况下，高度规范化(在这种情况下为"更多表")是好的且干净的，但是通常需要大量的JOIN才能获得相关的结果。有了足够大的数据集，这可能会降低性能。

Jeff就StackOverflow的设计写了一些有关它的内容。另请参阅Jeff链接到Dare Obasanjo的文章。

回答

具有较少列的表有很多优点，但是我们还需要查看上面的情况并回答以下问题：

允许客户使用多个地址吗？如果不是，则不需要单独的地址表。如果是这样，那么一个单独的表将很有帮助，因为我们可以轻松地根据需要添加更多地址，而在该表中添加更多列将变得更加困难。

回答

这有很多方面，但是从应用程序效率的角度来看，微粒表有时会更高效。如果每次db进行操作时，如果有几个表具有一堆列，则有机会进行锁定，则在锁定期间将使更多数据不可用。如果锁升级到页面和表(最好不是表:))，我们将看到它如何降低系统速度。

回答

使用尽可能少的列进行查询有很大的好处。但是表本身可以有很多。杰夫对此也说了些话。

基本上，在进行查询的查询性能时，请确保所要查询的内容不超过我们要查询的列数。

回答

如果这些一对一关系中的任何一种将来可能变成一对多或者多对多，则多表数据库要灵活得多。例如，如果我们需要为某些客户存储多个地址，那么拥有一个客户表和一个地址表会容易得多。我真的看不到这种情况，我们可能需要复制地址的某些部分，而不需要复制其他部分，因此单独的地址，城市，州和邮政编码表可能有点过头。

回答

我认为我们必须先确定要存储的数据类型，然后再做出决定。有一个地址表是很棒的，但前提是多个人共享同一地址的可能性很高。如果每个人都有不同的地址，那么将该数据保存在不同的表中只会引入不必要的联接。

除非拥有城市本身就是我们在应用程序中关心的实体，否则我看不到拥有城市表的好处。或者，如果我们想限制用户可以使用的城市数量。

最重要的是，这样的决定必须在开始提高效率之前考虑应用程序本身。海事组织。

回答

我会主张使用更多的表，但是只能使用到一定程度。以示例为例，如果将用户信息分成两个表(例如：USERS和ADDRESS)，则可以灵活地为每个用户提供多个地址。一个明显的应用是用户拥有单独的帐单地址和送货地址。

支持使用单独的CITY表的论据是，我们只需要存储每个城市的名称一次，然后在需要时引用它。这确实减少了重复，但是在此示例中，我认为这是多余的。这样做可能更节省空间，但是当我们从数据库中选择数据时，我们将在联接中付出代价。

回答

像其他一切一样：这取决于。

关于列数与表数没有硬性规定。

如果客户需要有多个地址，则可以使用一个单独的表。如果确实有充分的理由将City列标准化为其自己的表，那么也可以这样做，但是我以前从未见过，因为它是自由格式的字段(通常)。

表格繁重，规范化的设计在空间方面非常有效，看起来"教科书不错"，但会变得极其复杂。看起来很不错，直到我们必须进行12次联接才能获得客户的姓名和地址。这些设计在最重要的性能方面并不能自动实现出色：查询。

如果可能，请避免复杂性。例如，如果一个客户只能有两个地址(不能任意多个)，那么将它们全部保留在一个表中就有意义(CustomerID，Name，ShipToAddress，BillingAddress，ShipToCity，BillingCity等)。

这是杰夫(Jeff)关于这个话题的帖子。

回答

完全标准化的设计(即"更多表")更灵活，更易于维护，并且避免了数据重复，这意味着数据完整性将更容易实施。

这些是进行规范化的有力理由。我会选择先进行规范化，然后在看到性能成为问题后才对特定表进行规范化。

我的经验是，在现实世界中，即使有非常大的数据集，也不会达到需要进行非规范化的程度。

回答

每个表应仅包含与由主键唯一标识的实体有关的列。如果数据库中的所有列都是同一实体的所有属性，那么我们只需要一个包含所有列的表。

但是，如果任何列可能为空，则需要使用主表的外键将每个可空列放入其自己的表中，以对其进行规范化。这是一种常见的情况，因此为了更简洁的设计，我们很可能向现有表中添加的表要比列多。而且，通过将这些可选属性添加到自己的表中，它们将不再需要允许空值，从而避免了一系列与NULL相关的问题。

回答

设计数据库时，我遵循一些非常简单的经验法则，我认为这些规则可用于帮助做出这样的决策...。

• 支持规范化。非规范化是优化的一种形式，它具有所有必要的折衷，因此应以YAGNI的态度进行处理。
• 确保引用数据库的客户端代码与架构进行了充分的分离，以至于对其进行重做不需要对客户端进行重大的重新设计。
• 当它为性能或者查询复杂性带来明显好处时，不要害怕进行非规范化。
• 在数据量和使用场景允许的情况下，使用视图或者下游表来实现规范化而不是规范化架构的核心。

这些规则的通常结果是，初始设计将优先使用表而不是列，并着重于消除冗余。随着项目的进展和非规范化点的确定，总体结构将朝着平衡的方向发展，以有限的冗余和色谱柱扩散为代价，以换取其他有价值的利益。

回答

唔。

我认为这很麻烦，取决于特定设计模型。一定要在其自己的表中排除具有多个字段的实体，或者其组成可能会随应用程序需求的变化而改变的实体(例如，无论如何我都会考虑地址，因为它具有太多字段， d如果我们认为有任何可能需要处理外国地址(可以采用不同的形式(与电话号码相同))，则尤其要这样做。

就是说，当我们开始使用它时，请密切注意性能。如果我们拆分出一个实体，需要进行大型，昂贵的连接，那么将表旋转回原始表可能是一个更好的设计决策。