我已经用数据库开发解决方案超过 11 年了，似乎我已经“开发”了一个关于命名我的表中的列的相当有争议的观点：我总是给它们一个 3 或 4 个字符类型的前缀，即 intGroupID， nvcTitle、dtmCreated、bitPlayerHater 等。我曾与其他几个完全鄙视老式前缀约定的开发人员一起工作。
（是的，我知道，我没有在这里发明任何东西，我只是拒绝放弃它：）
我的主要理由是在我的开发人员尝试理解数据结构时向他们提供尽可能多的信息。立即了解列的类型可以让您（或至少我）更好地了解您正在处理的内容。与使用 C# 或 VB.NET 相比，当您编写查询时，通常不会从 IDE 获得相同的智能感知支持。
到目前为止，没有人能够提出可以改变我对这个特定主题的想法的杀手锏。我还有其他一些同样有争议的命名约定，可以提高清晰度，但列前缀似乎惹恼了更多人。
为什么为数据库列添加前缀被认为是一种不好的做法？
它被称为“匈牙利符号”。
作为一名开发人员（和数据架构师），我发现它毫无价值。它没有提供太多信息。
它仅对部分类型信息提供快速、不准确的注释。例如，它省略了长度。
在对象是 BLOB 的更复杂的数据库环境中，它根本不提供有关 blob 中对象类型的信息。
它使更改数据类型变得痛苦。
有必要记住一个晦涩的前缀。是vcName，strName还是uniName？
SQL 自动处理类型转换，使得繁琐的特定于类型的命名在很大程度上无关紧要。
最重要的是：它没有提供有关数据含义的有用文档。我的经验是，人们几乎总是会破坏意义。他们很少（如果有的话）对它是 int 还是 string 感到困惑。当他们想知道时，他们只需使用 TOAD 或其他提供 ACTUAL 类型的工具来描述表格，而不是预期类型的部分摘要。
[虽然说它几乎没用，但我意识到这可能不是您要寻找的“杀手锏”。如果您可以用实际原因逐点更新您的问题，这将有所帮助，您认为这是匈牙利符号的价值，因此可以逐点解决。]
我已经更改了几次列类型。例如code从number到string。在大多数情况下，如果没有前缀，我可以在不重新编码的情况下做到这一点，并且所有应用程序仍将运行（至少在 oracle 中）。使用您的方法，我需要更改intCode为strCode，并且我 100% 确定我需要使用此字段重做所有代码！
将整数更改为浮点数也是如此。
有些人还会在列名前加上表格缩写（例如department.dep_code）。我发现这真的很难编码，因为我倾向于忘记缩写。具有 50 个表的系统往往会获得非常相似的前缀。使用它的一个原因是在将员工加入部门时，部门代码字段是一个唯一字段（emp_code和dep_code）。我认为它不会增加价值，因为使用表别名可以更轻松地完成此操作，而不会强制您使用前缀。
我在客户端代码中为 GUI 组件使用了很多前缀。例如sle，用于单行编辑，还有用于 c 和 powerbuilder的匈牙利符号。迁移到 java 时，我停止使用它。我想我为变量使用了更清晰的名称。然而，转向面向对象的语言是，一切都是对象，在任何地方都使用它有点傻objVariable。
我不输入列名前缀的最大原因是，当我必须记住（然后输入）列的前缀而不是仅仅输入逻辑名称时，它倾向于使输入查询的过程更长（例如 FirstName 而不是 strFirstName）。
通常，您或那些使用您的数据的人应该知道您的数据的基础。由于查询不是真正强制执行的强类型，因此您可以参数化任何查询。您第一次测试查询要么成功，要么失败。修复它，然后继续。
至于在可视化 IDE 中工作，我见过许多不强制使用通用约定命名对象（文本框、组合框等）的商店。由于我以前做过的很多东西都是动态生成、链接、绑定的，所以我在控件上使用了这样的前缀，例如 txtFirstName、btnOk、cboStateList 等。然后，这些控件，我去掉前 3 个字符并命名为在运行时自动绑定到数据对象的字段（如果适用）。但是，如前所述，表中列名的前缀可能会导致更多问题而不是帮助。
只是我的美元价值（2 美分的通货膨胀）
问题在于所谓的 Apps Hungarian Notation 和 Systems Hungarian Notation 之间。前者添加有关您拥有的数据类型的信息（例如dx，可能意味着“距左边框的像素数”），而后者添加有关您拥有的数据类型的信息（例如bit，意味着bit）。
使用当前的编程环境和方法，您永远不必查找正在使用的变量类型。如果你错了，IDE 和编译器会告诉你。因此，这本质上是冗余数据，当您开始（自动）从这些名称生成源时，它开始影响您：
// just looks wrong:
public void SetSomething(bool bitPlayerHater)
阅读 Joel 关于让错误代码看起来错误的文章。尤其是“我是匈牙利”部分。
另外，如果您必须更改数据类型（它发生的次数比您想象的要多 - 我们刚刚迁移到 unicode），您必须在整个代码中更改列名。（顺便说一句，这是一件坏事！）:-)
根据我的经验，数据库系统非常擅长执行操作的类型安全，因此几乎不需要这样的前缀。我心中的数据库理想主义者说系统无论如何都应该基于域（抽象数据类型），因此就与不同运算符的兼容性而言，低级数据类型基本上是无关紧要的。
系统实施后，任何需要知道列类型的人都可以轻松查询数据字典/系统目录以查找此信息。在建模阶段，这些类型通常也很容易作为规范的一部分获得。
不使用前缀的一个很好的理由是：这会使对按标识符排序的数据字典执行查询变得困难，因为标识符的前导部分现在实际上是类型。在我看来，类型是与标识符不同的属性，因此应该单独存储。
我正要说我在一个名为匈牙利语的数据库上工作了多年……基本上没问题，但多年来，一些以数字为前缀的字段实际上包含字母数字，而一些布尔标志不包含，还有一些的 varchars 已经变成了 clob，等等等等......无论如何，这足以代表年轻球员的一个重要陷阱。
我没有也不认为命名约定实际上有任何“错误”......它只是有点难以理解，开发人员可以应付......但我同意它增加的价值很少......程序员通常是非常聪明的人，记住数据库模式的数据类型实际上并没有太大的挑战……特别是如果您长时间使用系统。
所以总而言之，我不赞成匈牙利符号，但如果我继承了一个使用它的系统，并且我创建了新表，我会遵循惯例......无论如何，这都不是我的鼻子。
如果他们一直抱怨，把他们发给我。我会给他们一些真正让他们生气的东西，比如 Java 程序中的 PascalCase，或者非大写的 CONSTANTS，例如 ;-)
顺便说一句：我还将用于命名控件（和仅控件）的 VB 标准移植到 Java 中，因为它很有意义，并且提供了有用的信息；它是如此广为人知和使用，以至于它可以作为一种通用语言，即使它违反了 Java 编码标准。
我对编码标准的看法：
干杯。基思。