数据库列类型前缀
我已经开发数据库解决方案超过 11 年了，似乎我已经“开发”了一个关于命名表中列的相当有争议的观点：我总是给它们一个 3 或 4 个字符的类型前缀，即 intGroupID， nvcTitle、dtmCreated、bitPlayerHater 等。我曾与其他几位开发人员合作过，他们都绝对鄙视老式的前缀约定。
（是的，我知道，我在这里没有发明任何东西，我只是拒绝放弃它:)
我的主要理由是当我的开发人员同事尝试理解数据结构时，向他们提供尽可能多的信息。 了解列的类型可以立即让您（或至少是我）对正在处理的内容有更好的心理印象。 与使用 C# 或 VB.NET 相比，当您编写查询时，IDE 通常无法提供相同的智能感知支持。
到目前为止，没有人能够提出能够改变我对这个特定话题的看法的致命论点。 我还有其他一些同样有争议的命名约定，它们可以提高清晰度，但列前缀似乎会激怒更多的人。
为什么给数据库列添加前缀被认为是一种不好的做法？
I’ve been developing solutions with databases for more than 11 years now, and it seems I’ve “developed” a rather controversial opinion about naming columns in my tables: I always give them a 3 or 4 character type prefix, i.e. intGroupID, nvcTitle, dtmCreated, bitPlayerHater, etc. I’ve worked with several other developers who all absolutely despised the old-school prefix convention.
(yeah, I know, I didn’t invent anything here, I’m just refusing to give it up:)
My primary reasoning is to provide as much information as possible to my fellow developers when they attempt to understand the structure of the data. Knowing the type of the columns instantly gives you (or me, at least) a better mental image of what you’re dealing with. And you usually don’t have the same intellisense support from the IDE when you’re writing queries compared working with C# or VB.NET.
So far nobody has been able to come up with the killer argument that could change my mind on this particular topic. I have a couple of other equally controversial naming conventions which increases clarity, but the column prefix seems to piss more people off.
Why is prefixing database columns considered such a bad practice?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
它称为“匈牙利表示法”。
作为一名开发人员（和数据架构师），我发现它毫无价值。 它没有提供太多信息。
它仅提供对部分类型信息的快速、不准确的注释。 例如，它省略了长度。
在更复杂的数据库环境中，对象是 BLOB，它根本不提供有关 blob 中对象类型的信息。
它使更改数据类型变得痛苦。
有必要记住一个晦涩的前缀。 是
vcName、strName还是uniName？SQL 自动处理类型转换，使得繁琐的特定于类型的命名在很大程度上无关紧要。
最重要的是：它没有提供有关数据含义的有用文档。 我的经验是，人们几乎总是会歪曲含义。 他们很少（如果有的话）对它是 int 还是 string 感到困惑； 当他们想知道时，他们只是使用 TOAD 或其他给出实际类型的工具来描述表格，而不是预期类型的部分摘要。
[虽然说它几乎没有用，但我意识到这可能不是您正在寻找的“杀手级论点”。 如果您可以逐点更新您的问题，您认为这是匈牙利表示法的价值，这样它们就可以逐点解决，这将会有所帮助。]
It's called "Hungarian Notation".
As a developer (and data architect), I find it worthless. It doesn't provide much information.
It only provides a quick, inaccurate gloss on part of the type information. It omits length, for example.
In more complex database environments, where the objects are BLOB's, it provides no information at all about the type of object in the blob.
It makes changing data type painful.
It's necessary to remember an obscure prefix. Is it
vcName,strNameoruniName?SQL handles type conversions automatically, making fussy type-specific naming largely irrelevant.
Most Important: It provides no useful documentation on the meaning of the data. My experience is that people corrupt the meaning almost always. They're rarely (if ever) confused on whether it's int or string; and when they want to know, they simply describe the table using TOAD or some other tool that gives the ACTUAL type, not a partial summary of the intended type.
[Having said that it's approximately useless, I realize that this is probably not the "killer argument" you're looking for. It would help if you could update your question with the actual reasons, point-by-point, that you feel are the value of Hungarian Notation, so they can be addressed point by point.]
我已经更改了几次列类型。 例如，从
数字到字符串的代码。 如果没有前缀，我可以在大多数情况下无需重新编码即可完成此操作，并且所有应用程序仍将运行（至少在 Oracle 中）。 使用您的方法，我需要将intCode更改为strCode，并且我 100% 确定我需要使用此字段重做所有代码！将整数更改为浮点数也是如此。
有些人还在列名前加上表缩写（例如
department.dep_code）。 我发现这真的很难编码，因为我容易忘记缩写。 具有 50 个表的系统往往会获得非常相似的前缀。 使用它的一个原因是当将员工与部门连接时，部门代码字段是一个唯一字段（emp_code和dep_code）。 我不认为它会增加价值，因为使用表别名可以更轻松地完成此操作，而不会强制您使用前缀。我在客户端代码中经常为 GUI 组件使用前缀。 例如用于单行编辑的
sle以及用于 c 的 匈牙利表示法和电力建设者。 当转向 java 时，我停止使用它。 我想我为变量使用了更清晰的名称。 然而，转向面向对象的语言是，一切都是对象，到处使用 objVariable 有点愚蠢。I have changed column types a few times. For example a
codefromnumbertostring. Without prefixes I can do it without recoding n most cases and all applications will still run (at least in oracle). With your method I need to changeintCodetostrCodeand I'm 100% sure I need to redo all my code using this field!The same is true for changing integer to floats.
Some people also prefix column names with the table abbreviation (e.g.
department.dep_code). I find that really hard to code with as I tend to forget the abbreviations. A system with 50 tables tend to get very similar prefixes. A reason for using it is when joining employee with department, department code field is a unique field (emp_codeanddep_code). I do not think that it add value as this can be done easier using table aliases which do not force you to use prefixed.I used prefixes in my client code a lot for GUI components. E.g.
slefor single line edit but also the hungarian notation for c and powerbuilder. When moving to java I stopped using it. I guess I used clearer names for my variables. However moving to an object oriented languages is, is that everything is an object and it is a bit silly to useobjVariableeverywhere.我不为列名添加类型前缀的最大原因是，当我必须记住（然后键入）列的前缀而不是仅仅键入逻辑名称时，它倾向于使键入查询的过程变得更长（例如 FirstName 而不是 strFirstName）。
My biggest reason for not type-prefixing column names is it has a tendency to make the process of typing out my queries that much longer when I have to remember (and then type) the prefix of my columns instead of just typing out the logical name (such as FirstName instead of strFirstName).
通常，您或处理数据的人员应该了解数据的基础。 由于查询并不是真正强制执行的强类型，因此您可以参数化任何查询。 第一次测试查询要么成功，要么失败。 修复它，然后继续。
至于在可视化 IDE 中工作，我见过许多商店不强制使用通用约定来命名对象（文本框、组合框等）。 由于我以前做过的很多东西都是动态生成、链接、绑定的，所以我在控件上使用这样的前缀，例如 txtFirstName、btnOk、cboStateList 等。然后，我剥离控件的前 3 个字符，并将其名称命名为在运行时自动绑定到数据对象的字段（如果适用）。 然而，如前所述，表中列名的前缀可能会导致更多问题而不是所带来的帮助。
就我的美元价值（通货膨胀2美分起）
Typically, you, or those working with your data should know the basis of your data. Since queries aren't truely strong-type enforced, you could parameterize any query. Your first time of testing the query would either work, or fail. Fix it, then move on.
As for working in the visual IDE, I've seen many shops that don't enforce naming the objects (textbox, comboboxes, etc) with a common convention. Since a lot of stuff I have historically done is dynamically generated, linked, bound, I use such prefix on controls, such as txtFirstName, btnOk, cboStateList, etc. Then, the controls, I strip the first 3 char and have the name of the field (if applicable) to auto-bind at run-time to a data object. However, as stated first, a prefix on column names in a table can cause more problems than it helps.
Just my dollar's worth (inflation from 2 cents)
问题出在所谓的应用匈牙利表示法和系统匈牙利表示法之间。 前者添加有关您拥有的数据种类的信息（例如
dx可能意味着“左边框的像素数”），而后者添加有关您拥有的数据类型（例如，bit表示bit）。使用当前的编程环境和方法，您永远不必查找正在使用的变量的类型。 IDE 和编译器会告诉您是否错误。 因此，这本质上是冗余数据，当您开始（自动）生成这些名称的源代码时，这些数据就会开始妨碍您：
阅读 Joel 关于 让错误的代码看起来错误。 特别是“我是匈牙利”部分。
The problem is between the so called Apps Hungarian Notation and the Systems Hungarian Notation. The former adds information about the kind of data you have (e.g.
dxcould mean "number of pixels from left border"), while the latter adds information about the type of data you have (e.g.bitto meanbit).With current programming environments and methods, you never have to lookup what type of variable you're working with. The IDE and the compiler will tell you if you're wrong. So this is essentially redundant data, which starts to get into your way when you start (auto)generating source off those names:
Read Joel's article about Making Wrong Code Look Wrong. Especially the section "I’m Hungary".
另外，如果您必须更改数据类型（这种情况发生的次数比您想象的要多 - 我们刚刚迁移到 unicode），您必须更改整个代码中的列名称。 （顺便说一句，这是一件坏事！）:-)
Plus if you ever have to change your data type (it happens more than you think - we just moved to unicode), you have to go change column names all over your code. (that's a bad thing btw!) :-)
根据我的经验，数据库系统非常擅长强制操作的类型安全，因此这样的前缀几乎没有必要。 我心中的数据库理想主义者说，无论如何，系统应该基于域（抽象数据类型），因此就与不同运算符的兼容性而言，低级数据类型基本上是无关紧要的。
一旦系统实现，任何需要知道列类型的人都可以轻松查询数据字典/系统目录来查找此信息。 在建模阶段，这些类型通常也可以作为规范的一部分轻松获得。
不使用前缀的一个很好的理由是：这将使对按标识符排序的数据字典执行查询变得困难，因为标识符的前导部分现在实际上是类型。 在我看来，类型是与标识符不同的属性，因此应该单独存储。
In my experience, database systems are pretty good at enforcing the type-safety of operations, so such prefixes are hardly necessary. The database idealist in me says that the system should be based around domains (abstract data types) anyway, so the low-level data type would basically be irrelevant as far as compatibility with different operators is concerned.
Once the system has been implemented, anyone needing to know the type of a column can easily query the data dictionary/system catalog to find this information. At the modelling stage, the types would normally also be readily available as part of the specification.
One good reason for not using the prefixes: it would make it difficult to perform queries on the data dictionary sorted by identifier, since the leading portion of the identifier is now really the type. In my opinion, the type is a distinct property from the identifier, and should therefore be stored separately.
我想说的是，我在一个匈牙利命名数据库上工作了多年......它基本上没问题，但多年来，一些数字前缀字段实际上包含字母数字，而一些布尔标志则不包含，还有一些varchars 已经变成了 clob，等等……无论如何，这足以代表年轻球员的一个重大陷阱。
我没有也不认为命名约定实际上有什么“错误”......它只是有点难以捉摸，开发人员可以应对......但我确实同意它增加的价值非常小......程序员通常都是非常聪明的人，记住数据库模式的数据类型实际上并不构成太大的挑战......特别是如果您长时间使用系统的话。
总而言之，我对匈牙利表示法持反对态度，但如果我继承了一个使用它的系统，并且创建了新表，我会遵循惯例……无论如何，这都不是我的错。
如果他们继续抱怨，请将它们发送给我。 我会给他们一些真正让他们生气的东西，比如 Java 程序中的 PascalCase，或者不大写的常量，只是举例;-)
顺便说一句：我还继承了命名控件的 VB 标准（以及仅控件）转换为 Java，因为它有意义，并且它提供了有用的信息； 它是如此广为人知和使用，以至于它成为了一种通用语言，即使它违背了 Java 编码标准。
我对编码标准的看法是：
干杯。 基思.
I was about to say that I worked on a Hungarian named database for years... it was mostly OK, but over the years some of the number prefixed fields actually contained alphanumerics, and some of the boolean flags wheren't, and a few of the varchars had become clobs, and so-on and so-on... enough to represent a significant trap for young players anyway.
I didn't and don't think there was actually anything "wrong" with the naming convention... it's just a bit infelxible, which developers can cope with... but I do agree that it adds very little value... programmers are generally pretty smart people, and memorising the datatypes of a db-schema doesn't actually present much of a challenge... especially if you work with a system for an extended period.
So all in all, I'd give Hungarian notation the thumbs down, but if I inherited a system which used it, and I created new tables, I would follow the convention... It's no skin off my nose either way.
If they keep whinging, Send them to me. I'll give them something real to get pissed-off about, like PascalCase in a Java program, or uncapitalized CONSTANTS, just for instance ;-)
As an aside: I've also carried over the VB-standard for naming controls (and controls only) into Java, because it makes sense, and it presents useful information; and it's so widely known and used that it serves as a lingua franca, even if it goes against the Java coding standards.
My ethos on coding standards:
Cheers. Keith.