3

我以这样一种方式设计了我的数据库，即我的一个表包含 52 列。所有属性都与主键属性紧密关联，因此没有进一步规范化的范围。

如果出现同样的情况并且您不想在一个表中保留这么多列，请告诉我，其他选择是什么。

4

4 回答 4

3

有 50 列并不奇怪。ERP 系统在某些表中通常有 100 多个列。

您可以研究的一件事是确保大多数列都有有效的默认值（null、today 等）。这将简化插入。

还要确保您的代码始终指定列（即没有“选择 *”）。任何类型的未来优化都将包括具有列子集的索引。

于 2012-04-27T06:53:22.110 回答
2

我们曾经使用过的一种方法是将表拆分为两个表。这两个表都获取原始表的主键。在第一个表中，您放置最常用的列，在第二个表中放置较少使用的列。通常第一个应该更小。您现在可以使用各种索引加快第一个表中的速度。在我们的设计中，我们甚至在内存引擎 (RAM) 上运行了第一个表，因为我们只有读取查询。如果您需要从 table1 和 table2 获取列的组合，则需要使用主键连接两个表。

于 2012-04-27T06:42:31.517 回答
0

五十二列的表不一定是错误的。正如其他人指出的那样，许多数据库都有这样的野兽。但是，我不会将 ERP 系统视为良好数据设计的典范：根据我的经验，它们往往恰恰相反。

无论如何，继续前进！

你这样说：

“所有属性都与主键属性紧密相关”

这意味着您的表格是第三范式（或者可能是 BCNF）。在这种情况下，不可能进一步规范化是不正确的。也许你可以去第五范式？

第五范式是关于删除连接依赖项。您的所有列都依赖于主键，但列之间也可能存在依赖关系：例如，COL42 的多个值与 COL23 的每个值相关联。连接依赖意味着当我们添加一个新的 COL23 值时，我们最终会插入几条记录，每个 COL42 值对应一条记录。关于 5NF的Wikipedia 文章有一个很好的例子。

我承认没有多少人能达到 5NF。很可能即使您的表格有 52 列，也可能已经在 5NF 中了。但值得检查。因为如果您可以拆分一两个子表，您将改进您的数据模型并使您的主表更易于使用。

于 2012-04-27T13:12:51.550 回答
-1

另一种选择是“项目-结果对”(IRP) 设计，而不是“多列表” MCT 设计，尤其是在您不时添加更多列的情况下。

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 设计构建了非常大的系统，即使对于海量数据，它也可以很好地执行。事实上，它的行为就像一个按列组织的数据库，因为您只需要拉入您需要的行（即更少的 I/O），而不是当您只需要几列（即更多的 I/O）时整个宽行。

于 2012-04-27T11:51:54.193 回答