是否有太多桌子这样的事情？答案

【问题标题】：Is there such a thing as too many tables?是否有太多桌子这样的事情？
【发布时间】：2011-01-29 17:37:49
【问题描述】：

我已经搜索了大约一个小时的 stackoverflow，但找不到任何相关的主题，所以如果这是一个重复的问题，我深表歉意。

我的询问是这样的。数据库中是否存在太多表？即使结构井井有条，经过深思熟虑，并且完美地促进了设计意图？我有一个快速接近 40 个表的数据库 - 大约 10 个主表和 30 多个辅助表（联结表、“枚举”表等）。

我只是一个糟糕的开发人员 - 还是我应该尝试不同的东西？对我来说似乎太多了，我真的很害怕它会如何影响项目的性能。我在可能的情况下做了很多浓缩，在可能的情况下对类似的事情进行了分组，等等。

数据库是在 SQL Server 2008 中构建的。

【问题讨论】：

40 还小
那么你认为什么是大的？这对我来说是巨大的——在学校里，如果我们为复杂的应用程序超过 7 或 8 张桌子，我们就会失败。 ——虽然回想起来，dba老师并不是很聪明。
@Stacey 学校和现实生活是有区别的。即使是相对简单的业务应用程序也可以有 40 多个表。
顺便说一句——您的 DB 讲师很可能坚持使用少量表格以使评分易于管理并鼓励您避免不必要的复杂解决方案。但是，作业通常一次只关注一个问题（或少数问题相互作用的方式），而现实世界需要同时将多个（或多个）概念放在一起。
我的团队最近继承了一个不断增长的数据库，其中包含超过 440,000 个表！可以说我们正在重构为多租户解决方案。

【解决方案1】：

您应该拥有所需数量的表格；不多不少。

这些天我正在使用的一个系统有 143 个表 - 因为这正是解决问题所需的数量。

【讨论】：

【解决方案2】：

哈哈，我们的主数据库有 700 多个表，我没有使用过这么小的数据库，它多年来只有 40 个表。

只要你有你需要的表并且它们被正确标准化，你就可以了。

我发现由于表太少而不是太多导致的性能问题。

【讨论】：

【解决方案3】：

您似乎正在尽最大努力规范您的数据库。这是好事。很多时候出现问题是因为没有足够的表。

【讨论】：

【解决方案4】：

桌子太多了，但 40 与这个数字完全不同。当人们开始遇到产品限制时，通常就是他们需要重新考虑他们的设计的时候。

对于 SQL 服务器，maximum capacity 限制告诉您一个 DB 可以包含 ~2000000000 个表（如果它不包含其他内容，没有 PK 或任何类型的约束等）。不用说，如果你达到了这个限制，那么你就做错了（例如，你决定每个顾客有 1 张桌子，但不知何故你实际上已经赢得了很多顾客）

【讨论】：

【解决方案5】：

在不了解您的特定数据库的情况下，我会说不，您没有使用太多表。现实世界的问题和业务需求可以很容易地指向至少与您的一样大的模式。我认为真正要问的问题是您的设计是否适合您的问题。

【讨论】：

好吧，我的大多数表都是连接表，以试图从其他“类型”进行伪继承。例如，我们有一个“产品”表和一个“项目”表——但它们非常相似，所以我创建了另一个名为“详细信息”的表，将产品和项目映射到单独的连接表，然后将唯一的产品和项目表中的项目。这种情况是我大部分额外表格的来源。
如果您认为 Products 和 Items 之间可能存在一些不必要的冗余，我建议您从这些具体问题开始另一个问题。
好的，我已经发布了另一个关于它的问题。再次感谢。 stackoverflow.com/questions/2485253/…

【解决方案6】：

这实际上取决于您尝试实现的应用程序的复杂性。诸如会计系统之类的东西非常密集，很容易达到 40 多张桌子。

【讨论】：

【解决方案7】：

2147483648 表或更多表可能对某些引擎有问题。 9223372036854775808 表或更多表可能与某些其他表有问题。

（但是如果您的问题是指是否存在某个数字 n 使得具有 >n 个表的数据库设计必然存在缺陷，那么没有。）

【讨论】：

【解决方案8】：

在我自己的工作中，我有大约 60 张桌子，而且似乎不多）我认为主要是数据存储的组织方式（表之间的关系等），您需要多少查询才能检索所需信息，以及您的数据在应用程序中可以表示为业务对象的简单程度。

【讨论】：

【解决方案9】：

您可以将实际表格中的所有数据放在一个表格中。第二个表可能只包含您的“表名”，并且该应用程序仍然可以工作。

但这不是重点。
表格是某种组织结构。它们是某种抽屉。

我的抽屉太多了吗？

这取决于……

【讨论】：