Worst Practices - Part 1 of a Very Long Series!
-
Definitely. I use usp_ in general, usp_dba_ for my stuff that I prefer no else use/touch. Other ideas on this?
Andy
-
I agree to the article for the case of column Names... but i am still happy with the Hungarian Notation(HN) being a BP for the case of programing. Being a VC%2b%2b programmer for quite sometime I am comfortable with the HN as it solves me lots of problems...especially for the scope case and also when the declaration is inside a class. As far as the column names go...I strongly go with the article...it's not a good idea for having Column Names in HN...this would add to the confusion. Column Names should be decide based on the business logic and not on Programmer Friendliness. If the latter happens... I would say that's a poor design.
PS: Please bear with my spelling/grammer mistakes...I am not that good in English.
~*~~*~~*~~*~~*~~*~~*~~*~~*~~*~~*~~*~~*~~*~~*~~*~~*~~*~~*~~*~
It's the music that matters for a soulful experience... not the instrument.
~*~~*~~*~~*~~*~~*~~*~~*~~*~~*~~*~~*~~*~~*~~*~~*~~*~~*~~*~~*~ -
Dont worry about the spelling my friend - at least you HAVE a second language, more than I can claim:-)
Andy
-
Ideally you have some kind of naming convention. Since ideals seem to rarely happen, I think "Something" would be ok as a column name. A good column name is descriptive without being overly long - I'd say between 3 and 12 characters. The best you can do is be consistent, don't mix styles, such as 'some_thing' in one table and 'somethingelse' in another. When I use my column names in code, I want the column name to be self describing so that someone doing maintenance work on the code can quickly and easily see what I am doing. I also prefer mixed case object names - SomeThing rather than SOMETHING.
Consistency is the BP.
Andy
-
I think that you have to keep the current implementation of databases, must of us do not start a new implementation, if you do it,is ok. The user do not have to see complicated names in yours columns as we know. No one is going to change an aplication and columns name because the notation is not as BP or WP.
Jose Galan
-
Exactly - thats why you shouldnt use it to start with!
Andy
-
This is a great way to visualise every ones BP and to avoid one WP.
Some steps that may be of help. I dont do a tbl_ for table definitons, When you look at the enterprise mgr, they are grouped, but most of the time i follow the business logic.
Meaning, if the tables are related to Funding then they would be Fund_, related to salary then Sal_ and like wise, if multiple apps use the same database the like if Compensation uses it we say Comp_, and if market analysis uses we say MA_.
For Views we use vwRPT, for views used for reports, vwComp for views used for Compensatoin Tool etc.
Some WP are if you do a lot of maintanence by writing adhoc queris, always have them saved some where with proper naming that you may understand. Belive me it saves a lot of time. One thing is you dont have to re-think twice before you run the query.
-
As a fan of naming conventions in general, I use a modified Hungarian Notation on all objects and columns in my databases. I have found that on the few occasions that a name change was required, the extra work of renaming the column ends up being a very small part of the revisions that I am having to make in the business rules that caused the name change in the first place. I find that what I gain by not having to look up the data type of every column I use far outweighs any time I have to spend changing a column name.
A case that you did not present is this:
What is the data type of @ModelNumber???
I have had it be everything from a smallint to a varchar(50). I use @intModelNumber (not @Si***) and @strModelNumber to distinguish.
I guess this is an issue of personal preference that will go on far beyond this discussion.
-
I dont mind the local variables as much, I tend to do much the same as you suggest - a holdover from coding in VB for me. Changing local variables is reasonably easy compared to changing a column name.
If having the data type is good, wouldnt including the length be better...@strSomeStuff_50 or something like that?:-)
Andy
-
quote:
Did they give a reason why (for not using Hungarian)?Hi Warren. According to MS, HN is discouraged in .NET since "In the Microsoft Visual Studio .NET environment, the type information about a field or variable is readily available by moving the mouse over the field name in the code editor." It's either MS thinks that programmers don't even document the objects they're using in their programs or they're just advertising one of the features of their IDE. Another one is the change-the-type-forget-to-rename .
I agree with Warren about HG. I was once an advocate of that but later I found out that I always missed to modify the prefix of one or two of the instances of that particular column which just had its type change. I have difficulty with my transition to .Net since I am used to the Hungarian guidelines MS itself ADVOCATED in VB6!
Some of the conventions I use
stored proc ---- up_MyStoredProc Camel
table ---- MyTable Pascal
view ---- MyView Someone told me to disguise views as table. Any comment?
default constraint ---- dflt_ColumnAIsZero
check constraint ---- chk_ColumnAGreaterThan12
index ---- ix_TableName, ix_TableName_ColAColB (in case more than one index in a table. Is this a good practice?)
trigger ---- undecided Suggestions?
parameter ---- @parameterName Camel
column ---- myColumn Camel
I think my adaptation of Camel notation is influenced by .NET. In .NET, any field (local in scope) should adapt camel casing. I just liken a VB.NET or C# member or field to a T-SQL column. 🙂
"The way to get things done is not to mind who gets the credit for doing them." - Benjamin Howett -
quote:
Did they give a reason why (for not using Hungarian)?Hi Warren. According to MS, HN is discouraged in .NET since "In the Microsoft Visual Studio .NET environment, the type information about a field or variable is readily available by moving the mouse over the field name in the code editor." It's either MS thinks that programmers don't even document the objects they're using in their programs or they're just advertising one of the features of their IDE. Another one is the change-the-type-forget-to-rename .
I agree with Warren about HG. I was once an advocate of that but later I found out that I always missed to modify the prefix of one or two of the instances of that particular column which just had its type change. I have difficulty with my transition to .Net since I am used to the Hungarian guidelines MS itself ADVOCATED in VB6!
Some of the conventions I use
stored proc ---- up_MyStoredProc Camel
table ---- MyTable Pascal
view ---- MyView Someone told me to disguise views as table. Any comment?
default constraint ---- dflt_ColumnAIsZero
check constraint ---- chk_ColumnAGreaterThan12
index ---- ix_TableName, ix_TableName_ColAColB (in case more than one index in a table. Is this a good practice?)
trigger ---- undecided Suggestions?
parameter ---- @parameterName Camel
column ---- myColumn Camel
I think my adaptation of Camel notation is influenced by .NET. In .NET, any field (local in scope) should adapt camel casing. I just liken a VB.NET or C# member or field to a T-SQL column. 🙂
"The way to get things done is not to mind who gets the credit for doing them." - Benjamin Howett -
Andy, thanks for that interesting article. I totally agree with you, that it is a bad idea to preceed column names with their data type.
I would like to share what helps me a lot in writing complex SQL-code:
I define a Three-Character-code for each table. Let's say I have a table called tblEmployees, to code would be EMPL. For table tblSales it would be SLS.
Then I preceed each column with that code and separate it from the actual column name with an underscore like this:
EMP_ID, EMP_Name, SLS_QTY and so on.
That way I alway know, from what table any specific piece of data comes from.
There is one exception to the rule: foreign key columns keep their name. For instance, if tblSales had a foreign key column pointing to the employee table, it still would be named EMP_ID, although it is in tblSales. That way, I always know, where the foreign key comes from.
If a column ever needs to be renamed, I can use Find-And-Replace tools and be pretty sure, that they do not replace anything I didn't mean to replace.
Edited by - broesi on 09/12/2002 01:48:32 AM
-
This article is a good start.
There are even better reasons not to use Hungarian Notation. I don't care about the data type of a column often enough. I create a table once, then I care about the type. When selecting from a table into another, if you are going into differently named columns, the data type is not an issue, its getting columns into the correct destination. If you are creating a table with select, you don't care about the datatype.
When writing t-sql, I might care about data type when declaring a temporary variable. But I do not need a crutch telling me the data type, any good development environment will give it to you. I write procs using Query Analyzer and I'm browsing the object browser to get columns names, so data type is at hand.
The cost of wordiness exceeds the usefulness of the information.
Now would you write about prefixing column names with an abbreviation for the table, or prefixing object names with the object type? I am against both of these practice for the same reason I dislike Hungarian Notation.
Here is a practical reason for not prefixing columns with table names. Table aliases already give you a prefix. In complicated queries, you will use table aliases. In simple queries, you don't need the table prefixed to the column name. When I developed a complicated series of queries for a report, many tables were involved and intermediate tables were used in multiple steps. All tables involved had an alias. There is no benefit, and there is a cost to writing code like
Select * from tblEmployees emp join tblSupervisors sup
ON emp.Emp_EmpID = sup.Sup_EmpID
Ugly code. No beneficial information. The same fields existed in multiple tables and I sometimes had to change the join. Using prefixes, I'd have to change the table alias, then the table prefix. A poster mentioned don't prefix for FKs. Before you ask, in the real case, there were no FKs involved. But more importantly, rules with exceptions are a lousy idea.
Don't repeat information. Don't make code verbose.
Don't prefix objects with the type. I don't care if I'm joining a table to a view. Prefixes just make the code verbose. The cost of wordiness exceeds the usefulness of the information. Crutches are no substitute for knowing your database.
-
I use type-specifying prefixes wherever I can (objects, local variables, and column names), and find it extremely convenient.
I think your advice promotes poorly written code.
Jeff Roughgarden, Ph.D., MCSD, MCDBA
-
Hi Andy great article. I use hungarian notation when coding in vb or access or in stored procedures, but not for column and table names. Column and table names represent user data and should have a name that is clear for the user. This without bp of spaces in the name.
I am now working on c# and the reason for not using hungarian notation is that it is object oriented. Even the datatypes are objects. You model the objects to the world of the user. Sometimes a object contains a string and when you call the same object with an other method the object contains a integer. ms has cpoied this principle from java where hn is not part of the naming conventions for the above reasons.
Viewing 15 posts - 16 through 30 (of 72 total)
You must be logged in to reply to this topic. Login to reply