To me, this has pitfalls similar to Hungarian naming - too often you run into situations where the name doesnt fit but you're stuck with it
Hungarian notation does have severe limitations in database word, as pointed out in an execellent article somewhere on SQLServerCentra.com. However, I don't see that these problems are also inherent in this method.
The main problem with hungarian notation is that if you change the datatype of a column, you have to change the name of that column - and the odds of doing that once the database is in use is very slim indeed. However, the only time you need to change the name of a column using this method is when the column moves from one table to another table - and when that happes, you have a lot of other maintenance work to do anyway. Chaning the name isn't that much of a deal, since you have to re-visit every piece of code or script that accesses that part of the database anyway.
, or you end up violating the convention for a 'special case'.
Well, that's a matter of discipline. I find that with experience, developers get more disciplined. No method will work well if you don't practice discipline, but perhaps a strict method will suffer more.
I can see where it might boost productivity in some cases - do you find that it does so enough to offset the increased time/effort it takes to enforce the convention?
Oh, yes, certainly. Whenever I get called on to work on a system where the method is not used, I find I miss it dearly. Maybe that's because I'm so used to it, it's hard to tell, but I find great benefits.
Thanks for writing the article, good to get some different points of view on here! Hope we see more stuff from you in the future.
Thanks, and thanks for the feedback! That's what makes it worth the effort. Thanks also to Steve Jones for his feedback, and Brian for inspiring me to write the article 😉
Edited by - mattias on 12/15/2001 04:56:50 AM