August 11, 2012 at 6:14 am
Jan Van der Eecken (8/11/2012)
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.
Isn't =http://4.bp.blogspot.com/_o5swS_a08j4/Sv0XX5UFrSI/AAAAAAAAEQc/NKWVzCsO0MY/s400/obama+short+bus.jpg[this it? It's the link which had replaced the embedding original when I saw it yesterday.
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.
Perhaps it hasn't become as obvious in S Africa as it is in Europe, but some people of the USA tend to have pretty extreme (and inane) political views and supporters of X will regard any suggestion that X may have some faults as profane sacrilege and react in much the manner of any religious fundamentalist. I can't for a moment imagine the USA accepting the sort of political cartoon that is a regular feature of our newspapers in the UK. Your Zapiro cartoons seem pretty mild compared to the sort of thing that the Times, the Telegraph, or the Guardian publishes.
edit: fix unmatched tags
Tom
August 11, 2012 at 7:09 am
Jeff Moden (8/10/2012)
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?
I wouldn't claim that the problem can be avoided, simply that it is just as serious with (application-visible) surrogate keys as with natural keys and that it is therefor wrong to claim that using surrogate keys instead of natural keys solves the problem. The fact that natural keys can change is something that we have to live with (and deal with when it happens) whether we use surrogate keys or not; similarly if a natural key ceases to be naturally unique we have to deal with it, whether we've used surrogate keys or not (and in this case the surrogate key has almost certainly ceased to be unique too).
Personally I do use surrogate keys where I find it appropriate, although I generally don't expose their value to the application (so they are not surrogate keys in Lynn's sense). These "invisible" surrogate keys are useful because an RDBMS like SQL Server needs some help in optimising storage of foreign keys. This is a symptom of the unhappy fact that RDBMS has not put storage design under the hood and provided clever enough optimisation that human intervention is unneccessary (personally, unlike the optimists on the 1970s, I don't think there will be such a step forward in automatic storage management for RDBMS anytime soon - after all, we still need skilled DBAs to determine how database files should be mapped onto drives and to choose which indexes should exist and which shouldn't and most people seem to regard that as a more important target than the implementation of vintage 1976 surrogate keys).
Tom
August 11, 2012 at 9:07 am
L' Eomot Inversé (8/11/2012)
I wouldn't claim that the problem can be avoided, simply that it is just as serious with (application-visible) surrogate keys as with natural keys
That's pretty much where I was getting ready to go with this... "It Depends" and neither is a panacea. Thanks, Tom.
--Jeff Moden
Change is inevitable... Change for the better is not.
August 11, 2012 at 10:20 am
L' Eomot Inversé (8/11/2012)
Jan Van der Eecken (8/11/2012)
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.Isn't =http://4.bp.blogspot.com/_o5swS_a08j4/Sv0XX5UFrSI/AAAAAAAAEQc/NKWVzCsO0MY/s400/obama+short+bus.jpg[this it? It's the link which had replaced the embedding original when I saw it yesterday.
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.
Perhaps it hasn't become as obvious in S Africa as it is in Europe, but some people of the USA tend to have pretty extreme (and inane) political views and supporters of X will regard any suggestion that X may have some faults as profane sacrilege and react in much the manner of any religious fundamentalist. I can't for a moment imagine the USA accepting the sort of political cartoon that is a regular feature of our newspapers in the UK. Your Zapiro cartoons seem pretty mild compared to the sort of thing that the Times, the Telegraph, or the Guardian publishes.
edit: fix unmatched tags
Yes, that's the link. Thanks Tom. I still don't see the issue. Maybe I'm just not privy enough as to what's going on in terms of pre-election low hitting attacks in the US. Showed it to my wife (who is a US citizen, and certainly not a Romney fan, or any Republican for that matter), but she didn't get it either. Call us ignorant if you may.
Tom, as to Zapiro being benign, have a look at these. To me those are really low-hitting. But then again I don't disagree with them. On the other side, we all who are white are racist colonialists by definition. [/rant].
August 11, 2012 at 12:56 pm
Jan Van der Eecken (8/11/2012)
Yes, that's the link. Thanks Tom. I still don't see the issue. Maybe I'm just not privy enough as to what's going on in terms of pre-election low hitting attacks in the US. Showed it to my wife (who is a US citizen, and certainly not a Romney fan, or any Republican for that matter), but she didn't get it either. Call us ignorant if you may.
I don't see the issue either (I can see two issues with having it here, embedded rather than linked, (i) that would require permission from the copyright holder and (ii) it would cause load on the referencesd site everytime the page here was accessed, not just when someone intentionally clicked the link) so I think it was a good thing it was changed to a reference. But I don't understand why anyone who is aware that political debate takes place would regard it as offensive.
Tom, as to Zapiro being benign, have a look at these. To me those are really low-hitting. But then again I don't disagree with them.
Yes, those are a bit harder-hitting than the ones you linked to previously.
On the other side, we all who are white are racist colonialists by definition. [/rant].
I don't disagree with them either (I try to read as little news as possible, because it's all so depressing, but some stuff gets through and I can see what those cartoons are getting at). I guess that makes me a white racist colonist too.
Tom
August 11, 2012 at 1:42 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).
First, I apologized for my emotional outburst.
Second, I am not really going to get into the religious debate of Surrogate Keys vs Natural Keys and which should be used and which shouldn't. I stated I liked having a surrogate key in my tables in addtion to the natural key. I worked with too many databases where the natural key suddenly no longer works as the natural (primary key) as a result of changes in the business rules/business Processes/Additional data added. Having another alternate key to help uniquely identify rows is good. Yes, it may be additional work in the application, but if well designed it helps.
Sorry if I have offended you in any way. I will strive to be more professional in the future.
August 12, 2012 at 9:40 am
I overstep the line of professionalism, apologize and say it won't happen again and Mr. Celko gets "offended" (may not be the right word, but all I can think of here) by that and doesn't want me to stop. He enjoys the sniping.
August 12, 2012 at 10:37 am
For those that enjoy this sort of thing, here is a pretty good comparison of the various running totals methods available.
http://www.sqlperformance.com/2012/07/t-sql-queries/running-totals
Wayne
Microsoft Certified Master: SQL Server 2008
Author - SQL Server T-SQL Recipes
August 12, 2012 at 1:19 pm
WayneS (8/12/2012)
For those that enjoy this sort of thing, here is a pretty good comparison of the various running totals methods available.http://www.sqlperformance.com/2012/07/t-sql-queries/running-totals
I did. Reminds me of looking up again when the quirky update will fail.
August 12, 2012 at 3:03 pm
This kind of thing:
http://www.sqlservercentral.com/Forums/Topic1343859-1292-1.aspx
Where in the world are these jobs where someone can get hired with 0 experience in the position? I don't think that kids fresh out of school shouldn't be given a chance but at the same time, if you're hired for a SQL position with no experience, then shouldn't some on the job training be expected? I see a good number of people here offering sound advice but a forum is not place to get "certified" in any specific type of discipline. Please excuse me if I'm out of line on this one but reading the OP made my head spin. My first instinct was to post a long winded reply to the OP but I stopped myself and thought this thread was the more appropriate place to vent.
August 12, 2012 at 5:37 pm
Scott D. Jacobson (8/12/2012)
This kind of thing:http://www.sqlservercentral.com/Forums/Topic1343859-1292-1.aspx
Where in the world are these jobs where someone can get hired with 0 experience in the position? I don't think that kids fresh out of school shouldn't be given a chance but at the same time, if you're hired for a SQL position with no experience, then shouldn't some on the job training be expected? I see a good number of people here offering sound advice but a forum is not place to get "certified" in any specific type of discipline. Please excuse me if I'm out of line on this one but reading the OP made my head spin. My first instinct was to post a long winded reply to the OP but I stopped myself and thought this thread was the more appropriate place to vent.
Well, if someone is realy good they can learn quickly by followng on-line tutorials and getting their hands dirty playing with the BI products. They won't be productive on day 1, of course, and it would be utterly stupid of a company to employe someone unless they intended to provide proper training (preferably in the form of mentoring and supervision, rather than formal courses by some "consultant" who probably is just parroting the books). It worries me somewhat that the OP apparently hasn't been told anything about training/mentoring. I don't know if it's different in the USA, but in the UK reputable firms tend to be quite hot on persuading their junior recruits to aim for CEng or IEng status (equivalent to PE over there, I guess), formal mentoring is very much a part of that process, and recruits know from when they get a job offer that there will be mentoring and they will be expected to learn.
I've replied on the OP's thread, hope it's some use to him but not sure it is. It would be good I think if some others could jump in and try to help.
Tom
August 12, 2012 at 5:48 pm
Thank you Tom. Now that I've had a chance to get over the initial shock I can see your response is more in line with what I think the OP needs.
August 13, 2012 at 2:11 am
WayneS (8/12/2012)
For those that enjoy this sort of thing, here is a pretty good comparison of the various running totals methods available.http://www.sqlperformance.com/2012/07/t-sql-queries/running-totals
Thanks for the link, Wayne.
It could look like Aaron Bertrand wants to provoke some reaction from Jeff again. 😛
-- Gianluca Sartori
August 13, 2012 at 9:05 am
Jeff Moden (8/11/2012)
L' Eomot Inversé (8/11/2012)
I wouldn't claim that the problem can be avoided, simply that it is just as serious with (application-visible) surrogate keys as with natural keysThat's pretty much where I was getting ready to go with this... "It Depends" and neither is a panacea. Thanks, Tom.
Agreed. That said - in my career I have run into a lot more cases of a "natural key" becoming an issue than a surrogate key becoming an issue.
Between the UPIN to NPI fiasco, followed by having to cleanse SSN's out of patient record systems, never mind several scads of supposedly "fool proof" composite natural keys that could "never" pop a duplicate, I do tend to challenge the use of keys which carry any form of business significance to the user community, relying instead on the "invisible" surrogate key concept instead.
----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?
August 13, 2012 at 9:33 am
Matt Miller (#4) (8/13/2012)
Jeff Moden (8/11/2012)
L' Eomot Inversé (8/11/2012)
I wouldn't claim that the problem can be avoided, simply that it is just as serious with (application-visible) surrogate keys as with natural keysThat's pretty much where I was getting ready to go with this... "It Depends" and neither is a panacea. Thanks, Tom.
Agreed. That said - in my career I have run into a lot more cases of a "natural key" becoming an issue than a surrgoate key becombing an issue.
Between the UPIN to NPI fiasco, followed by having to cleanse SSN's out of patient record systems, never mind several scads of supposedly "fool proof" composite natural keys that could "never" pop a duplicate, I do tend to challenge the use of keys which carry any form of business significance to the user community, relying instead on the "invisible" surrogate key concept instead.
Second the motion.
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
Viewing 15 posts - 37,456 through 37,470 (of 66,712 total)
You must be logged in to reply to this topic. Login to reply