Database column naming

Let's suppose 开发者_C百科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?

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.

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.)

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.CODE and OTHERTABLE.CODE to remove ambiguity

If you use WITH SCHEMABINDING (SQL server at least) you have to qualify column names

So, you'd end up with AIRPORT.AP_CODE if you used column prefixes

As 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.