我和一位同事偶然发现了一个新获得的数据库架构，其中包含多个似乎只有一列的表。一个表似乎是某种类型，另一个表是某种频率，等等。我们在这里只处理一个模式，因此没有实际数据可供参考。
我们已经考虑过了，但我们无法真正理解需求或应该“在最佳实践中”仅使用单个列的信息类型。
通过我的教育，我们被教导应该始终有某种注释、时间戳、描述或与每个主键相关的信息类型。
通过几次谷歌搜索，我发现很多网站只提到这种行为如何影响主键实践，而不是一般信息。
所以重申我的问题：设计只有一列的表是否被认为是一种不好的做法？只说单列这实际上有什么好处呢？有没有你能想到的行业例子？
【问题讨论】：
标签： sql sql-server database database-design
我创建的几乎每个表都有以下列：
Id）。单列表的一个用途是有效地实现检查约束，其中代码可以动态验证值。我通常会使用具有适当外键关系和上述列的引用表来实现这一点。
另一个实例是一个数字表，它只存储整数值。
总的来说，我会说这不是一个好主意。可能有特定的情况，例如数字表就可以了。
【讨论】：
在我看来，这取决于这些表的用途。
如果你有很多，那可能是错误的。我可以想到单列表的一些用途，它们可以用作derived tables 来生成 ID、序列、日期（这可能更有用，多于 1 列来指定月份、年份..）等，但我相信他们确实有目的。
一般来说，在表格中包含多于一列、某种 ID 或日期的关键列总是更好，这样它就会有意义。
如果这是不好的做法？我相信如此，最好在表格上获得更多信息，除非它是用于特定目的的特定表格。
【讨论】：
这取决于，没有惊喜。
我看到的单列表的另一种情况是实体的锚表，其中每个属性（名称、日期等）都被证明是时间相关的或版本相关的。因此，它们被组织成许多扩展历史/版本表，其中包含一组以某种方式分组的属性，其中每个这样的扩展组都是可选的。
【讨论】：
如果该列不是主键，那绝对是不好的做法。
但如果它是主键，并且其他表的外键或其他表与此有外键关系，则它可以是模式规范化的一部分。
您可以通过创建两列表 (ID,PREVIOUSLY_NULLABLE_COLLUMN) 而不是可空列（或者如果您有 ID、A、B、C 列，其中 A 和 B 都不应为 null 或 null 和 C是独立可选的，您将拥有表 (ID),(ID,A,B), (ID,C))。
如果原始表只有可以为空的列和主键，您将以一个列表和一堆“列”表结束。
如果你真的实现了更高的 NF（我不记得是哪一个）或者如果你有很多可选列，那么这种方法是有意义的。
【讨论】：