Naming conventions in database design

Often I see databases that are designed with stupid naming convention. Why is it so hard to think for a second and then do it right. I also would like to say that this is just my opinion on this. But for me this seems so, well, obvious.

The weird part in this is that it’s so common to see databases designed in a way that the table name is again used as prefix in field name. I mean, what resons there might be to put Products.Product_name in there. The same could be named just and it works just as good.

Whenever I bring that up I get arguments like “it’s easier to distinquish between tables” or “the names will collide in queries”. Let’s try that.

SELECT, Products.type, Prices.amount
FROM Products, Prices
WHERE Prices.product =;

I know you are all saying “You could just shorten the names of the tables with ‘Products AS P and Prices AS R’”. But my point comes from this next one:

SELECT Products.Product_name, Products.Product_type, Prices.Price_amount
FROM Products, Prices
WHERE Prices.Product_id = Product.Product_id;

Now, this is rather long and proofs my point. I could have used the shorter version of the table names in the first example. And similarly in the last one. If I use the shorter version in the last example I get almost same lenght to the names as in first. But if I use short names in the first I get easy to read queries and they are short. But I can’t do anything to long field names in the last example.

Small detail but this just gets me every time I see this. I can’t come up with any reasonable explanation why I should use overly long names and repeat the table name again in field name.

Isn’t it the whole point behind databases that same information could be only once in the database. There are reasons when same information can be multiple times in same database, but only with good reason.


2011-01-02 15:52 Re-published from old website