Please start any new threads on our new
site at https://forums.sqlteam.com. We've got lots of great SQL Server
experts to answer whatever question you can come up with.
| Author |
Topic |
|
TonyTheDBA
Posting Yak Master
121 Posts |
 Posted - 2005-11-15 : 07:04:39
|
Hello All, Does anyone have any online links to a resource outlining sensible naming conventions by a Sql 'Authority', I have a team of developers that don't want to follow our corporate SQL Server Standards and need to back up my 'Unhelpful and Obstructive attitude' I have used the links by Narayana Vyas Kondreddi and also [url]http://www.aspfaq.com/show.asp?id=2538[/url] to formulate what I consider to be a set of naming conventions that are sensible, and generally incorporate best practice as much as possible. Due to politics with the organisation I work for I now find myself having to justify why the naming convention convention should be followed and why it is best practice. Thanks Tony-- RegardsTony The DBA |
|
|
blindman
Master Smack Fu Yak Hacker
2365 Posts |
Posted - 2005-11-15 : 08:58:17
|
| That is one of the best set of naming conventions I have seen published. Which is another way of saying that it is virtually identical to the standards I have come to use independently over the past 10 years."Avoid Hungarian notation" -The single best piece of advice on the page. |
 |
|
|
blindman
Master Smack Fu Yak Hacker
2365 Posts |
Posted - 2005-11-15 : 08:59:33
|
| Which standards are your developers violating? It might be easier to outline the specific dangers of some of their practices, rather than trying to answer the general question you posted. |
|
|
|
madhivanan
Premature Yak Congratulator
22864 Posts |
Posted - 2005-11-15 : 09:06:07
|
| Naming convension is just for clarity. But avoid naming your stored procedures having prefix sp_MadhivananFailing to plan is Planning to fail |
|
|
|
TonyTheDBA
Posting Yak Master
121 Posts |
Posted - 2005-11-15 : 09:51:08
|
quote:
Originally posted by blindman
That is one of the best set of naming conventions I have seen published. Which is another way of saying that it is virtually identical to the standards I have come to use independently over the past 10 years."Avoid Hungarian notation" -The single best piece of advice on the page.
Actually I agree, it made it very easy to formulate a document to put to the corporate development team, who accepted it with only minor queries. The team I'm having problems with work in another division and are responsible for producing PI's and such. They have a reporting database that pulls data from existing systems so that they can produce consolidated reports (No, its not a datawarehouse but thats another issue!). They are insisting that all databases should have tables and columns prefixed so that they can Identify the source in the reporting database. . . Personally If they wish to do that in the Reporting Database they are welcome to, (it is unlikely that anyone apart from themselves would be able support it easily anyway). They could just as easily annotate the DTS packages to document the source of the table, and along with naming the DTS package sensibly just as easily identify the source of the information.This is part of what they want for a table defHH1_MV_CLI_REF_ID Smallint HH1_MV_CLI_PARIS_ID Bigint HH1_MV_CLI_NAME DateTime HH1_MV_CLI_DOB Nvarchar (50) HH1_MV_CLI_ADD1 Nvarchar (50) HH1_MV_CLI_ADD2 Nvarchar (50) HH1_MV_CLI_ADD3 Nvarchar (50) HH1_MV_CLI_ADD4 Nvarchar (50) HH1_MV_CLI_ADD5 Nvarchar (50) HH1_MV_CLI_PCODE Nvarchar (50) HH1_MV_CLI_ADDED_ON DateTime HH1_MV_CLI_ADDED_BY Nvarchar (50) And the corporate standards say that it should be ClientID Integer ParisID Integer FullName DateTime BirthDate Varchar (50) Address1 Varchar (50) Address2 Varchar (50) Address3 Varchar (50) Address4 Varchar (50) Address5 Varchar (50) PostCode Varchar (10) AddedOn DateTime AddedBy Varchar (10)I'm sure there must be a Celko article online regarding naiming conventions  I have put forward numerous reasons why the standards should be followed but ended up with a "We must Agree to disagree" comment from them.RegardsTony The DBA"Where is the information?""Lost In the Data.""Where is the data?""Lost in the $@*&ing database!!!" - Joe Celko |
|
|
|
Michael Valentine Jones
Yak DBA Kernel (pronounced Colonel)
7020 Posts |
Posted - 2005-11-15 : 09:57:26
|
| I think the important thing is to have a consistant standard. You can argue about the specifics of the standard forever and not convince everyone. At a certain point, standards simply have to be either imposed or ignored.The reason for the standard it to save development and maintenance time by having a standard that everyone in the organization can quickly understand and use.We have a standard were I work that is different from your standard in many specific points, but we use it. Our standards go far beyond naming conventions into areas like standards for table design and stored procedure error handling.It was a major fight to impose these standards, but now, no one really questions them, and virtually everyone follows them. You can look at any stored procedure being produced where I work, and see a consistant way of declaring parameters, comments, a standard header, a standard error handler, etc.CODO ERGO SUM |
|
|
|
Kristen
Test
22859 Posts |
Posted - 2005-11-15 : 11:36:53
|
| "consistant"+1 for thatBut that does mean that you must evolve a standard, and stick to it. And fix up legacy code if your standard needs to be improved with the benefit of hindsight. So there needs to be buy-in from the "sponsors and owners"+100 for benefits in maintainability of codeKristen |
|
|
|
Vivaldi
Constraint Violating Yak Guru
298 Posts |
Posted - 2005-11-15 : 12:10:43
|
quote:
Originally posted by Kristen
"consistant"+1 for thatBut that does mean that you must evolve a standard, and stick to it. And fix up legacy code if your standard needs to be improved with the benefit of hindsight. So there needs to be buy-in from the "sponsors and owners"+100 for benefits in maintainability of code
Absolutely. Consistency is huge, especially in large systems. My shop has a standard (we use Visual SS for deployment) so using a slight hungaran notation is nice. tb, pr, ix, etc prefixes. for easy naming. (we even structure naming to be (objecttype_module_action)) But it should be tailored for the situation.________________________________________________SQL = Serious Quaffing of Liquor |
|
|
|
|
|
|
|
|
Database Naming Conventions