我设计了我的数据库，其中一个表包含52列。所有属性都与主键属性紧密关联，因此没有进一步规范化的范围。
如果出现同样的情况，请告诉我，您不希望在一张表中保留这么多列，这样做的另一个选择是什么。
答案 0 :(得分：3)
以任何方式拥有50列并不奇怪。 ERP系统在某些表格中通常有100多列。
您可以研究的一件事是确保大多数列都有有效的默认值（null，今天等）。这将简化插入。
还要确保您的代码始终指定列（即没有“select *”）。任何类型的未来优化都将包括具有列子集的索引。
答案 1 :(得分：2)
我们使用过一次的方法是将表拆分为两个表。这两个表都获得原始表的主键。在第一个表中，放置最常用的列，在第二个表中放置较少使用的列。通常，第一个应该更小。您现在可以使用各种索引加快第一个表中的内容。在我们的设计中，我们甚至在内存引擎（RAM）上运行了第一个表，因为我们只有读取查询。如果需要获取table1和table2中列的组合，则需要使用主键连接两个表。
答案 2 :(得分：0)
包含52列的表不一定错。正如其他人指出的那样，许多数据库都有这样的野兽。但是，我不认为ERP系统是良好数据设计的典范：根据我的经验，它们往往相反。
无论如何，继续前进！
你这样说：
“所有属性都与主键紧密相关 属性“
这意味着您的表格处于第三范式（或者可能是BCNF）。在这种情况下，不可能进一步归一化是不正确的。也许你可以去第五范式？
第五种正常形式是关于删除连接依赖关系。您的所有列都依赖于主键，但列之间也可能存在依赖关系：例如，COL42的多个值与COL23的每个值相关联。 Join dependencies意味着当我们添加COL23的新值时，我们最终会插入几条记录，每条记录对应COL42的一个值。 Wikipedia article on 5NF有一个很好的例子。
我承认没有多少人能够到达5NF。而且很可能即使有52列，你的表也已经在5NF了。但值得一试。因为如果您可以打破一个或两个子表，您将改进数据模型并使主表更易于使用。
答案 3 :(得分：-1)
另一种选择是“多列表”MCT设计中的“项目 - 结果对”（IRP）设计，特别是如果您将不时添加更多列。
MCT_TABLE
---------
KEY_col(s)
Col1
Col2
Col3
...
IRP_TABLE
---------
KEY_col(s)
ITEM
VALUE
select * from IRP_TABLE;
KEY_COL ITEM VALUE
------- ---- -----
1 NAME Joe
1 AGE 44
1 WGT 202
...
IRP使用起来有点困难，但更加灵活。
我使用IRP设计构建了非常大的系统，即使对于海量数据也能很好地运行。实际上它有点像一个列组织DB，因为你只需要拉入你需要的行（即更少的I / O）而不是当你只需要几列（即更多的I / O）时整个宽行。