使表格真的很大的列数是多少？

Question

我的数据库中有两个表，一个用于登录，另一个用于用户详细信息（数据库不仅仅是两个表）。登录表有12列（Id，电子邮件，密码，PhoneNumber ...），用户详细信息有23列（Job，City，Gender，ContactInfo ..）。这两个表有一对一的关系。

我正在考虑创建一个包含两个表的列的表，但我不确定，因为这可能会使表的大小变大。

所以这引出了我的问题，那些使表变大的列数是多少？是否有一个特定或近似的数字使表的大小变大，并使我们停止向表添加列并创建另一个？还是程序员决定这个号码？

Answer 1

使我们停止向SQL中的现有表添加列的约束是，如果我们超过数据库引擎可以为单个表支持的最大列数。可以看出here，对于SQLServer，对于非宽表是1024列，对于宽表是30,000列。

35列不是表格的特别多的列。

Answer 2

列数实际上不是问题。您似乎担心的任何性能问题都可归因于表中DATA的大小。即，如果表有数十亿行，或者其中一列在每个单独的行上包含200 MB的XML数据，等等。

通常情况下，由多列引起的唯一问题是它如何与索引相关，因为尝试创建涵盖每个查询的每个变体的100个不同索引会很麻烦。

点这里是，我们不能给你任何建议，因为只有表和列的数量和关系不足以继续。它可能完全没问题，也可能没有。数据的性质以及如何通过适当的规范化，索引和统计来计算数据是真正重要的。

Answer 3

有许多原因可能导致分解表（按列拆分）。初学者应该学习的第一个原因是数据规范化。数据规范化并不直接与性能有关，尽管规范化数据库有时会胜过构建不良的数据库，尤其是在负载下。

标准化的前三个步骤导致第1，第2和第3范式。这些表单与非键值与键的关系有关。一个简单的总结是，第三范式中的表是一个表，其中所有非键值都由键，整个键以及除键之外的任何其他键确定。

有大量的文献可以教会你如何规范化，规范化的好处是什么，以及有时会有什么缺点。一旦熟练掌握了规范化，您可能希望了解何时偏离规范化规则，并遵循像Star Schema这样的设计模式，从而产生结构良好但未规范化的设计。

有些人像传统一样对待正常化，但这超出了这个想法。这绝对是一件好事，但它只是一套指导方针，通常（但并不总是）引导您朝着令人满意的设计方向前进。

规范化数据库在更新时往往优于非规范化数据库，但可以构建非常规化数据库，这对于某些类型的检索来说非常快。

当然，所有这些都取决于您要构建的数据库数量，以及它们的大小和范围，

Answer 4

我认为登录表包含仅在用户登录系统时使用的数据。出于所有其他目的，使用详细信息表。

将这些数据集分成单独的表并不是一个坏主意，可以很好地适用于您的应用程序。但是，另一种选择是将数据放在一个表中，并使用覆盖索引将它们分开。

索引的一个方面似乎没有人考虑的是索引可以被认为是表中的子表。当SQL语句仅访问索引中的字段时，执行操作所需的I / O可以仅限于索引而不是整行。所以创建一个＆＃34;登录＆＃34;索引和＆＃34;详细信息＆＃34; index将获得与单独表相同的好处。有了额外的好处，任何需要所有数据的操作都不必执行两个表的连接。