A Call to Arms

Home / SQL Server 2005 / A Call to Arms

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!


  • Jon Crawford

    Curious if you read/your comments on the link in discussion to joelonsoftware? Looked like a good reason for hungarian notation to exist, but I still don’t know that it should live in a db.

  • scarydba

    Yeah, there is some argument there. Same thing with naming indexes iuMyIndex or icMyIndex or icuMyIndex, all of which will be an Index (i), Unique (u) and/or Clustered (c). So from the index name, you can see if the index is unique or not, clustered or not, etc. But the fact of the matter is, usually, when you’re examining indexes, you want to see the index. Then you’ll be seeing CREATE INDEX….CLUSTERED or whatever… so, why the naming convention?

  • I kind of agree and I kind of don’t – I have done the tbl thing quite a lot, but I never leave it as tbl. I usually have some three letter extension that denotes the table’s functional group (can you tell I’m in a habit from before schemas existed? 🙂 ). So in our website DB, configuration tables are prefixed tblCfg, log tables are prefixed tblLog. Ok, so you could drop those – but, while I agree the point that Phil makes is valid, he seems to miss the point that actually a naming convention is *hugely* useful when working in a team. So, perhaps, we should revisit our website DB, and create a schema called Config, and have Config.Contacts instead of tblCfgContacts. But, I really don’t think it would be useful to have no convention at all – i.e. I really wouldn’t like to see an index called ‘Contacts’. I would rather get the hint as to what something is *before* I have to script it to find out… Good discussion point though…

OK, fine, but what do you think?