我有一个相当常见的场景，用户可以从一组属性中进行选择。 UI中的属性由复选框表示。
例如：
组件：Harddrive（y / n），CPU（y / n），显示器（y / n），键盘（y / n）等....
在过去，我一般将这种情况建模如下：
"PCs" 1:M "PC Components" M:1 "Components"
另一种选择是将“属性”作为“PC”表中的y / n字段。
e.g。
PCs (table)
-----------
PCId(PK)
Harddrive(y/n)
CPU(y/n)
etc...
过去我选择一对一的理由是基于用户是否可以输入新属性。如果答案是肯定的，那么我选择第一个选项，如果答案为否，那么我通常会使用y / n属性。
但是现在我有一个场景，其中大约有20个属性分为多个类别。在创建ERD之后，它看起来“错误”并且表格的列数很荒谬。
我的问题是，是否有标准/正确的方法对此进行建模？如果是这样，它有名字吗？
答案 0 :(得分：2)
有人试图设计一个更“紧凑”的数据模型（每个属性不是一列），因为属性具有兼容的数据类型（它们都是y / n）。
如果每个属性都有不同的数据类型，例如，如果它们使用不同的查找表限制为一组值，那么每个属性必须使用一个列是明智的。
见Domain-Key Normal Form。将y / n属性建模为行意味着无法表示强制属性（必须具有Y或N值）。所以你有一些约束，N个属性必须有N行。对最小行数的约束既不是域约束也不是键约束，因此它无法通过DKNF测试。
每个表都没有必要符合DKNF，但如果你问的是哪个术语描述了每个属性列的设计，我建议“域/键范式”适合。
答案 1 :(得分：1)
我遵循这个简单的规则：每列一个数据。让数据库优化存储结构。
因此，在SQL Server世界中，我使用BIT数据类型，是的，单独的列。其他数据库，我确定，有相应的类型。