December 9, 2001 at 12:00 am
Comments posted to this topic are about the content posted at http://www.sqlservercentral.com/columnists/MFagerlund/datastandards.asp
December 14, 2001 at 10:04 am
Interesting article. You have some good ideas, but I'm not sure of their benefits. The large prefixes can create some confusion, especially with developers accessing the tables. For DBAs, I think this will help greatly, but for a large development team, especially one with new developers, this might become very confusion.
One other note, the use of Underscores seems to swing in and out of favor. With the release of .NET, they are out of favor and SQL is supposed to be moving in that direction.
Nice article and well written.
Steve Jones
December 14, 2001 at 9:51 pm
Hey Mattias,
I found it interesting as well, though I guess I'm going to fall into the opposition camp on this one! 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, or you end up violating the convention for a 'special case'.
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?
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.
Andy
December 15, 2001 at 4:47 am
quote:
but for a large development team, especially one with new developers, this might become very confusion.
Well, I've used the method with medium sized development teams (5 to 6 people), and it didn't cause a lot of cunfusion, that I can recall. I found that it was usually beneficial to new developers, because once they understood the module system, they could navigate the database much easier. Then again, most everything is confusing to the unexerienced developer.
quote:
One other note, the use of Underscores seems to swing in and out of favor. With the release of .NET, they are out of favor and SQL is supposed to be moving in that direction.
I personally find it easier to read with the underscores than it is without them. I guess it's a matter of taste.
quote:
Nice article and well written.
Thank you!
m
December 15, 2001 at 4:55 am
quote:
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.
quote:
, 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.
quote:
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 😉
mattias
Edited by - mattias on 12/15/2001 04:56:50 AM
December 17, 2001 at 3:38 am
Nice, clear article - I think if I come across this type of system in the future I'll easily recognise it now. Not sure that I would choose to implement it on small/medium sized dbs, but on dbs with a massive number of tables i can see it could be a useful way of administering a modularised structure.
My question regards foreign keys: what if two tables have a foriegn key to the same field on a third table - how is this column then named?
Second question is to Steve: saw in your question that there is an issue with underscores and .NET - am not really familiar with .NET yet, so could you explain this a bit for me.
Paul Ibison
Paul Ibison
Paul.Ibison@replicationanswers.com
December 17, 2001 at 6:13 am
quote:
My question regards foreign keys: what if two tables have a foriegn key to the same field on a third table - how is this column then named?
I'm not quite sure I unserstand you here, but; Foreign keys are always named using their "domestic" name - the name they have in their home table.
If table T0201_AGENT and T0301_DEPARTMENT both have foreign keys that refer to the table T0101_CONTACT, then both (foreign key) columns would be named T0101_CONTACT_ID. Since they're on separate tables, it shouldn't pose a problem.
Hope that answered your question, if it didn't, please elaborate, and I'll give it another shot.
m
Edited by - mattias on 12/17/2001 06:15:53 AM
December 17, 2001 at 8:20 am
.NET is the new direction for all MS apps, supposedly T-SQL. This will mean that T-SQL will support inheritence, encapsultion, etc. Not sure how that will work, but supposedly T-SQL will become a .NET server and you will be able to code in any .NET languange inside SQL. Again, I can't really imagine how this will work, but that's what I've heard from a few peoplea t MS.
In terms of underscores, you can use them, but MS is recommending you do not for .NTE languages (VB.NET, c#.net).
Steve Jones
December 18, 2001 at 5:09 am
Thanks for the answers guys.
Steve: the direction you mention for TSQl sounds exciting, although presumably it'll be a couple of years before this comes about.
Mattias: my FK question really concerns a column on a table which is a foreign key in more than one instance. It may be a foreign key on it's own to table A and part of a combined FK to table B. Admittedly this is a slightly unusual situation, but how would the naming cope with this? (another such problematic 'exception' would be self-joins).
Paul Ibison
Paul Ibison
Paul.Ibison@replicationanswers.com
December 21, 2001 at 2:20 pm
quote:
Mattias: my FK question really concerns a column on a table which is a foreign key in more than one instance. It may be a foreign key on it's own to table A and part of a combined FK to table B. Admittedly this is a slightly unusual situation, but how would the naming cope with this?
Well, if it's a partial foreign key, that is, one of several columns that together form a foreign key, then each column would be named as the coresponding columns are named in the "mother" table.
quote:
(another such problematic 'exception' would be self-joins).
In the case of a self-join, I add a descriptive text to the name, after the regular column name. If T0101_CONTACT has a reference to a "mother" and a "father", these columns would be named T0101_CONTACT_mother and T0101_CONTACT_father.
This _is_ a problem, no doubt, but the problem isn't considerably smaller with any other method. The one reason it may be a slighly bigger problem using the strict conventions is that you really expect the column to have a specific name - but it doesn't, because that would cause several columns with the same name. Using no naming conventions, that particular problem doesn't occur, because you simply don't know what the name of the field would be, unless you looked it up.
m
Edited by - mattias on 12/21/2001 2:22:01 PM
May 26, 2002 at 7:28 am
Thank you for taking the time to share your information. I am a student and need all the info I can get. Your points of interests were clear and to the point, no fancy mumbo jumbo...It clarified some areas of trouble for me. Thanks!
Kim
Viewing 11 posts - 1 through 10 (of 10 total)
You must be logged in to reply to this topic. Login to reply