Question

We put common prefixes on related tables to assure they display next to each other in our DB management software (Toad, Enterprise Manager, etc).

So for example, all user tables start with the word User:

• User
• UserEvent
• UserPurchase

Ideally, in honor of the three great virtues of a programmer these tables should be named User, Event, Purchase respectively to save some typing, agreed?

Is this naming convention the best (only?) practice for grouping related tables together naturally?

Answer 1

I tend to go against the grain in naming conventions on two counts here…

1. I don’t like using prefixes so that things group together in a given UI. To me the tables should be named such that in code they are easily readable and make sense. There have been numerous studies (mostly ignored by programmers) that show that things like using underscores, logical names, eliminating abbreviations, and eliminating things like prefixes have a very big impact on both comprehension and the speed of working with code. Also, if you use prefixes to break down tables what do you do when a table is used by multiple areas – or even worse it starts out in only one area but later starts to be used in another area. Do you now have to rename the table?

2. I almost completely ignore name lengths. I’m much more concerned about readability and understandability than I am about taking 1/10th of a second longer to type a column or table name. When you also keep in mind all of the time wasted trying to remember if you abbreviated ‘number’ as ‘no’, ‘num’ or ‘nbr’ and keep in mind the use of things like Intellisense, using longer, more meaningful names is a no brainer to me.

With those things in mind, if your UserEvents table really has to do with events related to a user then that name makes perfect sense. Using just Events would end up giving you a poorly named table because the name isn’t clear enough in my opinion.

Hope this helps!