August 10, 2012 at 3:52 pm
Lynn Pettis (8/10/2012)
Okay. Just let off a little rant to Mr. Celko again. Please, if anyone thinks I went too far (and no, you'll have to find it yourselves) please let me know.
If it's the very brief one in the "unique constraint" thread, then I' afraid my answer is "yes, you clearly went too far". In his several posts in that thread, Celko had avoided his usual rants and offensive approach and was giving clear and reasoned argument. Sure, there was an appeal to Codd, but a sensible one that was clearly marked as such and not an attempt to bulldoze the argument. Your contribution was what I can only describe as inept impoliteness. But the emoticons suggest that that was not actually a rant, merely an inept attempt at humour, so maybe you are referring a different post.
I intensely hate Celko's usual offensive ranting style, and I'm inclined to cheer when I see proper contributions from him instead of that nonsense because when he sets jis mind to it he can make a terrific contribution. It's a pity that you have become so conditioned by seeing those rants that just his name on a post appears to send you over the top, even when the post has none of that ranting in it. Responses like yours will perhaps suggest to him that it's not worth the effort of avoiding the offensive style that he is sometimes pulled up on because his perfectly sensible posts are treated just the same.
Tom
August 10, 2012 at 4:05 pm
Steve Jones - SSC Editor (8/10/2012)
Lynn Pettis (8/10/2012)
If I'm wrong, tell me. Show me how I am wrong and how I can do things better. But don't attack me, don't challenge my intellect, knowledge, skills, or abilities. All you are going to do at that point is put me on the defensive and then I don't care how right you may be.You're missing the point. There is no right and wrong here. You are arguing a different perspective than Mr. Celko, often not even on the technical merits.
Making do with what exists is fundamentally different than dealing with improper design.
Not from what I interpret what Mr. Celko writes. I may be wrong, but from what I have read it doesn't matter to him if it is what you have to work with, if it is wrong, its wrong. I have seen one post that was actually helpful from him. The rest, I'm sorry, they have pushed me in direction that I personally don't have much respect for him or what he says.
I would rather see him write more along the lines like this:
Point out that the design is flawed, but do so in a manner that does not attack or berate the OP. In other words, no more "You are wrong statements," or telling the OP that he (or she) doesn't know what they are doing. This attacks the OP, not the design.
Show how the design could be better. A "this is how it should (or could have) been designed" type discussion. Explaining why it would be better.
Then acknowledge that the OP has to work within the constraints of what has been given, and how he would attack the problem within those constraints knowing that a rewrite may simply be out of scope, not possible at this time.
August 10, 2012 at 4:09 pm
Yes, it went too far. That was doing exactly what we complain about Celko doing - attacking the person not the idea.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
August 10, 2012 at 4:13 pm
GilaMonster (8/10/2012)
Yes, it went too far. That was doing exactly what we complain about Celko doing - attacking the person not the idea.
Thank you, All. I will redact my comment.
I have also asked Eugene to remove the comment from the quote in his post.
August 10, 2012 at 4:19 pm
GilaMonster (8/10/2012)
Yes, it went too far. That was doing exactly what we complain about Celko doing - attacking the person not the idea.
+1
Paul White
SQLPerformance.com
SQLkiwi blog
@SQL_Kiwi
August 10, 2012 at 4:33 pm
edit: nevermind, really wasn't relevent.
August 10, 2012 at 4:35 pm
It has been said on a few occasions in this thread in the past.
I think we need to refrain from attacks on the person and refrain from piling on. I think it has been more common of late with the attacks and piling on. I would like to see more supportive comments where applicable. Debunk a bad comment or bad advice - that is fine. But let's leave it at that and keep it simple. No need to attack. We wouldn't that kind of attitude driving people away from the community or this site. Nor do we want that to reflect dimly on us among our peers and employers.
I would like to see us grow a thicker skin when reading some of these comments by certain individuals and think 3 or 4 times before posting. Maybe take a walk or swim first. If it works to wonder what your wife, daughter, mother or boss would think about the post - then do that before you post something that you have any question as to whether it is over the line or not. Of course, if you wonder if it crosses a line - it probably does.
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 10, 2012 at 4:39 pm
SQLRNNR (8/10/2012)
It has been said on a few occasions in this thread in the past.I think we need to refrain from attacks on the person and refrain from piling on. I think it has been more common of late with the attacks and piling on. I would like to see more supportive comments where applicable. Debunk a bad comment or bad advice - that is fine. But let's leave it at that and keep it simple. No need to attack. We wouldn't that kind of attitude driving people away from the community or this site. Nor do we want that to reflect dimly on us among our peers and employers.
I would like to see us grow a thicker skin when reading some of these comments by certain individuals and think 3 or 4 times before posting. Maybe take a walk or swim first. If it works to wonder what your wife, daughter, mother or boss would think about the post - then do that before you post something that you have any question as to whether it is over the line or not. Of course, if you wonder if it crosses a line - it probably does.
Yes. I agree. Need to slow down and think. Maybe even try and a get a life again. I know, get my employer to send me to Afghanistan, that would put things in perspective. Not like I didn't have enough stress in my life at this time.
August 10, 2012 at 4:41 pm
Lynn Pettis (8/10/2012)
Natural keys vs Surrogate keys is one example. I have worked with a database that was designed wrong. But I had to work with what was given. It would have been nice to rewrite the application and redesign the database, but it wasn't in the cards. We didn't have the resources (people, time, or budget). Several times over an eleven year period, parts of the database that had natural keys became broken because of changes in business rules that made the natural key no longer a valid primary key. This caused problems that could have been mitigated by the use of surrogate keys. The surrogate keys would have allowed us to uniquely identified records when the original natural key no longer did.
It seems to me that you are advocating the introduction of an arbitrary value to be used as an identifier at application level (it's irrelevant that the RDBMS may provide a mechanism for generating these identifiers). Of course these values have to change, as Celko points out, when the business changes - for example when two businesses merge the "personnel number" (or "employee id or whatever you call it) will no longer be unique, so unless it changes it can't continue to identify an employee record. As this is the sort of "surrogate key" you are talking about your assertion that using surrogate keys eliminates the problem of primary keys ceasing to be unique when the business changes is wrong. If employess badges (which provide access through gates/doors and so on) have the personnel number encoded on them (perhaps as a bar code) all the badges have to be replaced, so putting that "surrogate key" on the badge was perhaps a mistake. Of course it will also sometimes be the case that business begins to make a finer dictinction that before: again, the "surrogate key" stops working. Applications (like badges) that know that surrogate key will cease to function correctly in that case too. (I'm using quotes around "surrogate key" because of course the phrase is also used for a different concept: a surrogate that is internal to the database, and not usable as a row identifier by the application. I think that was introduced by Cadiou some 36 years ago, was for along time the commonly accepted meaning of "surrogate key", and probably still is in academic circles; it too has its problems.)
If I'm wrong, tell me. Show me how I am wrong and how I can do things better. But don't attack me, don't challenge my intellect, knowledge, skills, or abilities. All you are going to do at that point is put me on the defensive and then I don't care how right you may be.
Yes, you were wrong. You claimed that your sort of surrogate key solves the problem of keys ceasing to be good identifiers; it clearly doesn't, and when JC pointed that out the only redeeming feature in your response was one of the two emoticons (the other emoticon was quite offensive).
Tom
August 10, 2012 at 4:41 pm
Oh, wait, I can't afford a life yet. I have daughter going off college this month and another going in 4 years. No money for a life. :w00t:
August 10, 2012 at 4:45 pm
Lynn Pettis (8/10/2012)
Oh, wait, I can't afford a life yet. I have daughter going off college this month and another going in 4 years. No maney for a life. :w00t:
Oh the agony!!
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 10, 2012 at 4:47 pm
SQLRNNR (8/10/2012)
Lynn Pettis (8/10/2012)
Oh, wait, I can't afford a life yet. I have daughter going off college this month and another going in 4 years. Nomaneymoney for a life. :w00t:Oh the agony!!
Oh, even better. I catch the spelling error after I get quoted! :w00t:
August 10, 2012 at 11:11 pm
L' Eomot Inversé (8/10/2012)
Lynn Pettis (8/10/2012)
Natural keys vs Surrogate keys is one example. I have worked with a database that was designed wrong. But I had to work with what was given. It would have been nice to rewrite the application and redesign the database, but it wasn't in the cards. We didn't have the resources (people, time, or budget). Several times over an eleven year period, parts of the database that had natural keys became broken because of changes in business rules that made the natural key no longer a valid primary key. This caused problems that could have been mitigated by the use of surrogate keys. The surrogate keys would have allowed us to uniquely identified records when the original natural key no longer did.It seems to me that you are advocating the introduction of an arbitrary value to be used as an identifier at application level (it's irrelevant that the RDBMS may provide a mechanism for generating these identifiers). Of course these values have to change, as Celko points out, when the business changes - for example when two businesses merge the "personnel number" (or "employee id or whatever you call it) will no longer be unique, so unless it changes it can't continue to identify an employee record. As this is the sort of "surrogate key" you are talking about your assertion that using surrogate keys eliminates the problem of primary keys ceasing to be unique when the business changes is wrong. If employess badges (which provide access through gates/doors and so on) have the personnel number encoded on them (perhaps as a bar code) all the badges have to be replaced, so putting that "surrogate key" on the badge was perhaps a mistake. Of course it will also sometimes be the case that business begins to make a finer dictinction that before: again, the "surrogate key" stops working. Applications (like badges) that know that surrogate key will cease to function correctly in that case too. (I'm using quotes around "surrogate key" because of course the phrase is also used for a different concept: a surrogate that is internal to the database, and not usable as a row identifier by the application. I think that was introduced by Cadiou some 36 years ago, was for along time the commonly accepted meaning of "surrogate key", and probably still is in academic circles; it too has its problems.)
If I'm wrong, tell me. Show me how I am wrong and how I can do things better. But don't attack me, don't challenge my intellect, knowledge, skills, or abilities. All you are going to do at that point is put me on the defensive and then I don't care how right you may be.
Yes, you were wrong. You claimed that your sort of surrogate key solves the problem of keys ceasing to be good identifiers; it clearly doesn't, and when JC pointed that out the only redeeming feature in your response was one of the two emoticons (the other emoticon was quite offensive).
You're spot on with the explanation of the surrogate key needing to change if two companies merge. However, I believe that just about any natural key that you would/could use in such a case could also suffer the same consequences if not being to a lesser extent. With that thought in mind and other the GUID (which, although the odds are high against it, no longer has the guarantee of being unique), what would you use for a key that truly prevented such problems as those which arise in a merger?
--Jeff Moden
Change is inevitable... Change for the better is not.
August 11, 2012 at 5:02 am
Jeff Moden (8/10/2012)
...what would you use for a key that truly prevented such problems as those which arise in a merger?
We ran into that exact problem when our company in Cape Town merged with a larger one in Johannesburg. Employee numbers were no longer unique. But it was quite easy to solve, they just appended a "C" to the Cape Town employee numbers before doing the merge of the two databases. And employee numbers are hardly the only issue in that case. Think about order numbers, client numbers etc... Both companies could have had the same clients, with names spelled slightly differently etc. All that needs to be reconciled.
Lowdown is, you can always create a new "Natural" key (which an employee number hardly qualifies as) by extending/modifying the two existing natural keys, as and when the need arises, then merging them. If you are relying on surrrogate keys the same applies, as long as you put some thought into it and make the changes BEFORE you merge two databases. And yes, if your employee ID is on badges etc, you'll have to reprint and reissue them. But that's part of the cost involved with a merger between two companies and should be part of the due dilligence exercise before such a merger happens anyhow. And it would be a negible one compared to all other issues involved.
August 11, 2012 at 5:13 am
Coming back to the picture that was pulled due to being politically inacceptable. Could whoever posted it there please send me a PM with the link to the original one? I'd honestly don't know why it was considered potentially offensive and would like to have a look at it again.
As a reference, have a look at how one particular cartoonist depicts our current President in the most widely read Sunday newspaper in South Africa.
Viewing 15 posts - 37,441 through 37,455 (of 66,712 total)
You must be logged in to reply to this topic. Login to reply