February 24, 2012 at 7:17 am
Dear Celko . . .
You have ZERO CLUE as to my environment and situation.
This is an environment that I INHERITED. I DID NOT BUILD THIS. This is based on a production environment, and I have limited leeway as to how I am able to configure and work with this. I need to work with the cards I've been dealt.
If you feel a need to continue blowing off (what you perceive is) your subjectual superiority, do it somewhere else. I'm f--king sick of you insulting my (and everyone else's) intellegience.
I haven't posted many questions to these things in a while. As a result, I haven't seen any postings from you in a while. I'd really hoped that you'd fallen off the face of the earth. That was wishful thinking on my part.
+--------------------------------------------------------------------------------------+
Check out my blog at https://pianorayk.wordpress.com/
February 27, 2012 at 5:14 am
CELKO (2/24/2012)
This is an environment that I INHERITED. I DID NOT BUILD THIS. This is based on a production environment, and I have limited leeway as to how I am able to configure and work with this. I need to work with the cards I've been dealt.
Then say this in the posting. After so many decades of fixing bad SQL, I find that bad DDL is usually the real problem. Therefore, that is what you fix first; and that solves other problems that were not part of the post.
And why should anyone specifically have to post they didn't create the tables or database when they are asking a query question? Very few people are going to post a query question about tables when they are in the middle of creating the tables. More than likely, they're going to post a "how do I create tables to do this?" question.
This is not an issue with Ray's post, Celko. This is an issue with your assumptions. You brow-beat everyone as if they are personally responsible for the problems they are trying to resolve. You don't ask if they created the schema, you assume. And those assumptions are why so many people have problems with your online persona.
You want people to stop bagging on you? Then I suggest you start asking questions to clarify your own assumptions before you hit everyone across the back of the head with your clue bat.
P.S. 90% of the time that you pull this "dummy, fix your schema" lecture, you're pulling it on people who are working with vendor or created-by-the-previous-DBA databases. Unlike you, I've been paying attention to the responses to your schema rants. And generally, that's the first thing people say.
February 27, 2012 at 1:03 pm
CELKO (2/23/2012)
The short answer is that you are not writing RDBMS at all. Trust me, there is no such thing as a “junction table” (that is an old network database term).
Nah, we call them Many to Many tables now. Funny that, they still exist. So sorry it's not your ivory tower lingo. Hey, whatta ya know, Many-To-Many DOES still exist in standard RDBMS design. WOW!
There is no such thing as a magical universal “id” (that was physical sequential record number on mag tape). Educational degrees are not categories; they are values.
Holy anal batman. OCD much? Seriously? He's describing a problem not writing a technical document. We got it, you and your high horse should have had a better vantage into being able to see what he meant.
Start using the ANSI/ISO row constructors
Nah, I much prefer something that makes sense to the people I work with instead of forcing them to conform to a random technical document out in the Aether that makes some DBA in his tower happy.
In the real world, this short list would be in a CHECK (degree IN (..)) constraint.
No, in the real world it'd be a lookup table with IDs assigned so you could easily fix spelling errors or add additional information as necessary attributes and keep primary storage smaller, WITH IDs.
What follows next is a relationship, not a junction. The names of the attributes DO NOT CHANGE from table to table! This is a fundamental concept in RDBMS.
No, that's a fundamental concept in RDBMS Design by OCDs. That you default to cascades scares the crap out of me, too, may the digital gods protect my large tables from your lookups. And hey, look! It's a junction! Two things met and crossed over each other! Oh, wait, they're related? That too!
Oh, look, my sarcasm functions too. Wow, maybe *I* should use it every time I post, then I can be Celko! I understand you're a nice guy in real life. Is there a method of taking a board to the back of the head of your internet personality alone?
This is a relational division; it was one of the original 8 operators in Codd's papers.
Two types of people have read through those inanely dry pieces of literature often enough to memorize it. Database Engine Designers and Academics. Neither of which most people are. I'll leave memorizing Codd to you. I think I'll just get work done. I don't care what one man decided to call particular components, only that the theory he built is sound.
And you gave the spec wrong. A EXACT division will have those two and only those two degrees; division with a remainder will have at least those two and perhaps more. Lets create a divisor table:
You'd SERIOUSLY build a hard table for this, as to what is relatively obviously a parameter set? Why wouldn't you just put a computed column on the employee table and use a trigger off the junction to determine this for faster lookups after the fact if you wanted to take a hard-coded approach.
*facepalm* Please, Celko... go away.
Never stop learning, even if it hurts. Ego bruises are practically mandatory as you learn unless you've never risked enough to make a mistake.
For better assistance in answering your questions[/url] | Forum Netiquette
For index/tuning help, follow these directions.[/url] |Tally Tables[/url]
Twitter: @AnyWayDBA
February 27, 2012 at 1:36 pm
CELKO (2/23/2012)
Start using the ANSI/ISO row constructors
Evil Kraig F (2/27/2012)
Nah, I much prefer something that makes sense to the people I work with instead of forcing them to conform to a random technical document out in the Aether that makes some DBA in his tower happy.
While I agree with most of what you wrote, I see no reason not to start using ANSI/ISO row constructors if you're not supporting SQL 2005. They're a perfectly logical extension of the syntax that has existed in T-SQL for awhile.
Drew
J. Drew Allen
Business Intelligence Analyst
Philadelphia, PA
February 27, 2012 at 3:14 pm
drew.allen (2/27/2012)
CELKO (2/23/2012)
Start using the ANSI/ISO row constructorsEvil Kraig F (2/27/2012)
Nah, I much prefer something that makes sense to the people I work with instead of forcing them to conform to a random technical document out in the Aether that makes some DBA in his tower happy.While I agree with most of what you wrote, I see no reason not to start using ANSI/ISO row constructors if you're not supporting SQL 2005. They're a perfectly logical extension of the syntax that has existed in T-SQL for awhile.
Drew
It's more the standardization of the items that doesn't always match locally used equivalents that I disagree with. But you're right, I'm harassing him there for the wrong item. I just got mentally stuck on one of his usual harps instead of the one that's there.
Also, I haven't worked at anyplace that has a full production install of 2008 *yet*. I also keep my 2k skills current, I have two clients I do spot work at that will probably never upgrade. I never assume anything's current and dislike having to update someone's 'newfangled' method to work on my 2k5 boxes. I have a 2k8 sandbox so it's not a huge deal though.
*shrugs* I wouldn't make the assumption that someone trying to help me is on the most recent version, so I would rarely use that style in a request for assistance.
Never stop learning, even if it hurts. Ego bruises are practically mandatory as you learn unless you've never risked enough to make a mistake.
For better assistance in answering your questions[/url] | Forum Netiquette
For index/tuning help, follow these directions.[/url] |Tally Tables[/url]
Twitter: @AnyWayDBA
February 27, 2012 at 3:49 pm
Hey Celko, when you consult with a client who has applications built around a database (assuming you actually work and don't just talk theory), do you tell them to rebuild their entire application and database? If a client calls me and says that they have an issue and that they don't want to have to spend money to rebuild an entire database and application, I don't tell them their design is crap and to rebuild it. I find solutions to deal with the issue at hand. My clients don't give a damn about how it should be or how the original design was bad, they want a solution so that their business can continue to function.
Standards don't mean anything when they don't solve the issue of an end user or client. Learning to design and understand theory is one thing, to practice it in the real world 100% of the time is another; It is not just impossible, but impractical.
Jared
CE - Microsoft
Viewing 6 posts - 16 through 20 (of 20 total)
You must be logged in to reply to this topic. Login to reply