我已经开发数据库解决方案超过 11 年了，似乎我已经“开发”了一个关于命名表中列的相当有争议的观点：我总是给它们一个 3 或 4 个字符的类型前缀，即 intGroupID， nvcTitle、dtmCreated、bitPlayerHater 等。我曾与其他几位开发人员合作过，他们都绝对鄙视老式的前缀约定。
（是的，我知道，我在这里没有发明任何东西，我只是拒绝放弃：）
我的主要理由是，当我的开发人员同事尝试理解数据结构时，为他们提供尽可能多的信息。了解列的类型可以立即让您（或至少是我）对正在处理的内容有更好的心理印象。与使用 C# 或 VB.NET 相比，在编写查询时，IDE 通常无法提供相同的智能感知支持。
到目前为止，没有人能够提出致命的论点来改变我对这个特定话题的看法。我还有其他一些同样有争议的命名约定，它们可以提高清晰度，但列前缀似乎会激怒更多的人。
为什么给数据库列添加前缀被认为是一种不好的做法？
它的名字叫“匈牙利表示法 http://en.wikipedia.org/wiki/Hungarian_notation".
作为一名开发人员（和数据架构师），我发现它毫无价值。它没有提供太多信息。
-
它仅提供对部分类型信息的快速、不准确的注释。例如，它省略了长度。
在更复杂的数据库环境中，对象是 BLOB，它根本不提供有关 Blob 中对象类型的信息。
它使更改数据类型变得痛苦。
有必要记住一个晦涩的前缀。是吗vcName, strName or uniName?
SQL 自动处理类型转换，使得繁琐的特定于类型的命名在很大程度上变得无关紧要。
最重要的是：它没有提供任何有用的文档meaning的数据。我的经验是，人们几乎总是会歪曲含义。他们很少（如果有的话）对它是 int 还是 string 感到困惑；当他们想知道时，他们只是使用 TOAD 或其他给出实际类型的工具来描述该表，而不是预期类型的部分摘要。
[虽然说它几乎没有用，但我意识到这可能不是您正在寻找的“杀手级论点”。如果您可以用您认为匈牙利表示法的价值的实际原因逐点更新您的问题，那么这将会有所帮助，因此可以逐点解决它们。]
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
