Database name with special character(Urgent)
-
To some, it's what works for them. To others, it's what works all the time.
I would personally expand that to be "It's what works for them all the time.", as I think many best practices are best localized. Of course, that takes us right back to "It depends."
-
Heh... "What works for them all the time", could break tomorrow...
Then, a new "Localized Best Practice" will be born getting them closer to the true "Best Practice". 
Guess that's what Serqiy is trying to get at... you can call something a "Localized Best Practice", but it's not the "Best Practice" unless it is also the one that will never break.--Jeff Moden
RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.Change is inevitable... Change for the better is not.
Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally) -
> I should tell you that I don't use the square brackets on everything... my "personal preference" is to avoid names with special characters simply because I hate typing the square brackets...
Just like me!
I also avoid square brackets as much as possible.
But when my colleague created a table "User" in our common project I did not say a word.
Because there is nothing wrong with table dbo.[User].
Whether I like this idea or not.
_____________
Code for TallyGenerator -
Except that that's really easy to take to an extreme. If we coded to handle all situations, pretty soon our code would all look something like...
INSERT INTO [MyDB].[dbo].[TableOLastNames]
(
[LastName]
)
SELECT
[LastName] = Left(Ltrim(Isnull([g].[LastName],'')),25)
FROM
[MyDB].[dbo].[MyOtherTableOLastNames] AS [g]
Because someone might change the source table's LastName field to be longer than 25 characters, and someone might also have added some spaces to the beginning on accident, and someone might decide that the destination table shouldn't have a nullable LastName column. Sure, there are times and places where one or more of these types of things might be needed, but I wouldn't recommend anyone code everything that way.
That's why I use localized "Best Practices". I know what I do and don't have control over, what works best in our environment (this is quite fluid even within our own environment, and even moreso universally, which is the main reason not to get carried away with this stuff) and I adjust things accordingly.
-
David,
how do you know if someone have added some spaces to the beginning of LastName on accident or it was intentional?
Data is data. You should not modify it unless modifications are specified by business rules.
_____________
Code for TallyGenerator -
Well, the debate started with just that, the semantics of the two words 'best' and 'practice'
The challenge was if the proposition was really 'best', and if it was suited to be called a 'practice', even.
Noone has said that anything on the past pages has been 'wrong', the only arguments has been about semantics.
While I do enjoy discussions, even about semantics, there's a limit on how far you can take such debates without actually sitting in the same room, or at least have audio and visual contact. Plain text is only 'so good'.
It's very similar to debating religion or politics. Each has it's own preferences that they consider 'best' (naturally, that's their conviction).
OTOH, discussions such as this, also serves well as food for thought, and perhaps even reevaluation of ones current convictions. We are all just the sum of our own experiences after all.
So, I'll (try) to close with that it seems that some agreements has been made.
It's been established as a 'practice' - both the practice of 'always use []' and 'don't use something that isn't allowed', even by Sergyi.
As Jeff said, BOL doesn't say anything about 'best practice', but it has never done that. BOL is just a place for facts. (The quality and consistency is another matter) But, nowadays, the term 'Best Practice' has become a 'label' of it's own. There are 'whitepapers' out there, and there are lots of documents with 'Best practice' in it's title for all kinds of different stuff. The common thing about all 'Best Practice' docs is that they contain what the authors of said docs consider as their foremost recommendations on the subject at hand. (aka 'best')
This gives that we shouldn't break the words apart and question wether 'best' is appropriate, or is this really 'practice' or not, 'best practice' is an expression, and should be evaluated as such.
If we agree on this, then we'll also find that it's a more or less a 'common expression' with some foothold already gained as to what it means as a concept. Further, all of these already published 'best practices' doesn't always talk about the same things as 'best', but still they exist.. Can it be that there actually may be different 'best practices'..? Does that make one more 'right' than the other? Or are they just different, and it's up to the reader to read and decide which they want to go with..? (or maybe formulate their own...)
I'd say it's the latter. Given the need to find some 'best practice' for a given situation, one should look around, see what's available, review and then decide if any of it was of use. It's anyone's choice to either adapt an idea or not. 'Best' is only 'best' until 'better' comes along, right? Haven't seen any 'Better Practice' docs around, though....
/Kenneth
-
> Noone has said that anything on the past pages has been 'wrong'
I said.
You definition of your habits as "best practice" is wrong.
Period.
> It's very similar to debating religion or politics. Each has it's own preferences that they consider 'best' (naturally, that's their conviction).
Most terrible wars started when some one decided that his preferences are "the best practice".
You find your habit useful and comfortable - it's OK with you.
But don't dare to name it "best practice" unless you've got solid proof for such statement.
So, what about saving words and showing some real benefits of the practice you named "best"?
_____________
Code for TallyGenerator -
Heh... again, I absolutely agree... that makes for some butt ugly
code and I'd personnally never do it that way... Like you, my "Localized Best Practice" is to use square brackets only if they're required (getting the feeling you didn't read my whole "lengthy" post ... not sure I blame you... it was LONG 
). Even Serqiy does that same thing... but, it's not the best coding practice simply because it could break (likely only during unit test which is why we accept no brackets as a "Localized Best Practice" and telling someone that the use of brackets is not a "Best Practice" might not be a best practice. On something like that, I'd simply say "Use brackets to overcome the problem. If you don't like the brackets (I don't), avoid the use of special characters." 
OTOH, discussions such as this, also serves well as food for thought, and perhaps even reevaluation of ones current convictions ...And, they give me something to ponder during morning coffee!
Can it be that there actually may be different 'best practices'..? Does that make one more 'right' than the other? Or are they just different, and it's up to the reader to read and decide which they want to go with..? (or maybe formulate their own...)
I'd say it's the latter.
Heh... I absolutely agree... unless you want to study the semantics of the phrase "make one more 'right' than the other".
Serqiy's semantic (just for purposes of this discussion because he does the same as the rest of us, brackets only where needed) appears to be the one that works everytime should be the only one to be identified as the "Best Practice". I just can't argue with that one.And, you hit the nail on the head... what may be a "Best Practice" in one environment, may not be even close to right for someone else. That's why I try not to impose the words "Best Practice" on anyone except for one thing... the code actually has to work (well, with one exception)
Like Serqiy, David, and Kenneth, my "Localized Best Practice" is to avoid using special characters and brackets to, if nothing else, improve readability of the code (well, in my eyes, anyway). Anyone want to talk about the "Best Practice" of using underscores or not? How about writing in all upper-case or all lower-case? How about when to do a line-break in code or the position of mathematical operators on wrapped lines? How about the myth of writing trully portable code?
As Kenneth pointed out, you can find dozens of white-papers on these subjects written by "experts" with years of experience, all of which are frequently interpreted as a "Best Practice". But, would I impose any of those as the "Best Practice" on someone else? Nah... it's just a recommendation based on some experience...
The word "Best Practice" has been overused IMHO, and, as Kenneth pointed out, the semantics of the phrase "Best Practice" are what started all of this. My "Best Practice" is to tell folks what will happen if they do or don't do something... they can figure out if they want to use it as a "Best Practice"... or not.
--Jeff Moden
RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.Change is inevitable... Change for the better is not.
Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally) -
Jeff, I always read posts in their entirety when I come across them.
I guess my main argument is that if we accept that "Best Practices" is a worthwhile philosophy, then so is "Localized Best Practices", which I think is actually far more useful in the wild. In other words, who are we to tell someone else the proper way to do their job, especially without knowing everything about the environment they work in?
-
> I said.
> You definition of your habits as "best practice" is wrong.
> Period.
Fine by me. You don't have to agree, and I certainly don't want to force my opinion over yours.
This is just pure semantics anyway - 'best', 'better', 'right', 'wrong', 'good' 'evil'... just words with no defined universal absolute meaning. If you think it is 'wrong', then you're welcome to do so. It's my gift to you.
> Most terrible wars started when some one decided that his preferences are "the best practice".
Not entirely true. Terrible wars only start when that person also decides that it's ok to force his/hers opinions on others, even if they disagree. That person would be someone who would not accept other opinions than his own, and would stand back at nothing to make sure that dissidents would not be allowed to be seen nor heard.
Such a person wouldn't be able to conduct a dialog, or to be reasoned with.
> You find your habit useful and comfortable - it's OK with you.
> But don't dare to name it "best practice" unless you've got solid proof for such statement.
Yet more semantics. What is 'solid'? What is 'proof'? Is it conclusions based on official texts such as the 'rules' that you write off as 'crap' or is it something else?
Jeff showed some of the wiki definition - 'Best Practice is a management idea'.
Here's a small quote from wiki - totally ripped out of it's surrounding context
-- quote --
A Best Practice can be selected (generally from several competing options) and defined within a computer system.
-- end quote --
Oh dear... They say there may be 'competing options' among available Best Practices...
Does that then mean that there are more than one single 'Best Practice' out there..?
Of course, it could also mean that 'there can be only one', and what it contains is choosed from the 'competing options'. If that's the case, then you're right. I wouldn't dare... Noone would dare.. until each and everyone could come to an agreement on which of the 'competing options' is to be called the 'Best Practice'.
But then again... apparently there already are several of them out there.. How can that be?
> So, what about saving words and showing some real benefits of the practice you named "best"?
What would you consider as a 'benefit'?
Keeping something simple or more complex?
Aiming for lower risk or higher risk?
......
Sorry, but it's now Friday evening and I'm going home for the weekend.
Have a nice day/weekend all of you.
/Kenneth
-
For the record, Kenneth's example earlier is a perfectly valid one as to why always using brackets to resolve less than ideal identifier naming choices isn't always a good idea.
The following code (tested in 2005) will be more than happy to create a table for you (run this at your own risk, as noted below):
DECLARE
@test-2 varchar(10)
DECLARE
@strSQL varchar(500)
SET
@test-2 = 'A' + Char(8) + 'B'
SET
@strSQL = 'CREATE TABLE [' + @test-2 + '] (Col1 int, Col2 int)'
EXEC
(@strSQL)
--SET @strSQL = 'DROP TABLE [' + @test-2 + ']'
--EXEC(@strSQL)
On the other hand, you'll notice the two commented lines above. Those are necessary, as though SQL Server will be perfectly happy to create it for you, trying to DROP it through the UI won't work so well. For anyone who happened to create the table, comment out the first EXEC, and uncomment the last two lines to get rid of the table. One might argue that this situation would be a rare occurrence, and I definitely agree, but I can think of far more situations where it could occur (such as a bad keystroke handling routine in .NET) than situations where someone's lastname validly begins with a space.
-
Sorry, David, you failed to prove validity of Kenneth's example.
> trying to DROP it through the UI won't work so well
Of course, if you using bad SQL syntax for database calls.
Build you string in UI properly - and everything will work perfectly.
Just like that commented string.
_____________
Code for TallyGenerator -
To stop discussion "Are there best practices at all" I may bring an example of truly best practice:
Always qualify names of objects owned by database owner with "dbo".
Do you know any contras to this statement?
So, there are best practices. Real best practices.
But avoiding brackets in SQL code is not one of them.
_____________
Code for TallyGenerator -
Who said anything about using bad SQL syntax? If you consider me using the right-click menu to drop a table to be an example of me using bad syntax, then semantics are the least of your concerns.
Again, you can't drop that table from the UI. User Interface. That thing that we sometimes go clicky-clicky on. Right-clicking on the table name and choosing "Delete" causes an error, even though SQL Server was perfectly happy to create the table. Kenneth's example was a perfectly valid example of why one shouldn't accept delimited identifiers as the one-sized fits all solution, as they have their own problems.
-
In other words, who are we to tell someone else the proper way to do their job, especially without knowing everything about the environment they work in? Exactly
--Jeff Moden
RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.Change is inevitable... Change for the better is not.
Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally)
Viewing 15 posts - 31 through 45 (of 58 total)
You must be logged in to reply to this topic. Login to reply