My colleague Ola Bini recently wrote a post describing his thoughts on the syntax of programming languages and while the post in general is interesting the bit that most resonates with me at the moment is the following:
Typing fewer characters doesn’t actually optimize for writing either – the intuition behind that statement is quite easy: imagine you had to write a book. However, instead of writing it in English, you just wrote the gzipped version of the book directly. You would definitely have to type much less – but would that in any way help you write the book? No, probably it would make it harder. So typing I definitely don’t want to optimize.
On the application I’m currently working on we have a full time DBA on the team who favours a much more concise style of naming in tables than most developers would be used to.
We have an acronym for each table and if there’s a foreign key reference to a field in that table elsewhere then we’ll use the acronym as part of the column name in the other table.
For example if we had a reference to a table called Person then our foreign key column name might be per_id.
One of the problems we were trying to overcome is that from what I understand Oracle has a field name limit of 30 characters so we would eventually exceed that if our naming was too verbose.
By using acronyms we can keep a more consistent style of naming rather than having some names being spelt out fully and others being abbreviated.
The other argument used for the more concise naming convention is that it’s much quicker to type columns named in this way and we don’t have auto complete functionality available in sqlplus as we do in most IDEs.
The disadvantage of the approach is that it’s now very difficult to understand what data is being stored in a table just by looking at it – you need to first learn all the acronyms and then do the translations in your head.
If you’re working with the tables all day long then it becomes second nature but if your use of them is more sporadic it takes a bit longer.
We’re trying to keep interactions with the database reasonably minimal so hopefully we won’t need to do any really complex queries with joins in which would be truly difficult to understand when we come back to them!