January 25, 2010 at 2:48 pm
I think this was pointed at with a link, but I wanted to make it explicit.
Hungarian Notation was meant to be Functional, Not Descriptive.
"DECLARE intPoints as integer" is pointless. "DECLARE cntPoints as integer" is(can be) worthwhile, it tells you how the variable is used. Likewise it is pointless to name a table tblStudents, but perhaps useful to use relStudentsClasses (I say perhaps, because if you have tables Students, Classes, and StudentsClasses, it seems clear without the prefix). Similarly, if you have a large, modular application you might prefix objects with the module name (although I think that's what Schema is for).
For the developers searching the IDE for table names, consider this an argument for better naming overall. If you have a table named Users, you shouldn't have a column named users (because columns, for the most part, should be singular) and if you have a variable named Users that is not a load from the table Users, why? Also, consider using qualified names (e.g. dbo.Users) in your ad-hoc queries, you can search by that and it can prevent problems due to conflicting table names owned by users.
Overall, IMHO, Hungarian notation has a place, but database objects are not it.
--
JimFive
January 25, 2010 at 3:13 pm
I've been poring through books of ballads trying to find the source of the quotation 'we'll go no more a tibbling, though Witsuntide is nigh'. I must admit that it wasn't 'tibbling', and it was '... til witsuntide is nigh'. The trouble is that I've got a lot of books of traditional ballads. I wonder if we should make one up?
Best wishes,
Phil Factor
January 25, 2010 at 4:03 pm
Likewise it is pointless to name a table tblStudents, but perhaps useful to use relStudentsClasses (I say perhaps, because if you have tables Students, Classes, and StudentsClasses, it seems clear without the prefix).
I would say that it is not pointless from a developer's standpoint. Let's say you have a large enterprise application targeting students and you are considering changing the structure of the Students table. You want to search through your code to find out all the places that reference this table to check for possible problems before you make the structural change. If you search for "Students" you might end up with one million hits, possibly a mix of variables, Web-site text, code comments, other database objects that have "students" in the name, etc. A search list that long could take days to work through. If you use table prefixes and search for "tblStudents" you will quickly find all references of only the database tables, and very little else. In practice this saves hours of work in large applications/Web sites. Over the life of a project, this type of naming convention can save months of man-hours in maintenance, especially when you have a rotating staff of interns and consultants working on the project over many years.
I started out not using table name prefixes, but after years of consulting on numerous legacy Web sites and having to work with a variety of database designs, I observed how much easier it was to find all the database references in code when tables had tbl prefixes that I became a convert. That naming convention makes it easier for me, as a consultant, to determine the impact of upgrading the database structure. I've been brought in on a few projects where the other developers were overly hesitant to make any database changes because they didn't know how those changes would impact the Web site that makes use of the database.
January 25, 2010 at 10:38 pm
i am finding a relation over time between cross-experience and degree of closed mindedness, as well as amount of respect towards other people, or self-respect since it all starts within a person.
in the case where i had to tibbed, i was working on making a subset of a database for mobile use. the constraints are great. i suggest those who you think you know it all, then take the challenge to extend yourself to the mobile arena.
January 26, 2010 at 5:53 am
You missed the BIGGEST point, and BIGGEST failing about Hungarian notation.
Hungarian notation presumes that EVERY developer in the world types using Times New Roman font. I have programmed for over 30 years now and I have always used, and still use Arial font. Try reading Hungarian notation in Arial font - its useless.
The Hungarians should stick to goulash - Hungarian notation is the most tedious, useless, and foolish thing ever to affect programming.
January 26, 2010 at 6:07 am
WayneS (1/25/2010)
GSquared (1/25/2010)
Grant Fritchey (1/25/2010)
I think a lot of this, for me anyway, is just habit. Is there a good reason any more to put idx or ix at the beginning of index names? Nope. But I keep doing it because... I'm creating an index and as I type it, I put ix at the beginning. ...I used to use a three-letter code that indicated the type of index: IDX = default, CIX = clustered, UIX = unique, UCI = unique and clustered. Made it easy to see what's what at a glance. Later, I realized that I never actually used this feature for anything, and stopped bothering with it.
I think Gail mentioned about the only use for this... when examining execution plans.
Only the unique constraint on the index would be of use when looking at the execution plan. You can see if the index is clustered or not based on the operation.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
January 26, 2010 at 6:21 am
You want to search through your code to find out all the places that reference this table to check for possible problems before you make the structural change
I think this was addressed with:
consider using qualified names (e.g. dbo.Users) in your ad-hoc queries, you can search by that and it can prevent problems due to conflicting table names owned by users.
Ok, we can take the word ad-hoc out of that, but I will still argue that tblStudents is bad naming, if you want/need prefixes then functional prefixes such as: dataStudents, relStudentsClasses, lkupGenderCodes are much more useful. Encoding the type within the name is pointless, encoding the function can be useful. It may seem arbitrary to say that tblStudents is bad but dataStudents is ok, however, if all of your tables start with tbl you haven't added anything to your design. If you use appropriate functional prefixes for each of your tables you have at least been forced to considered the function of each item in your database.
--
JimFive
January 26, 2010 at 6:32 am
James Goodwin (1/26/2010)
You want to search through your code to find out all the places that reference this table to check for possible problems before you make the structural change
I think this was addressed with:
consider using qualified names (e.g. dbo.Users) in your ad-hoc queries, you can search by that and it can prevent problems due to conflicting table names owned by users.
Ok, we can take the word ad-hoc out of that, but I will still argue that tblStudents is bad naming, if you want/need prefixes then functional prefixes such as: dataStudents, relStudentsClasses, lkupGenderCodes are much more useful. Encoding the type within the name is pointless, encoding the function can be useful. It may seem arbitrary to say that tblStudents is bad but dataStudents is ok, however, if all of your tables start with tbl you haven't added anything to your design. If you use appropriate functional prefixes for each of your tables you have at least been forced to considered the function of each item in your database.
--
JimFive
The thing I don't like about that is that it destroys the ability to easily filter or scan the list of tables to find all the Student tables.
If every table related to Student data starts with "Students", then you can easily filter by that (or visually scan for that in the list), and you'll have them. "Students", "StudentsClasses", "StudentsAddresses", "StudentsPhones", "StudentsEmail", all group together nicely. "Students", "relStudentsClasses", "relStudentsAddresses", etc., don't.
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
January 26, 2010 at 6:50 am
Does synonym usage work in both tibbled and non-tibbled worlds? You know what it's doing by usage if you're looking at something that's using it... but you don't know what any single ones does in a list until you open it up? It's not though synonyms are broken down in Management Studio by object type.
Hey I am just curious! 😀
January 26, 2010 at 7:30 am
Grant Fritchey (1/26/2010)
Only the unique constraint on the index would be of use when looking at the execution plan.
And whether or not it's filtered
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
January 26, 2010 at 7:44 am
GSquared (1/26/2010)
James Goodwin (1/26/2010)
You want to search through your code to find out all the places that reference this table to check for possible problems before you make the structural change
I think this was addressed with:
consider using qualified names (e.g. dbo.Users) in your ad-hoc queries, you can search by that and it can prevent problems due to conflicting table names owned by users.
Ok, we can take the word ad-hoc out of that, but I will still argue that tblStudents is bad naming, if you want/need prefixes then functional prefixes such as: dataStudents, relStudentsClasses, lkupGenderCodes are much more useful. Encoding the type within the name is pointless, encoding the function can be useful. It may seem arbitrary to say that tblStudents is bad but dataStudents is ok, however, if all of your tables start with tbl you haven't added anything to your design. If you use appropriate functional prefixes for each of your tables you have at least been forced to considered the function of each item in your database.
--
JimFive
The thing I don't like about that is that it destroys the ability to easily filter or scan the list of tables to find all the Student tables.
If every table related to Student data starts with "Students", then you can easily filter by that (or visually scan for that in the list), and you'll have them. "Students", "StudentsClasses", "StudentsAddresses", "StudentsPhones", "StudentsEmail", all group together nicely. "Students", "relStudentsClasses", "relStudentsAddresses", etc., don't.
Actually, in SSMS (SQL 2005/2008), if you use the Filter capability in the ObjectExplorer and enter Student in the name you will get all og the above tables. I use the filter frequently when working PeopleSoft databases, but then they have 25,000 + tables. I also use it to filter on schema in our DWStage/DWODS databases to restrict what I look at.
January 26, 2010 at 8:02 am
GilaMonster (1/26/2010)
Grant Fritchey (1/26/2010)
Only the unique constraint on the index would be of use when looking at the execution plan.And whether or not it's filtered
Oh, true, didn't think about that one.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
January 26, 2010 at 8:56 am
"Students", "StudentsClasses", "StudentsAddresses", "StudentsPhones", "StudentsEmail", all group together nicely. "Students", "relStudentsClasses", "relStudentsAddresses", etc., don't.
I agree, and I don't use prefixes for database objects. What I was suggesting was that if someone wants to use prefixes then a functional prefix is more useful than a declarative prefix.
I find it interesting that the most cited reason for prefixes is searching through the project to find references. It seems to me that if this is the problem then encapsulation is a better answer than naming conventions.
--
JimFive
January 26, 2010 at 10:47 am
I find it interesting that the most cited reason for prefixes is searching through the project to find references. It seems to me that if this is the problem then encapsulation is a better answer than naming conventions.
Encapsulation would not be a solution to the issue, especially since many Web programming languages aren't OOP languages. Even on Web sites that use OOP, database queries can be found anywhere in the site.
I use the dbo prefix when writing queries, but even I forget to add it occasionally and I don't know of any IDE that enforces its use. I wouldn't rely on an optional prefix to find database queries in a Web site or application. In contrast, the name of the table is essential to the query, so it is guaranteed to be present and searchable.
January 26, 2010 at 10:55 am
Actually, in SSMS (SQL 2005/2008), if you use the Filter capability in the ObjectExplorer and enter Student in the name you will get all of the above tables. I use the filter frequently when working PeopleSoft databases, but then they have 25,000 + tables. I also use it to filter on schema in our DWStage/DWODS databases to restrict what I look at.
It would be nice is SSMS supported user-defined folders and color labels, or possibly stars or colored flags to allow for alternate ways of organizing tables.
Viewing 15 posts - 61 through 75 (of 77 total)
You must be logged in to reply to this topic. Login to reply