多少根柱子才算太多根柱子？

表的设计取决于它需要存储的实体。如果所有数据都属于一起，那么50列(甚至100列)可能是正确的选择。

只要表是 正常化了，除了数据库功能和需要优化之外，没有关于大小的经验法则。

我同意 Oded。我见过有500列的表格，它们中的所有列都在正确的位置。只要考虑一下你可能希望存储的关于日常用品的事实的数量，你很快就会知道为什么。

如果不方便选择所有这些列，或者当您只对其中的一小部分感兴趣时不方便指定要选择的列，那么您可能会发现定义一个视图是值得的。

这更像是一种性能上的打击: 大量带有大量 NULL 的列，或者 具有大量 JOIN 的列更少？

它完全取决于您存储的数据、创建的索引等等。如果不知道你存储的是什么，没有人能够保证一个比另一个更好。一般来说，规范化规则将“强制”您分离数据到不同的表和用户 FKey，如果您有大表，但我不同意它总是比一个大表表现更好。您可以在数十个查询中以6-7级联接结束，这些查询有时会导致错误，因为在较大的查询中比在简单的查询中有更多的机会创建错误。

如果你发布了一些要求，你正在做什么，也许我们可以帮助您设计数据库正确。

Odbc 的字符限制是8000... ... 所以这是一个物理限制，超过这个限制，事情就会变得非常令人沮丧。

我在一张有138列的桌子上工作。.它写得很糟糕，本来可以正常化的。虽然这个数据库似乎是由一些人创建的，他们想知道为什么在数据库设计中存在约定，并决定一次性测试所有约定。

在进入数据仓库和报表服务器时，使用非常宽的扁平表是相当常见的。它们只是快了很多，这意味着您不必为了性能而将整个数据库存储在 ram 中。

多少根柱子才算太多根柱子？

当您觉得不再有意义或添加另一列是正确的时候。

一般取决于应用程序。

根据我的经验，最好有较少的连接，因为这些往往发生得太频繁，特别是在大型数据库。只要您的数据库表被设计用于存储单个实体(学生、教师等) ，这应该没问题。以便稍后在代码中将其表示为对象。因此，如果将实体拆分为多个表，则必须使用多个联接才能在以后填充对象。另外，如果使用 ORM 生成数据访问层(如。Net)将为每个表生成单独的类(当然它们之间仍然存在关系) ，这将更难使用。

另一件事是，您可以指定在查询中返回哪些列，这将减少传递给应用程序的数据，但是如果您甚至需要另一个表中的单个列，则必须进行连接。而且在大多数情况下，由于有这么多列，那么在数据库中存储大量数据的可能性很高。因此，这种连接比 NULL 带来的危害更大。

我参与的每个项目都是不同的，所以你应该找到每个故事的平衡点。

它也很大程度上取决于表的用例。如果您想优化它以便阅读，那么将它们放在一个表中可能是一个好主意。

在 NO-SQL 世界(例如 Cassandra/hbase)中，对列的数量没有限制，实际上，拥有许多列被认为是一种很好的做法。这也取决于它的存储方式(没有间隙)。值得一查。

最好使用单个表，这样可以避免使用联接，而查询它取决于列是同一个实体还是不同的实体。

例如，假设您正在为工作流程进行数据库设计，其中一些字段将由初级工作人员编辑，而一些字段将由高级工作人员编辑。在这种情况下，最好将所有列放在一个表中。

拥有太多的列会导致大量的 null (罪恶)和表映射到的笨拙对象。这会损害 IDE 中的可读性并妨碍维护(增加开发成本)。如果您在某些情况下需要快速读取，可以使用非规范化表，例如仅用于报告或查询(搜索“ CQRS”模式)。是的，“ Person”有一百万个属性，但是你可以分解这些单一的表格(设计先于规范化)来匹配更小的实体(“地址”、“电话”、“爱好”) ，而不是为每个新用例添加新的列。拥有更小尺寸的对象(和表)带来了很多好处; 它们支持单元测试、 OOP 和 SOLID 实践。

另外，考虑到为了避免连接而对大量列进行聚合，我认为避免连接带来的性能收益通过索引维护而丧失，假设一个典型的读和写工作负载。为了提高读取性能而在字段上添加索引可能表明需要将这些字段移动到它们自己的表中。