数据库列类型前缀

它叫做“ Hungarian Notation “。

作为开发人员(和数据架构师),我发现它毫无价值。它提供的信息不多。

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

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

2. 这会使更改数据类型变得很痛苦。

3. 有必要记住一个模糊的前缀。它是 vcName , strName 或 uniName ?

4. SQL自动处理类型转换,使得繁琐的特定类型命名在很大程度上不相关。

5. 最重要的是:它没有提供关于 意思 数据。我的经验是,人们几乎总是腐败的意思。他们很少(如果有的话)混淆它是int还是string;当他们想知道的时候,他们只是使用toad或其他提供实际类型的工具来描述表,而不是使用预期类型的部分摘要。

[说了这几乎是无用的,我意识到这可能不是你要找的“杀手论据”。如果你能用你认为匈牙利符号的价值所在的实际原因逐点地更新你的问题,这样它们就可以被逐点地解决。]

我已经更改了几次列类型。例如A code 从 number 到 string . 如果没有前缀,我可以在不重新编码的情况下完成这项工作,大多数情况下,所有应用程序仍将运行(至少在Oracle中)。用你的方法我需要改变 intCode 到 strCode 我百分之百肯定我需要用这个字段重做我的所有代码!

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

有些人还用表缩写(例如 department.dep_code )。我发现很难用它来编码,因为我往往忘记了缩写。一个有50个表的系统往往会得到非常相似的前缀。使用它的原因是当员工加入部门时,“部门代码”字段是唯一的字段( emp_code 和 dep_code )我不认为它会增加值,因为使用表别名可以更容易地做到这一点,而表别名不会强制您使用前缀。

我在客户机代码中经常使用前缀作为GUI组件的前缀。例如。 sle 对于单行编辑 hungarian notation 对于C和PowerBuilder。当移动到Java时,我停止使用它。我想我对变量使用了更清楚的名称。然而,转向面向对象的语言是,一切都是一个对象,使用它有点愚蠢 objVariable 到处都是。

我不键入前缀列名称的最大原因是,当我必须记住(然后键入)列的前缀而不是只键入逻辑名称(如firstname而不是strfirstname)时,它有一种趋势,即使键入查询的过程更长。

通常,您或那些处理您的数据的人应该知道您的数据的基础。由于查询不是强制执行的真正强类型,因此可以参数化任何查询。您的第一次测试查询要么有效,要么失败。修好它,然后继续。

至于在VisualIDE中工作,我看到过许多商店不强制使用通用约定来命名对象(文本框、组合框等)。由于我以前做过的很多事情都是动态生成、链接、绑定的,所以我在控件上使用了这样的前缀,如txtfirstname、btnok、cPostatelist等。然后,我去掉前3个字符,并在运行时将字段名(如果适用)自动绑定到数据对象。但是,如前所述,表中列名称的前缀可能导致的问题比它所能帮助的更多。

只是我的美元价值(从2美分起通货膨胀)

问题出在所谓的应用匈牙利符号和系统匈牙利符号之间。前者增加了关于 友善的 您拥有的数据(例如 dx 可能意味着“来自左边框的像素数”),而后者添加了有关 类型 您拥有的数据(例如 bit 意味着 一点 )

对于当前的编程环境和方法,您不必查找 类型 你正在处理的变量。IDE和编译器会告诉你是否错了。因此,这本质上是冗余数据,当您开始(自动)从这些名称生成源时,这些数据就开始进入您的方式:

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

阅读乔尔的文章 Making Wrong Code Look Wrong . 尤其是“I_M匈牙利”部分。

另外,如果您必须更改数据类型(这种情况比您想象的要多——我们刚移动到Unicode),您必须在代码中更改所有的列名。(顺便说一句,这是件坏事!)-)

根据我的经验,数据库系统非常擅长执行操作的类型安全性,因此几乎不需要这样的前缀。我的数据库理想主义者说,无论如何,系统应该基于域(抽象数据类型),因此,就与不同运算符的兼容性而言,低级数据类型基本上是不相关的。

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

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

我正要说,我在一个匈牙利名字的数据库里工作了好几年…这基本上是可以的,但多年来,一些数字前缀字段实际上包含字母数字,以及一些布尔标记(如果没有),以及一些varchar变为clobs等等…足以代表年轻球员的一个重要陷阱。

我没有也不认为命名规则实际上有什么“错误”的地方…这只是有点不可行,开发人员可以应付…但我确实同意,它所增加的价值很小…程序员通常都是很聪明的人,记住数据库模式的数据类型实际上并不是什么挑战…尤其是如果你在一个系统上工作了很长一段时间。

总之,我会对匈牙利符号竖起大拇指,但是如果我继承了一个使用它的系统,并且创建了新的表,我会遵循惯例…我鼻子上也没有皮。

如果他们不停地抱怨,就把他们寄给我。我会给他们一些真正让人恼火的东西,比如PascalCase在Java程序中,或者没有资本化的常数,例如,

顺便说一句,我还继承了VB标准,将控件(和控件)命名为Java,因为它是有意义的,并且它提供了有用的信息;并且它被广泛地知道和使用,即使它违背Java编码标准,它也可以作为一种语言弗兰卡。

我对编码标准的看法:

• 做任何有用的事。
• 阅读并理解至少一个已发布的标准,但不要教条主义地遵循它。参见第1点。
• 在罗马的时候…一致性是使其“保持一致”的关键。参见第1点。

干杯。基思。