August 1, 2013 at 8:44 am
saFinance is shorter than FinanceStaging and dwKyle is much shorter than KyleDataWarehouse. The users don't see these names, so they don't have to be user friendly. I can see that some might prefer databases be grouped, in which case the suffix would be better, but I like to have my staging areas grouped together, so I need the prefix.
Some would say I'm giving away my Microsoft Access roots, but no apologies for that.
August 1, 2013 at 9:44 am
I quite agree. Clarity has a lot going for it!
August 1, 2013 at 9:56 am
Why is shorter better?????
This is the fight I have had with developers for years. They provide the argument that "ThisIsTheProductionDatabase" is too much typing, so they name it "PD".
Same thing for objects. Actual words usually work best for names. There is never any confusion.
With your prefix "sa", when I look at this, I would expect some sort of DBA utility database.
In the SQL Server world, SA means system administrator, not 'Staging Area".
How many times have you had to provide an answer, verbal or written, as to what these arbitrary and meaningless prefixes mean? Add up that time, and then multiply that by your salary. These poor practices cost an awful lot of money.
Michael L John
If you assassinate a DBA, would you pull a trigger?
To properly post on a forum:
http://www.sqlservercentral.com/articles/61537/
August 1, 2013 at 10:03 am
Nemeaux (7/31/2013)
So what do you all think about database names as short as 5 characters in length? Which is a standard that is mandated where I work?
That is NUTS.
I guess the point they are trying to make is obfuscation.
Jason...AKA CirqueDeSQLeil
_______________________________________________
I have given a name to my pain...MCM SQL Server, MVP
SQL RNNR
Posting Performance Based Questions - Gail Shaw[/url]
Learn Extended Events
August 1, 2013 at 10:07 am
Grant Fritchey (8/1/2013)
Clarity, clarity, clarity.You need to make things clear. Keeping the names arbitrarily short does nothing but obscure meaning. You want to know what things are, quick, clear and simple. In fact, this should be your naming standard for everything. Keep things clear.
I agree. You want to be able to know what the database (or object) represents quickly and not have to look it up in some documentation translator.
I'm also completely against naming databases based on the environment they are in. That makes things EXTREMELY difficult to manage for testing, coding, rollbacks from production, etc.
<sarcasm> I love the databases suffixed with _DEV that end up being the production database. </sarcasm> That takes a bit of getting used to.
Jason...AKA CirqueDeSQLeil
_______________________________________________
I have given a name to my pain...MCM SQL Server, MVP
SQL RNNR
Posting Performance Based Questions - Gail Shaw[/url]
Learn Extended Events
August 1, 2013 at 11:19 am
How many times have you had to provide an answer, verbal or written, as to what these arbitrary and meaningless prefixes mean? Add up that time, and then multiply that by your salary. These poor practices cost an awful lot of money.
They are obviously not arbitrary or meaningless. If I had said klw for my OLAP and xdr for my staging areas, that would be arbitrary and meaningless. Far enough point on the sa also being system administrator, but lots of abbreviations have multiple meanings.
I've never had to explain them beyond the explanation I gave above. So I would say, all in all, it's very little money. In any case, I'm not trying to convince anyone to change their names to what I think they should be. I'm personally just glad to know that people have naming conventions and use them. I've worked in both environments, and an environment lacking such conventions is harder.
August 1, 2013 at 11:51 am
RonKyle (8/1/2013)
saFinance is shorter than FinanceStaging and dwKyle is much shorter than KyleDataWarehouse. The users don't see these names, so they don't have to be user friendly. I can see that some might prefer databases be grouped, in which case the suffix would be better, but I like to have my staging areas grouped together, so I need the prefix.Some would say I'm giving away my Microsoft Access roots, but no apologies for that.
Like I said, if it's working for you, great!
"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
August 2, 2013 at 8:24 am
Thanks to everyone for all their replies. From all the comments I've read from everyone it looks, at least to me, that short database names are not favored by most.
As a post script to my original question, does anyone know of a definitive authority or publication that can nail this issue down and support the above short name conclusion I've reached?
Thanks!
August 2, 2013 at 8:59 am
From a purely technical point of view, short names don't hurt. They don't help either. A shorter DB name won't make backups run faster, queries run faster or decrease the load on your CPU or network.
So, from there, it becomes strictly a question of opinion. Does it make more sense to make typing a connection string (which usually isn't typed very often, at all) easier or should you go for clarity. I think most people here, and elsewhere, will fall on the side of clarity. But it's just an opinion.
"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
August 2, 2013 at 9:01 am
I think most people here, and elsewhere, will fall on the side of clarity. But it's just a opinion.
However, as you can see, it's an opinion held by many people with years of experience doing this. That's as close to authoritative as you will get on this subject.
//added word "many" to preceeding sentence
August 2, 2013 at 11:02 am
Thanks! I am pretty sure you're right.
Viewing 11 posts - 16 through 25 (of 25 total)
You must be logged in to reply to this topic. Login to reply