SQL Server 表中列的最佳命名
您会选择以下三个选项中的哪一个作为 SQL Server 表中的列名，为什么？
- YearToDateWages
- YTDWages
- YtdWages
跟进：
- SSN
- Ssn
- SocialSecurityNumber
Which of the following three options would you choose for a column name in a SQL Server table, and why?
- YearToDateWages
- YTDWages
- YtdWages
Follow up:
- SSN
- Ssn
- SocialSecurityNumber
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
对于第一个，我会使用，
因为 YTD 是工资的修正值。
对于第二个，
我从不在数据库字段或表名称中使用驼峰命名法，并且 Ssn 不是真正的单词，也不是有效的缩写。
For the first one, I would use
because YTD is a modifier on Wages.
For the second one,
I never use camelCase in database field or table names, and Ssn is not a real word, nor is it a valid abbreviation.
我建议使用或多或少与命名类相同的规则。如果缩写是常识（例如
SSN或YTD），则缩写，但如果缩写代表的含义并不完全明显，则将其拼写出来。是否使用大写字母或使用 PascalCase 取决于个人喜好。
编辑：根据其他答案，也许
YTD并不像我想象的那么出名。如果它是在金融或交易应用程序中，那么您可能使用缩写版本是安全的；时刻留意你的听众。I'd suggest using more or less the same rules as naming classes. If the abbreviation is common knowledge (such as
SSNorYTD) then abbreviate, but if it's not totally obvious what the abbreviation would stand for, then spell it out.Whether you write it in uppercase or use PascalCase is a matter of personal preference.
Edit: Based on other answers, perhaps
YTDisn't as well-known as I thought. If it's in a financial or trading app then you're probably safe with the abbreviated version; always be mindful of your audience.查看ISO-11179 命名约定 特别是第 5 部分
第 5 部分：命名和识别原则，为识别管理项目提供了指导。识别是一个广泛的术语，用于指定或识别特定的数据项。取决于标识符的使用，可以以多种方式完成识别。识别包括分配对人类没有固有意义的数字标识符；图标（已赋予含义的图形符号）；具有嵌入含义的名称，通常用于人类理解，与数据项的定义和值域相关联。
Take a look at the ISO-11179 Naming Conventions specifically part 5
Part 5: Naming and Identification Principles, provides guidance for the identification of administered items. Identification is a broad term for designating, or identifying, a particular data item. Identification can be accomplished in various ways, depending upon the use of the identifier. Identification includes the assignment of numerical identifiers that have no inherent meanings to humans; icons (graphic symbols to which meaning has been assigned); and names with embedded meaning, usually for human understanding, that are associated with the data item’s definition and value domain.
这取决于缩写的知名度。我的经验法则是我在谈话中所说的话。所以我会写出“YearToDate”，但保留“Ssn”缩写。
It depends on how well-known the abbreviation is. My rule of thumb is what I'd say in a conversation. So I would write out "YearToDate", but keep "Ssn" abbreviated.
我认为这取决于应用程序/数据库的维护范围。如果您是唯一一个从原始角度或应用程序代码角度查看数据库的人，那么您可能应该将其命名为对您来说最有意义的名称。我经常用下划线命名 SQL 字段，将数据类型与其修饰符分开，因此
wages_ytd和user_ssn就足够了。然而，我们很少能预测未来，你永远不知道你的小应用程序什么时候会被其他人开发。因此，在任何情况中，您都不应该以神秘的方式或以其他人无法理解的方式命名变量。那，我有时会回到我的旧程序并思考，“那个变量是什么？？”如果您遇到过这种情况，那么您的名字还不够冗长。
我缩写或使用较短变量名的通常原因是，如果我厌倦了重复键入或引用它（智能感知有帮助，但它并不总是可用），或者如果我的代码在整个宽屏显示器上乱写乱画，并且我遇到了麻烦因为冗长的变量名称，例如
DiagnosticsWidgetFailureCount.SpecificWidgetProperty.FilterBySomeOption。I think this depends on the maintenance scope of the application/database. If you're the only one who will ever see the database from a raw standpoint or the application code, you should probably name it what makes the most sense to you. I often name SQL fields with underscores separating the data type from its modifier, thus
wages_ytdanduser_ssnwould suffice.However, rarely can we predict the future, and you never know when your small app will wind up being worked on by others. In no case should you ever name variables cryptically or in a way that nobody else would figure out, for that reason. That, and I've come back to my old programs sometimes and thought, "What is that variable??" If that ever happens to you, your names aren't verbose enough.
The usual reason I abbreviate or use shorter variable names is if I get tired of repeatedly typing or referring to it (Intellisense helps but it's not always available), or if my code is scrawling across the entire widescreen monitor and I am having trouble because of long verbose variable names, like
DiagnosticsWidgetFailureCount.SpecificWidgetProperty.FilterBySomeOption.如果您手动写出查询，那么越短越好。在使用 SocialSecurityNumber 重复多次编写一些查询后（例如，在选择列表中、一些连接子句、where 子句和 order by 子句），那么较短的查询看起来会好得多。
缩写在大小写一致的情况下最容易阅读，例如 SSN，并且当名词在前时，例如 WagesYTD。如果您有与工资相关的其他字段（例如 WagesOvertime），则尤其如此。）
If you're writing out the queries by hand, then shorter is better. After writing a few queries with SocialSecurityNumber repeated a number of times (e.g. in the select list, a few join clauses, a where clause and and the order by clause) then shorter will seem much better.
Abbreviations are easiest to read with consistent case, e.g. SSN, and when the noun comes first, e.g. WagesYTD. This is particularly true if you have other fields relating to Wages, e.g. WagesOvertime.)