【问题标题】:Finding the right terminology for a dictionary table查找字典表的正确术语
【发布时间】:2012-08-28 08:34:31
【问题描述】:

我关心的是我目前所说的“字典表”,即数据库表 包含受控词汇表。

让我们举个例子: 假设您有一个包含字段的表 User

  • user_id : 主键
  • 名字
  • 姓氏
  • user_type_id : UserType 表的外键

另一个表UserType只有两个字段:

  • user_type_id : 主键
  • name:特定类型用户的名称/值。

例如,UserType 表可能包含 (1, Administrator), (2, PowerUser), (3, Normal)...

我的问题是:像 UserType 这样的表的规范术语是什么,它只包含(dictinct)单词的列表。 我想发布一些代码来帮助管理此类表,但首先我必须为它们命名!

感谢您的帮助。

目前的想法: 现在我觉得 Lookup Tables 是一个很好的术语。它在这些帖子中也具有相同的含义:

唯一的问题是 lookup 表有时也用于命名 junction 表。

【问题讨论】:

  • 我称之为查找表。不确定这是否是公认的术语。
  • +1 到查找表。我也会这样称呼它。 My answer below 用于其中的值,然后可以称为查找值而不是候选键。
  • 物理上称为查找表或元数据。你实际上用一系列这些东西构建的是一个数据字典。
  • @KarlForner 请参阅反对票/赞成票常见问题解答。 stackoverflow.com/privileges/vote-down

标签: sql terminology rdbms database


【解决方案1】:

我经常将单词列表视为函数的域(允许的输入值集),因此我将它们称为域表。但这是从数学的角度来看。

编辑

见:

【讨论】:

  • 谢谢。这是有道理的,但如果你是唯一一个使用它的人,那就有点违背了目的。
  • 每个人都应该知道函数的域是什么;)
  • 为什么投反对票?域是列(或类似列)的值范围的有效 RDBMS 术语,例如是/否,对/错。
  • 抱歉,刚刚从候选人中丢弃了域。
【解决方案2】:

作为一名 C 编码员,我想说这张表看起来真的很像 enum(或枚举)。它详尽地定义了可接受的值并将自动给定的整数链接到名称(反之亦然)。

作为一个 SO 用户,我想说这个问题看起来有点过于开放,因为我认为没有一个唯一的规范名称......

【讨论】:

  • 感谢您的回答。我只想知道人们使用的术语,以便我可以查找文档并以适当的名称发布。并称猫为猫或猫(我不知道法语的翻译是否有效)。
  • 作为一名法语程序员,我明白你的意思了 ^^ 但说真的,我认为enum(我真正使用过)准确地描述了它是什么以及它是如何使用的。
  • 我同意 enum 看起来相当不错,但我在等着看是否有社区接受的术语。查找也可以工作,甚至更好。
  • 我必须承认,我从未在我使用过的任何 RDBMS 中遇到过枚举(在编程意义上),但这将是一个非常受欢迎的补充。
  • MysQLPostgreSQL 具有枚举数据类型。但这仅适用于列,不能替换“枚举”表。
【解决方案3】:

您所描述的通常称为数据字典

【讨论】:

【解决方案4】:

你可以完全相反,用他们的技术名称而不是他们的含义来称呼他们,让 ppl 推断——你可以叫他们candidate keys——这在“选择你选择的候选人”中是有道理的大大地;每个候选人都是独一无二的*(或应该是)。

如果不是完全令人头疼的命名问题,它们往往会很有趣:-)

【讨论】:

  • 我真的不明白你的提议,即使在阅读了候选键之后!
  • 相反,我的意思是——搜索技术名称和有意义的名称——候选键是查找表中的值。这些是您实际选择的值,在它们被引用的表中。所以UserType.user_type_idUser.user_type_id 的外键,或者以有意义 的方式表示,UserType.user_type_id UserType.name 是@987654327 中值的候选者@(在这些特定列中,User.user_type_id 此处)。您问UserType table 的规范名称应该是什么——我说我同意 @phillyd 提出的术语 Lookup Table。。跨度>
  • 我认为候选键是查找表中的列?
  • 是的,关键是列的索引/规则,但您在概念上所做的是建立指向该列中值的链接。进一步探索“列”与“特定行中的列值”只是语义。 “键”始终是列,使用基于该列的值。但是您正在寻找“可以称呼它的东西”而不是进入技术定义来迷惑您的用户,对吗?查找表/列/值足以进行此类解释。否则,只需将其称为父键/父键表。
【解决方案5】:

根据我与 SQL 开发人员打交道的经验,他们的关系理论背景越强,他们使用“查找表”、“验证表”或“字典表”等术语的可能性就越小。

相反,他们只是称它们为桌子。为什么?

对你来说,重要的部分似乎是表格

  • 仅包含一个文本列,或
  • 仅包含一个文本列和一个 ID 号,或者
  • 仅包含一个文本列和一个短文本代码,并且
  • 主键用作外键引用的目标。

如果您仔细考虑一下,这些表与其他表的唯一区别就是列数。关系理论通过列数来区分关系,我也不觉得需要像 SQL 那样区分。

  • 每个候选键在这个意义上实现了一个受控词汇表——键(和所有其他适用的约束)提供了控制“词汇表”的机制。
  • 每个候选键都可以用作外键引用的目标,无论表有多少候选键,无论候选键有多少列,也无论是否有任何候选键用作今天的外键引用。
  • 许多这样的表只是开始作为“查找”表。一年后,有人发现需要存储更多信息。添加一两列后,它是否仍然是“查找”表?

【讨论】:

  • 这并不是将这些表与其他表区分开来的唯一因素。行数是有限的,而且通常非常小,而且它们非常稳定(几乎没有变化),这使得它们成为例如缓存的完美目标。在我的应用程序中,我至少有 10 个这样的表。
  • 行数和稳定性可能只是巧合。一个国家名称表大约有 400 行,但一个城市名称表可能超过 35,000 行。
  • 你说得很好。怎么称呼这些东西很大程度上取决于目标受众。查找表对开发人员可能意义重大,但对用户而言毫无意义(同上其他术语,如域)。
  • @catcall:你说得对,我的目的是控制词汇,避免代码中的硬编码字符串。
  • @dee:目标受众是开发人员,我想命名一个perl包。
猜你喜欢
  • 2020-06-17
  • 2011-07-26
  • 1970-01-01
  • 2012-09-21
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多