单柱桌是好的设计吗？[关闭]

有一个只有一列的表可以吗？我知道从技术上来讲这不是非法的，但是它被认为是糟糕的设计吗？

编辑：

这里有一些例子：

• 您有一个带有50个有效美国州代码的表，但是您无需存储详细的州名。
• 电子邮件黑名单。

有人提到添加一个关键字段。我的看法是，这单列将是主键。

是的，以使表格效率最高的方式设计表格无疑是一个很好的设计。“不良RDBMS设计”通常以低效率为中心。

但是，我发现大多数单柱设计案例都可以从附加色谱柱中受益。例如，州代码通常可以在第二栏中说明完整州名称。或黑名单可以具有关联的注释。但是，如果您的设计确实不需要这些信息，那么最好只使用一列。

relational algebra就此而言，这是一元关系，表示“ 此事物存在 ”

是的，最好有一个表来定义这种关系：例如，定义一个域。

当然，这样一个表的值应该是自然的主键。

prime numbers我首先想到的是一张查找表。

我过去曾经使用过它们。我的一个客户想要自动阻止任何试图使用他拥有的这个大名单中的电话号码进行注册的人，因此这只是一个大黑名单。

如果确实有需要，那么我认为没有问题。也许您只是出于某种原因希望显示可能性列表，并且希望能够动态更改它，但无需将其链接到另一个表。

我有时发现的一种情况是这样的：

表countries_id，仅包含一个与每个国家的数字ID列。

表country_description包含具有国家ID的列，具有语言ID的列和具有本地化国家名称的列。

表company_factories，包含公司每个工厂的信息，包括位于Wich的国家/地区。

因此，为了保持表中的数据一致性和语言无关的数据，数据库将这种模式与只有一列的表一起使用，以允许外键没有语言依赖性。

在这种情况下，我认为存在一个列表是合理的。

根据评论编辑： Quassnoi

_{（来源：ggpht.com）}

在此架构中，我可以在表company_factories中定义一个外键，该键不需要我在表中包括语言列，但是如果我没有表country_id，则必须在表中包括语言列以定义外键。

在少数情况下，单列表有意义。我做了一个数据库，其中有效语言代码的列表是用作外键的单列表。拥有不同的密钥毫无意义，因为代码本身就是密钥。而且由于语言代码描述在某些情况下会因语言而异，因此没有固定的描述。

通常，在任何情况下都需要不包含任何其他属性的权威值列表都是单列表的理想选择。

我一直在使用单列表-当然，这取决于应用程序设计是否已使用数据库。一旦承受了建立数据库连接的设计开销，便将所有可变数据放入表中。

我可以想到单列表OTMH的两种用法：

1）数据项存在。通常在下拉列表中使用。也用于简单的合法性测试。

例如。美国两个字母的州缩写；我们运送到的邮递区号；拼字游戏中的合法字词；等等

2）稀疏的二进制属性，即，在大表中，仅对很少的记录有效的二进制属性。我可能会创建一个单独的表，而不包含新的布尔列，该表包含属性为true的记录的键。

例如。患有绝症的员工；一年360天的银行（大多数使用365天）；等等

-Al

只要它包含唯一值，就没有问题。

通常，我已经在查询类型表（例如您描述的状态表）中看到了这一点。但是，如果执行此操作，请确保将列设置为强制唯一性的主键。如果您不能将此值设置为唯一值，则不应使用一列。

我通常会说是的。不知道为什么只需要一列。我看到一些有效的例外。这取决于您要实现的目标。

当您考虑数据库的架构时，它们并不是很好的设计，但实际上只能用作实用程序表。

我看过过去有效使用的数字表。

数据库的目的是使信息相互关联。没有相关数据时，该怎么办？

也许这是某种编译表（例如，名字+姓氏+生日），尽管我仍然不确定为什么要这么做。

编辑：我可以看到使用这种表为某种简单的列表。那是你用的吗？

是的，只要该字段是您所说的主键即可。原因是因为如果您插入重复数据，则这些行将是只读的。如果您尝试删除重复的行之一。由于服务器将不知道要删除哪一行，因此它将不起作用。

我能想到的唯一用例是一张单词表，也许是一个文字游戏。您访问表只是为了验证字符串是否是单词：从单词=？的单词中选择单词。但是，用于保存单词列表的数据结构要比关系数据库好得多。

否则，通常将数据库中的数据放置在数据库中，以利用数据的各种属性之间的关系。如果您的数据没有超出其价值的属性，将如何发展这些关系？

因此，尽管这不是非法的，但通常来说，您可能不应该拥有仅包含一列的表。

我所有的表都至少具有四个技术字段，串行主键，创建和修改时间戳记以及软删除布尔值。在任何黑名单中，您还想知道是谁添加了条目。因此，对我而言，答案是否定的，只有一个列的表没有意义，除非对某些东西进行原型设计。

是的，那很好。但是ID字段不会伤害到它吗？