January 6, 2012 at 6:11 am
All caps in the naming convention sucks. Using the "_" in the naming convention can make things more understandable at a glance, but makes it a major pain when typing queries. Which is why I also prefer the CamelCase method. Makes it easy enough to read and understand and easy to type. Although I can also see where that would be a pain in a case-sensitive database. Luckily, I haven't had to work with such a database. Yet.
-- Kit
January 6, 2012 at 6:16 am
Koen Verbeeck (1/5/2012)
Thanks again everyone for their congratulations!
You're the daddy!
Well done dude. You know those little foam things you put in your ears when you're clay-pigeon shooting? Get some!
For better assistance in answering your questions, please read this[/url].
Hidden RBAR: Triangular Joins[/url] / The "Numbers" or "Tally" Table: What it is and how it replaces a loop[/url] Jeff Moden[/url]
January 6, 2012 at 6:16 am
Kit G (1/6/2012)
All caps in the naming convention sucks. Using the "_" in the naming convention can make things more understandable at a glance, but makes it a major pain when typing queries. Which is why I also prefer the CamelCase method. Makes it easy enough to read and understand and easy to type. Although I can also see where that would be a pain in a case-sensitive database. Luckily, I haven't had to work with such a database. Yet.
Yup CS server is a big PITA.
I'd say that 20-50% of the scripts out there won't work right off the bat on the CS server (especially the longer ones).
January 6, 2012 at 6:43 am
Ninja's_RGR'us (1/6/2012)
Kit G (1/6/2012)
All caps in the naming convention sucks. Using the "_" in the naming convention can make things more understandable at a glance, but makes it a major pain when typing queries. Which is why I also prefer the CamelCase method. Makes it easy enough to read and understand and easy to type. Although I can also see where that would be a pain in a case-sensitive database. Luckily, I haven't had to work with such a database. Yet.Yup CS server is a big PITA.
I'd say that 20-50% of the scripts out there won't work right off the bat on the CS server (especially the longer ones).
And I am just glad that the DB2 AS400 I also have to deal with is not CS.
Take that back - not for some things.
Saw a good tag line today to get a humerous start to the day.
There are 10 kinds of people in the world - those that understand binary and those that don't.:-D
January 6, 2012 at 6:46 am
Greg Edwards-268690 (1/6/2012)
Ninja's_RGR'us (1/6/2012)
Kit G (1/6/2012)
All caps in the naming convention sucks. Using the "_" in the naming convention can make things more understandable at a glance, but makes it a major pain when typing queries. Which is why I also prefer the CamelCase method. Makes it easy enough to read and understand and easy to type. Although I can also see where that would be a pain in a case-sensitive database. Luckily, I haven't had to work with such a database. Yet.Yup CS server is a big PITA.
I'd say that 20-50% of the scripts out there won't work right off the bat on the CS server (especially the longer ones).
And I am just glad that the DB2 AS400 I also have to deal with is not CS.
Take that back - not for some things.
Saw a good tag line today to get a humerous start to the day.
There are 10 kinds of people in the world - those that understand binary and those that don't.:-D
I always wanted to do that on a big stage (like humor show), just to easily spot all the programmers (computer savy) in the room.
January 6, 2012 at 7:12 am
Ninja's_RGR'us (1/6/2012)
Greg Edwards-268690 (1/6/2012)
Ninja's_RGR'us (1/6/2012)
Kit G (1/6/2012)
All caps in the naming convention sucks. Using the "_" in the naming convention can make things more understandable at a glance, but makes it a major pain when typing queries. Which is why I also prefer the CamelCase method. Makes it easy enough to read and understand and easy to type. Although I can also see where that would be a pain in a case-sensitive database. Luckily, I haven't had to work with such a database. Yet.Yup CS server is a big PITA.
I'd say that 20-50% of the scripts out there won't work right off the bat on the CS server (especially the longer ones).
And I am just glad that the DB2 AS400 I also have to deal with is not CS.
Take that back - not for some things.
Saw a good tag line today to get a humerous start to the day.
There are 10 kinds of people in the world - those that understand binary and those that don't.:-D
I always wanted to do that on a big stage (like humor show), just to easily spot all the programmers (computer savy) in the room.
Visions of big screen of Assembly language...to spot the older geek in the crowd.
Happy Friday everyone!
January 6, 2012 at 7:48 am
Case insensitive vs case sensitive, one of the reasons I write all my queries and t-sql code as if everything was case sensitive. Don't have to worry about it that way.
January 6, 2012 at 7:52 am
Revenant (1/6/2012)
SQL Kiwi (1/5/2012)
Jeff Moden (1/5/2012)
SQL Kiwi (1/5/2012)
Jack Corbett (1/5/2012)
Have had a discussion with Aaron Bertrand about case-sensitivity recently.You knows he's super-anti-underscores?
Makes two of us.
Worldwide? 😉 😛 😀
No way. On the projects that I lead or QA'd, you will not find a single name with underscores. Not that I would ever lean on my team to adhere to my personal preferences -- it just happens that they conclude, no pressure, ... 🙂
Serious: not a single underscore in 8 years and counting.
I don't like underscores, but I have no compelling argument to get people who like them to stop using them. I never use them myself and I remove them when I have the chance, but I don't always have that chance.
--------------------------------------
When you encounter a problem, if the solution isn't readily evident go back to the start and check your assumptions.
--------------------------------------
It’s unpleasantly like being drunk.
What’s so unpleasant about being drunk?
You ask a glass of water. -- Douglas Adams
January 6, 2012 at 7:54 am
Brandie Tarvin (1/6/2012)
Stefan Krzywicki (1/5/2012)
Speaking of venting vaguely, don't you just love when there's a third party tool (maybe even made by another group in your company) with a database you can't modify and they have tables with fields likeUserData1 varchar(1000) NULL
UserData2 varchar(1000) NULL
UserData3 varchar(1000) NULL
UserData4 varchar(1000) NULL
UserData5 varchar(1000) NULL
UserData6 varchar(1000) NULL
UserData7 varchar(1000) NULL
UserData8 varchar(1000) NULL
UserData9 varchar(1000) NULL
UserData10 varchar(1000) NULL
I suppose that's better than varchar(max)...
My "favorite" is a recent rash of CREATE TABLE statements where all columns are nullable except for the Identity column.
When I verbally smack people for that, the response I get is "but we're taking care of the data verification in the stored proc code." To which my response is "Well, that's all fine and dandy, but what about the data that can get inserted without use of the stored proc, like SSIS or an ad-hoc query? I won't let you create this table unless you define which columns, other than the Identity/PK are required. There has to be at least one."
Am I the only person who hates the idea of an entirely NULL rowset with only an Identity in it?
Nope, I'd politely suggest that they should think about the data more and include NOT NULL for some of the columns to let future users know what's important just by looking at the table structure. Sometimes that works, sometimes you have to reach for a bigger bat.
--------------------------------------
When you encounter a problem, if the solution isn't readily evident go back to the start and check your assumptions.
--------------------------------------
It’s unpleasantly like being drunk.
What’s so unpleasant about being drunk?
You ask a glass of water. -- Douglas Adams
January 6, 2012 at 8:03 am
Brandie Tarvin (1/6/2012)
My "favorite" is a recent rash of CREATE TABLE statements where all columns are nullable except for the Identity column.
Hey, some tables like that are OK. The only non-nullabble column in my Tally table is an integer primary key, and in the bad old days (no ROW_NUMBER()) it was an Identity column. :hehe:
When I verbally smack people for that, the response I get is "but we're taking care of the data verification in the stored proc code." To which my response is "Well, that's all fine and dandy, but what about the data that can get inserted without use of the stored proc, like SSIS or an ad-hoc query? I won't let you create this table unless you define which columns, other than the Identity/PK are required. There has to be at least one."
If the security is done right there is no mechanism other than calling the stored proc for inserting or altering rows, so that's not always a good argument. But there is an absolutely solid argument: as much as possible should be done declaratively even if it's also done procedurally, so apart from the trivial exception of a tally table there should be some constraints other than the primary key constraint. 😉
Am I the only person who hates the idea of an entirely NULL rowset with only an Identity in it?
Probably not; but although I agree that in 99.9% of cases when you see that it will turn out that it's unjustifiable bad design, there are (extremely) rare cases where it is in fact good design, eg here's something that seems reasonable :alien:
create table brek (
brekID int identity(1,1) primary key
, m int null references meat(meatID)
, v int null references veg(vegID)
, constraint CK_brek CHECK (m is not NULL or v is not NULL)
, constraint UQ_brek unique(m,v)
)
I like disallowing nulls, but sometimes it implies too many tables, too many joins, too much code, and doesn't avoid the nulls anyway (because you need to use outer join to combine the many tables and that brings nulls back, or you need an outer union to combine them and as well as bringing nulls back that has to be hand coded because T-SQL has no outer union operator).
Tom
January 6, 2012 at 8:32 am
At the risk of being virtually lynched, I can see the use in underscores in table names and especially in constraint names.
I shall now run away and hide before anyone finds the pork chop launcher.
January 6, 2012 at 8:38 am
Jeff Moden (1/5/2012)
Steve... any chance of getting a "thread count" for 2011?
Posts by year? Sure, I'll query it.
January 6, 2012 at 8:39 am
Brandie Tarvin (1/6/2012)
At the risk of being virtually lynched, I can see the use in underscores in table names and especially in constraint names.I shall now run away and hide before anyone finds the pork chop launcher.
Hey if the DTA uses it it must be good to use in production, right?
:hehe:
January 6, 2012 at 8:41 am
GilaMonster (1/6/2012)
I hate underscores. I hate all caps naming. I have a special hatred for what I have in a system at the moment:INSURANCECAMPAIGNREVIEW_STARTDATE
Don't hate, but I find it hard to read. I prefer
InsuranceCampaignReviewStartDate
January 6, 2012 at 8:48 am
Since inception, here are the posts
Year Mo Posts
20121249
201112806
201111906
201110862
20119974
20118909
20117837
20116894
20115763
20114812
20113888
20112740
20111798
201012824
201011972
2010101457
201091613
201081057
20107833
20106492
20105582
201041325
201031575
201021139
20101568
200912810
200911625
200910674
20099508
20098690
20097772
200961167
200951284
20094740
200931018
20092993
20091603
200812364
200811161
Viewing 15 posts - 33,271 through 33,285 (of 66,549 total)
You must be logged in to reply to this topic. Login to reply