Let's suppose there is a table called AIRPORT and I have to choose between two naming conventions:
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.
