Phil Factor’s most recent guest editorial over at SQL Server Central has, to a degree, pointed out that the emporer’s spiffy new outfit… well, it’s not exactly there. That’s why he looks so nekkid.
But seriously, the very idea of naming objects inside of the database with Hungarian-style notation really should end. Phil’s right. There’s absolutely no reason why you should name a unique index ixuTableName when UniqueTableName or TableNameUnique would do the job just as well and not be nearly as obscure. I confess to using this type of naming convention all the time, but I’m realizing that I don’t need it and it’s largely just habit.
There are possible exceptions, for instance you want to group all lookup tables in your database so you name them lkTableName, but why not LookupTableName? It’s a little more typing, but with typeahead available, for free, in Management Studio and excellent add-ons like Red Gate’s SQL Prompt, who types out the full name of any of the tables anyway?
I don’t know any developers that are using Hungarian notation in their code these days. Everyone is working with objects and dealing with them like columns in a database table as far as names go (yeah, I know people put Hungarian notation in column names too, but that’s pretty rare). Why keep doing that kind of thing in databases?
Go over, read Phil’s editorial, and the comments about it as well. See if you’re not on board with breaking this bad habit. No more tibbling!




Subscribe to this blog
Briefcase
Print
Posted by Jason Brimhall on 26 January 2010
Well put Grant. Thanks
Posted by Dugi on 26 January 2010
Yes, I vote for "No more tibbling!"
Posted by Grant Fritchey on 26 January 2010
Cool. Now we need a t-shirt.
Posted by Steve Jones on 26 January 2010
It is quite a debate and I tend to agree with you. Why do it in a database?
And we do need a t-shirt!
Posted by Jason Brimhall on 26 January 2010
T-shirt: I Quibble your Tibble!
Posted by edwisdahl on 27 January 2010
I agree with the idea that we shouldn't use hungarian notation in the database.
However, I still use a similar prefix in my SSIS packages as the engine uses generics for reporting and it is one of the easiest ways to identify task and transformation type through the log and / or error output.