February 2, 2011 at 1:18 pm
Greetings,
I am new to this forum. I have been using Sql Server since 2003.
I am facing a sort of conflict with my current customer :
An old sql server database, migrated from sql server 2000 to sql server 2008 (2003 project).
naming of tables are like the following : tbl_ and Vw and yet procedures have no underscores. The database contains no functions.
All object names are abbreviated, without any dictionary to understand what they mean. We have to ask every time.
We developed a new module, and followed Pascal Casing, with clear words for the tables meaning.
The customer makes a code review and says, that object are not correctly named correctly 🙂 and that the meaning of tables is not clear. Names like AnalyticsAxis, is simply not clear to the customer. We are also asked to follow tbl_.
The customer has no document, he's just following habits based on what was done.
My question is :
How do we deal with such situation?
How is the history of naming?
Where does the popularity of capital casing all letters come from in database design?
Often, the client thinks It's a matter of respect, and takes it personnal, while it's a matter of conventions.
Any input, to answer or guide me would be welcome.
Kind Regards,
O.D.
Oussama Dinia
.NET Solutions Architect
http://devmeetsbi.ghost.io/
http://www.devmeetsbi.io/catalog/3079
February 2, 2011 at 1:31 pm
Is this project a one-time development to be passed to the customer after completed for further use and support?
naming of tables are like the following : tbl_ and Vw and yet procedures have no underscores. The database contains no functions.
All object names are abbreviated, without any dictionary to understand what they mean. We have to ask every time.
I believe everyone has their own preference of naming conventions. The "tbl" convention I have heard of coming from people using Microsoft Access (pardon my language:-D).
If this is an application you are developing for the customer. Then after handing it to the customer they will be responsible for future code changes and support, I would believe it is their decision on the naming convention. Any contract or agreement made in developing the application may help you in this matter, as to what power you have over it.
If they are taking responsibility for the application after you are done I would believe it is up to them on what naming convention they want, be it wrong or not. You might give them suggestions on the pros and cons to using their convention. Which finding documentation that supports your side is a plus. EDIT: If they insist on their convention, I would request documentation on it with explanation on how it should be used.
Shawn Melton
Twitter: @wsmelton
Blog: wsmelton.github.com
Github: wsmelton
February 2, 2011 at 1:49 pm
Thanks Shawn.
so much for access and tbl_ 🙂 (Access is Access, and SQL Server is SQL Server I would say).
That application is a tuff one (4000 lines of code for some pages :)), and so is the database 🙂
All this was already existing, we are adding new modules.
Indeed, my main question is who has the power in deciding, and if them, then I will request a document to follow. Thanks for that, I needed to hear it 🙂
This is the tuffest client we've had in years, we hope to be able to keep up, and help them change a little 🙂
Apart from pascal casing and camel casing, we use prefixes when necessary, like vw or fcn for views and functions.
Thanks again 🙂
Oussama Dinia
.NET Solutions Architect
http://devmeetsbi.ghost.io/
http://www.devmeetsbi.io/catalog/3079
February 3, 2011 at 7:40 am
If they can at least explain their naming convention, follow it. Have you done it in a way that is clear and at least reasonably accurate? Yes. But that doesn't really matter. If they're used to working with it one way, you'll need to comply, however silly it might be (and tbl_* is pretty darned silly).
"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
February 3, 2011 at 7:53 am
I'd have to agree with Grant. Sometimes consistency has to trump logic, especially when you're handing it off to someone else for support.
Also, if they're going to be inflexible about it they should really have a naming convention/best practices type document to guide you.
_____________________________________________________________________
- Nate
February 3, 2011 at 8:21 am
I agree. Don't argue with them (naming convention arguments are such a waste of time). But do ask to document the standard, just so you can better comply with it.
"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
February 4, 2011 at 3:03 am
Hello Everyone,
First, thanks to all for the advice. At first, I did not follow naming conventions used by the client, as he had none defined in a document. Now that I'm changing them to follow them, yet, without a document (as my company asked me to do without, until they create them).
It's a matter of calming things down. Pascal and Camel casing seem out of scope!!!
I am being as patient as possible, renaming TransferID to ID_TRANSFER and Transfer (s) tablename to tbl_TRANSFER.
Either way, sometimes easy clients, sometimes tuff clients.
Thanks again
Oussama Dinia
.NET Solutions Architect
http://devmeetsbi.ghost.io/
http://www.devmeetsbi.io/catalog/3079
February 4, 2011 at 3:13 am
It is always appropraite to follow coding standard properly documented. This document should be either provided by client and followed religiously by you OR created by you and approved by your client.
i think in your case you are finding yourself in first scenario, you appropriate to request coding standard document from your client
good luck
Viewing 8 posts - 1 through 7 (of 7 total)
You must be logged in to reply to this topic. Login to reply