数据库列类型前缀

Question

我一直在用数据库开发解决方案超过11年了，似乎我已经“开发”了一个关于在我的表中命名列的相当有争议的意见：我总是给它们一个3或4个字符的类型前缀，即intGroupID，nvcTitle，dtmCreated，bitPlayerHater等。我和其他几位开发人员一起工作，他们都绝对鄙视老派前缀约定。

（是的，我知道，我在这里没有发明任何东西，我只是拒绝放弃它）。

我的主要原因是当他们试图了解数据结构时，尽可能多地向我的开发人员提供信息。立即了解列的类型可以为您（或至少我）提供一个更好的心理形象，让您了解所处理的内容。与C＃或VB.NET相比，在编写查询时，通常不会从IDE获得相同的智能感知支持。

到目前为止，还没有人能够提出可以改变我对这一特定主题的看法的杀手论点。我还有其他一些同样有争议的命名约定，它们提高了清晰度，但是列前缀似乎让更多的人感到不安。

为什么数据库列的前缀被认为是一种不好的做法？

Answer 1

它被称为“Hungarian Notation”。

作为开发人员（和数据架构师），我发现它毫无价值。它没有提供太多信息。

1. 它只对部分类型信息提供快速，不准确的光泽。例如，它省略了长度。

   在更复杂的数据库环境中，对象是BLOB，它根本不提供有关blob中对象类型的信息。

2. 它使更改数据类型变得痛苦。

3. 有必要记住一个模糊的前缀。是vcName，strName还是uniName？

4. SQL自动处理类型转换，使特定类型的特定命名在很大程度上无关紧要。

5. 最重要的是：它没有提供有关数据的含义的有用文档。我的经验是人们几乎总是腐败这个意思。他们很少（如果曾经）对它是int还是string感到困惑;当他们想知道时，他们只是使用TOAD或其他提供ACTUAL类型的工具描述表格，而不是预期类型的​​部分摘要。

[说过它几乎没用，我意识到这可能不是你正在寻找的“杀手锏”。如果您能够逐点地用实际原因更新您的问题会有所帮助，您认为它们是匈牙利表示法的价值，因此可以逐点解决这些问题。]

Answer 2

我已经多次更改了列类型。例如，从code到number的{​​{1}}。如果没有前缀，我可以在不重新编码的情况下完成大多数情况，并且所有应用程序仍将运行（至少在oracle中）。使用您的方法，我需要将string更改为intCode，我100％确定我需要使用此字段重做所有代码！

将整数更改为浮点数也是如此。

有些人还使用表格缩写（例如strCode）为列名添加前缀。我觉得很难编码，因为我倾向于忘记缩写。具有50个表的系统倾向于获得非常相似的前缀。使用它的原因是当员工加入部门时，部门代码字段是一个唯一字段（department.dep_code和emp_code）。我认为它不会增加价值，因为使用表格别名可以更容易地实现这一点，而不会强制您使用前缀。

我在客户端代码中使用了很多GUI组件的前缀。例如。 dep_code用于单行编辑，但hungarian notation用于c和powerbuilder。转移到java时，我停止使用它。我想我的变量使用了更清晰的名字。然而，转向面向对象的语言是，一切都是对象，在任何地方使用sle都有点傻。

Answer 3

我没有为列名添加前缀的最大原因是，当我必须记住（然后键入）我的列的前缀而不是仅仅键入时，它倾向于使我的查询输入的时间更长逻辑名称（例如FirstName而不是strFirstName）。

Answer 4

通常，您或使用您的数据的人应该知道您的数据的基础。由于查询不是真正的强类型强制，您可以参数化任何查询。您第一次测试查询将会起作用或失败。修复它，然后继续。

至于在visual IDE中工作，我见过许多商店没有强制命名对象（文本框，组合框等）与常见的约定。由于我历史上做的很多东西是动态生成，链接，绑定的，我在控件上使用这样的前缀，例如txtFirstName，btnOk，cboStateList等。然后，控件，我剥离前3个字符并且名称为字段（如果适用）在运行时自动绑定到数据对象。但是，如前所述，表中列名的前缀可能会导致更多问题，而不是它的帮助。

只是我的美元价值（通货膨胀从2美分）

Answer 5

问题出现在所谓的匈牙利语表示法和匈牙利语系统符号之间。前者添加了有关您拥有的种数据的信息（例如dx可能意味着“左边界的像素数”），而后者添加了有关类型的信息bit表示bit）。

使用当前的编程环境和方法，您无需查找正在使用的变量的类型。 IDE和编译器会告诉您是否错了。所以这实际上是冗余数据，当你开始（自动）从这些名称生成源时，这些数据开始受到影响：

// just looks wrong:
public void SetSomething(bool bitPlayerHater)

阅读Joel关于Making Wrong Code Look Wrong的文章。特别是“我是匈牙利”一节。

Answer 6

另外，如果您必须更改数据类型（它发生的事情比您想象的要多 - 我们只是转移到unicode），您必须在代码中更改列名。 （这对你来说是件坏事！）： - ）

Answer 7

根据我的经验，数据库系统非常擅长强制操作的类型安全性，因此几乎不需要这样的前缀。我的数据库理想主义者说系统应该基于域（抽象数据类型），所以对于与不同运营商的兼容性，低级数据类型基本上是无关紧要的。

系统实施后，任何需要知道列类型的人都可以轻松查询数据字典/系统目录以查找此信息。在建模阶段，这些类型通常也可以作为规范的一部分随时可用。

不使用前缀的一个很好的理由：它会使对标识符排序的数据字典执行查询变得困难，因为标识符的前导部分现在实际上是类型。在我看来，类型是与标识符不同的属性，因此应该单独存储。

Answer 8

我正要说我多年来一直在使用一个匈牙利语命名数据库...它基本上没问题，但多年来一些数字前缀字段实际上包含字母数字，而一些布尔标志不包含，而且一些变种人已经变成了clo，等等......足以代表年轻球员的重要陷阱。

我没有也不认为命名惯例实际上有任何“错误”...它只是有点不灵活，开发人员可以应对...但我同意它增加的价值非常小...程序员通常都是非常聪明的人，记住db-schema的数据类型并不会带来太大的挑战......特别是如果你长时间使用系统。

所以总而言之，我会给匈牙利的记法大拇指，但如果我继承了一个使用它的系统，我创造了新的桌子，我会遵循惯例......无论如何，这都不是我的鼻子。

如果他们继续抱怨，请发送给我。我会给他们一些真正令人生气的东西，例如Java程序中的PascalCase，或者仅仅是非资本化的CONSTANTS; - ）

顺便说一句：我还将用于命名控件（和控件）的VB标准转换为Java，因为它有意义，它提供了有用的信息;它广为人知，并且使用它作为通用语，即使它违反了Java编码标准。

我对编码标准的态度：

• 做任何事都行。
• 阅读并理解至少一个已发布的标准，但不要教条地遵循它。见第1点。
• 在罗马时......一致性是让它“挂在一起”的关键。见第1点。

干杯。基思。