数据库列命名
假设有一个名为 AIRPORT 的表，我必须在两种命名约定之间进行选择：
- 将属性命名为 AP_CODE、AP_NAME 等，
- 或者将它们命名为 CODE、NAME
问题是它是否更高效 em> 遵循第一种方式还是使用同义词（即 AP）和引用属性（例如 AP.CODE）？
Let's suppose there is a table called AIRPORT and I have to choose between two naming conventions:
- to name attributes like AP_CODE, AP_NAME and so on
- or to name them just like CODE, NAME
The question is whether it is more efficient to follow the first way or to use synonym (i.e. AP) and reference attributes like AP.CODE?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
在任何常用的 RBDMS 中，它都不可能对性能产生任何重大影响。选择将基于可读性和个人风格偏好。我建议不要使用前缀，因为它通常只是人们训练自己排除的噪音。
It's not likely to have any significant performance impact either way in any RBDMS in common use. The choice would be based on readability and personal style preference. I would advise against the prefixing as it's usually just noise that people train themselves to tune out anyway.
其实没有什么区别，所以选择清晰度。我最近一直在使用 Oracle，它有 32 个字符的名称长度限制，因此我尝试避免在属性上使用表名前缀，而是使用表别名。 （这也使得更改表名称变得更容易。）
There's really no difference, so opt for clarity. I've recently been using Oracle, which has something like a 32 character name length limit, so I try to avoid the table name prefix on attributes and instead use the table aliases. (This also makes it a bit easier to change your table names.)
我只使用代码和名称。就我个人而言，我认为这很笨拙，而且没有任何好处。
如果您在其他表中有 CODE 和 NAME，则必须指定
AIRPORT.CODE和OTHERTABLE.CODE以消除歧义如果您使用
WITH SCHEMABINDING（至少 SQL Server）你必须限定列名因此，如果你使用列前缀，你最终会得到
AIRPORT.AP_CODE作为一个类比，如果你考虑 OO 对象属性，你没有给它们加上前缀，是吗...？
准确地说，效率绝对没有提高。
I'd just use CODE and NAME. Personally, I think it's simply clumsy and adds no benefit at all.
If you have have CODE and NAME in other tables, then you'd have to specify
AIRPORT.CODEandOTHERTABLE.CODEto remove ambiguityIf you use
WITH SCHEMABINDING(SQL server at least) you have to qualify column namesSo, you'd end up with
AIRPORT.AP_CODEif you used column prefixesAs an analogy if you think about an OO object properties, you don't prefix them, do you...?
To answer exactly, there is absolutely no efficiency gain.