一列表是好的设计吗？

Question

有一个只有一列的表可以吗？我知道这在技术上并不违法,但它被认为是糟糕的设计吗？

编辑:

这里有一些例子:

有人提到添加一个关键字段.我看到它的方式,这个单列将成为主键.

Answer 1

relational algebra就此而言,这将是一元关系,意思是" 这件事存在 "

是的,有一个表定义这样的关系是很好的:例如,定义一个域.

当然,这样的表的值应该是自然的主键.

查找表prime numbers是我首先想到的.

Answer 2

是的,以最高效率的方式设计桌子当然是一种很好的设计."糟糕的RDBMS设计"通常以效率低下为中心.

但是,我发现大多数单柱设计案例都可以从额外的列中受益.例如,州代码通常可以在第二列中拼写出全州名称.或者黑名单可以关联注释.但是,如果你的设计确实不需要那些信息,那么单列就可以了.

Answer 3

我过去曾经用过它们.我的一个客户希望自动阻止任何试图在这个大名单中注册电话号码的人,所以这只是一个大黑名单.

Answer 4

如果有一个有效的需要,那么我没有看到问题.也许您只是想要显示由于某种原因显示的可能性列表,并且您希望能够动态地更改它,但不需要将其链接到另一个表.

Answer 5

我发现的一个案例有时是这样的:

表countries_id,仅包含一个具有每个国家/地区的数字ID的列.

表countries_description,包含具有国家/地区ID的列,包含语言ID的列和包含本地化国家/地区名称的列.

表company_factories,包含公司每个工厂的信息,包括Wich所在的国家/地区.

因此,为了维护表中的数据一致性和语言无关数据,数据库将此模式与仅包含一列的表一起使用,以允许没有语言依赖性的外键.

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

编辑回应评论: Quassnoi

在这个模式中,我可以在表company_factories中定义一个外键,不要求我在表上包含Language列,但是如果我没有表countries_id,我必须在表上包含Language列来定义外键.

@Doliveras:好的,我现在看,+1.不过,我宁愿将ISO 3166-1用于coutry_code.与数字ID不同,3个字母的国家/地区代码可以让您了解世界上几乎每个人都可以阅读拉丁字母的国家/地区. (3认同)
为什么要使用countries_id？要插入国家/地区,您需要至少使用一种语言知道其名称,这会导致country_id出现在countries_description中.没有countries_description条目的country_id是没有意义的."COALESCE总裁巴拉克奥巴马先生(14243,country_name)回归无效,今天与Россия总裁德米特里梅德韦杰夫会面" (2认同)

Answer 6

在极少数情况下,单列表是有意义的.我做了一个数据库,其中有效语言代码列表是用作外键的单列表.拥有不同的密钥是没有意义的,因为代码本身就是关键.并且没有固定的描述,因为语言代码描述因某些上下文的语言而异.

通常,任何需要没有任何附加属性的权威值列表的情况都是单列表的理想选择.

Answer 7

我一直使用单列表 - 当然,取决于应用程序设计是否已经使用数据库.一旦我忍受了建立数据库连接的设计开销,我就尽可能将所有可变数据放入表中.

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

1)数据项存在.通常用于下拉列表.也用于简单的合法性测试.

例如.两个字母的美国州缩写; 我们发货的邮政编码; 在拼字游戏中合法的词语; 等等

2)稀疏二进制属性,即在大表中,二进制属性,对于非常少的记录都是真的.我可能会创建一个单独的表,而不是添加新的布尔列,该表包含属性为true的记录的键.

例如.患有绝症的员工; 银行年限为360天(最多使用365年); 等等

-Al.

Answer 8

大多数情况下，我在查找类型表（例如您描述的状态表）中看到了这一点。但是，如果您这样做，请务必将该列设置为主键以强制唯一性。如果您不能将此值设置为唯一值，则不应使用一列。