我一直在搜索stackoverflow大约一个小时，找不到任何相关的主题，所以如果这是一个重复的问题，我道歉。
我的询问是这样的。是否有一个数据库中有太多表的点？即使结构井井有条，想出来，也完美地促进了设计意图？我有一个快速接近40个表的数据库 - 大约10个主表，以及30多个辅助表（联结表，'枚举'表等）。
我只是一个糟糕的开发者 - 或者我应该尝试不同的东西？对我来说似乎有这么多，我真的很害怕它会如何影响项目的表现。在可能的情况下，我做了很多精简，尽可能将类似的东西分组等等。
数据库是在SQL Server 2008中构建的。
答案 0 :(得分：16)
您应该拥有所需数量的表;不多也不少。
我现在工作的其中一个系统有143个表 - 因为这正是解决问题所需的数量。
答案 1 :(得分：6)
LOL我们的主数据库有超过700个表，我没有使用数据库这么小，只有几年和几年有40个表。
只要您拥有所需的表格并且它们是正确的，您就可以了。
我看到由于表太少而导致的性能问题更多。
答案 2 :(得分：4)
您似乎正在尽最大努力规范化数据库。这是好事。很多时候出现问题是因为没有足够的表格。
答案 3 :(得分：2)
在不了解您的特定数据库的情况下，我会说不，您没有使用过多的表。现实问题和业务需求可以轻松指向至少与您的一样大的架构。我认为真正的问题是你的设计是否适合你的问题。
答案 4 :(得分：2)
有太多桌子这样的东西，但40就是那个数字。当人们开始考虑产品限制时，通常需要重新考虑他们的设计。
对于SQL Server，maximum capacity限制告诉您DB可以包含~2000000个表（如果它不包含任何其他内容，没有PK或任何类型的约束等）。毋庸置疑，如果你达到了这个限制，那么你做错了什么（例如你决定每个客户有一张桌子，不知怎的，你实际上已经获得了很多客户）
答案 5 :(得分：1)
这实际上取决于您尝试实施的应用程序的复杂性。会计系统等事情非常激烈，很容易达到40多个表格。
答案 6 :(得分：1)
2147483648表或更多表可能会对某些引擎造成问题。 9223372036854775808表或更多可能与某些其他表有问题。
（但是如果你的问题意味着是否存在某个数字n，使得带有＆gt; n表的数据库设计必然存在缺陷，那么就没有。）
答案 7 :(得分：0)
在我自己的工作中，我有大约60张桌子，看起来并不多 我认为主要的是数据存储是如何组织的（表之间的关系等）， 您需要多少查询来检索所需信息，以及您的数据在应用程序中表示为商务对象的简单程度。
答案 8 :(得分：0)
您可以将实际表中的所有数据放在一个表中。到第二个表可能只包含你的'表名'，应用程序仍然有效。
但这不是重点 表是某种组织结构。它们是某种抽屉。
我有太多的抽屉吗？
这取决于......