Rule of Thumb in terms of good programming practice
-
The "why" boils down to your environment. If you don't have control over every facet of object naming, but have code that runs against these objects, then it's your code that will break without the brackets. For some people, that's acceptable. For others, not so much. Considering the fact that many of us here are consultants and therefore don't have final say over object naming, etc., and considering that adding the brackets doesn't affect performance, it's a best practice for some of us.
I don't use them everywhere, but if, for example, I write a udf that accepts object names as a parameter, I never work with the assumption that the person that created the object being passed is as smart about naming things as I would be.
My rule of thumb: If the environment allows you to use weird object names, someone will use weird object names.
-
David, you name it. I do actually never use brackets because I have control over the naming (though I am a contractor, as well). And if I don't I will still not use brackets. Only because SQL Server can live with unusual characters the applications running against the db may eventually not. Hence, I tell my customers that they cannot use names with spaces and so on. And I met quite a number of people with discipline and understanding who agreed on that.
But you're right that when it's possible to use weird names then (unprofessional) people will. And MS is the company to blame because they allow all this. This reminds me of some VBA versions where you could code in languages different from English. What a heck. Fortunately at least THAT has been given up.
-
As an example of the issues being discussed here, my predecessor named a server SQL-Prod. Most applications will run fine but a couple have failed as the '-' (minus symbol) is a reserved character in SQL Server and of course the default instance is called 'sql-Prod'
KISS; Keep it simple Simon. As noted elsewhere restrict yourself to the 7 bit ascii characters.
Regards
Karl
-
Ok, so all in all, brackets are only for reserved words? Then how come when you right-click a table or stored proc, and script it, SQL Server put s brackets around everything, whether they are reserved words or not! That's what I'm getting to here. There must be a reason other than reserved words, to stick to the practice fo doing this for every object whether it be field name, or even a proc name itself!
Example:
CREATE
TABLE [dbo].[AdAttend](
[AdAttendID] [int]
IDENTITY(1,1) NOT NULL,
[AdEnrollSchedID] [int]
NOT NULL,
[AdEnrollID] [int]
NOT NULL,
[Date] [datetime]
NOT NULL,
[StartTime] [datetime]
NOT NULL,
[Attend] [int]
NULL,
even INT has brackets! SQL Server put them there, not me! so there is a reason for this, not just a reserve word issue
-
Same with Redgate, everything it creates has brackets, not just reserve words. Now I'm sure RedGate didn't jsut do this for reserve words obviously...
-
What about reports?
What about "FOR XML" statements?
Can you dictate the names used there?
I guess you cannot. Even if you are CEO in your company.
Because those reports go to other companies and naming is a result of negotiations. And those negotiators not gonna consider your "rule" not to use brackets but make reports unreadable to users instead.
And if you mean to sell the product can you guarantee that server/instance names will not exceed your limitations? Can you control it?
And despite the importance of USA, you know, it's not the only coutry in the world.
And ASCII is an American institute, not German, not French. I wish you try one day to write interface to German SAP system.
So, keep resricting yourself. Just to make sure your system cannot be sold outside the USA. And cannot interact with non-ascii compliant products.
_____________
Code for TallyGenerator -
Because it's not only reserved words (spaces in object names causes problems, for example), and because writing code to only put brackets around things that break the mold is more complex than simply using brackets, and since brackets aren't a detriment, they do so.
Basically, having brackets prevents bizarre error messages and other assorted headaches, and has no detrimental effect, therefore, vendors who use them have cut down a number of completely avoidable support issues.
When playing sports, I try and avoid getting into situations where I could be hit in places that I really really don't want to be hit. Since not everything is within my control, I still wear a cup.
-
OK, so let me sum this up.
Basically it's an all or nothing for me. I either go with brackets on everything or don't. I would prefer to go with brackets because it is "not just for reserved words or words with spaces" and is just good practice and a good basis to code on because of whatever reasons that will save you hassles long term across systems. Ok, but what are the benefits if this is what I am gathering correctly from everyone. I guess I'll do some research on this to see exactly what the benefits are to sticking to putting brackets on everything, spaces or no spaces, reserved words or no reserved words...even table names, stored proc, names, and even types.
Thanks.
-
>>And those negotiators not gonna consider your "rule" not to use brackets but make reports unreadable to users instead.
I'm sorry, this is broken English. Seriously, I'm trying to understand you. Can you please restate this so I can understand your perspective on this?
>>So, keep resricting yourself. Just to make sure your system cannot be sold outside the USA. And cannot interact with non-ascii compliant products.
so are you saying use all brackets or not to?
-
And old QA does it every time.
Automatic tools cannot predict hat kind of names you will use for your objects. So, when it generates scripts it must not give any chance of generating SELECT * FROM dbo.USER
I don't understand what you are saying.
-
We told you the benefits. No headaches when dealing with oddly named objects. That's it.
-
I was replying not on your post.
It was a reply in 7-bit ACSII restriction approach.
See the quote I put in my post.
If you consider this you probably don't need any more explanation.
As for me I prefer not to use brackets in static SP code. It makes it more clean and more readable.
But if there is any kind of dynamic script brackets are mandatory.
_____________
Code for TallyGenerator -
thanks...
And for this:
>>>We told you the benefits. No headaches when dealing with oddly named objects
well, yea, I guess why would you not use brackets if it was odly named (i.e. spaces or reserver words). What I wanted to know is...what were the benefits of using brackets on EVERYTHING...which is what I wanted to know if any.
mix and match...no brackets and only use when required sounds good to me unless there is a compelling reason to use brackets on all objects, regardless if those objects already have weird names.
-
Putting the square brackets around any object name (instance, database, owner and table/view/stred proc/etc) will always work in SQL Server. This of course is why scripting out from Enterprise Mangler and similar uses the brackets on everything.
As I observed earlier none of the migration projects I have worked on were ever expected and the bit that caused the most fun was when someone had used non-standard syntax, data types, etc. This is where my recommendation to use ANSI standard comes from e.g. select * from "master"."DBO"."Sysobjects" will work in any SQL Server, Oracle and Informix database where as select * from [master].[DBO].[Sysobjects] will only work in one of them.
On the other hand it was items like square brackets and date formats that enabled my to take a recent contract role that paid for the 6 months holiday the followed
-
> e.g. select * from "master"."DBO"."Sysobjects" will work in any SQL Server
It will not work on SQL Server 2005.
_____________
Code for TallyGenerator
Viewing 15 posts - 16 through 30 (of 30 total)
You must be logged in to reply to this topic. Login to reply