|
database
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
I have no blogPUBLIC NOTICE:
I have no blog. I have never had a blog. I have no idea who is using my name, postings and likeness on that "SQL Apprentice" blog. As much as I detest your behavior in these groups, I find this blog
concept morally repugnant. I get the joke; somebody is posting "the best of Celko" from these groups, but they should have the guts to do it without assuming your identity. You probably don't give a damn what I think, but for once, I agree with the way you're handling this. I would probably see if there were some legal route to pursue. Stu --CELKO-- wrote: Show quote > PUBLIC NOTICE: > I have no blog. I have never had a blog. I have no idea who is using > my name, postings and likeness on that "SQL Apprentice" blog. Stu wrote:
> As much as I detest your behavior in these groups, I find this blog Actually I found it quite a handly collection of Joe's posts... yes he> concept morally repugnant. I get the joke; somebody is posting "the > best of Celko" from these groups, but they should have the guts to do > it without assuming your identity. shouldn't pretend to actually BE Joe, but aside from that it doesn't seem to be a piss-take or malcious...(though I only skimmed through it). It's not that the author of the blog is copying Joe's posts verbatim
that bothers me; it's the impersonation factor. Joe does a pretty good job of maligning his own character (in my opinion); I just think the author of the blog shouldn't give the impression that they are Joe Celko. Stu Chris Lim wrote: Show quote > Stu wrote: > > As much as I detest your behavior in these groups, I find this blog > > concept morally repugnant. I get the joke; somebody is posting "the > > best of Celko" from these groups, but they should have the guts to do > > it without assuming your identity. > > Actually I found it quite a handly collection of Joe's posts... yes he > shouldn't pretend to actually BE Joe, but aside from that it doesn't > seem to be a piss-take or malcious...(though I only skimmed through it). >> Actually I found it quite a handly collection of Joe's posts... yes he shouldn't pretend to actually BE Joe, but aside from that it doesn't seem to be a piss-take or malcious...(though I only skimmed through it). << So far, it is nothing but direct quotes from news group postings, whichare public and quotable. As long as he does not add or change anything, I do not have much to say about it. tho, I wish he would take the time to fix the spelling and grammar :) The headshot actually belongs to MKP, one of my publishers, and I have used it for ten years with their permission. And yes it does look like me; in fact I still wear the same three piece suits from the 1980's, which says a lot about my good health and bad fashion sense (want to see my Nerhu jacket? My Halston sportscoat? I still fit into things from the 1970's). Just what is the problem? If you wanted a blog could you
have done better? :) I respectfully submit only a nitwit could deduce he's assuming your identity (pardon the pun). And once you click it's in the public ear. The guy seems rather bright, creative and industrious. Now I can see punishing him for these morally repugnant and anti-social traits. So who wants to be the first one on their block to put this guy in a stock? Democracy is chaos, you give some you get some. And in the end you should feel flattered. In this case imitation (which it is not) is not the sincerest form of flattery, ridicule is:) Go Menace Go :) http://racster.blogspot.com Nice Blog Joe, and the photos ALMOST look like you too! It had me fooled...
;-) -- Arnie Rowland, Ph.D. Westwood Consulting, Inc Most good judgment comes from experience. Most experience comes from bad judgment. - Anonymous Show quote "--CELKO--" <jcelko***@earthlink.net> wrote in message news:1157855268.221004.7520@b28g2000cwb.googlegroups.com... > > PUBLIC NOTICE: > I have no blog. I have never had a blog. I have no idea who is using > my name, postings and likeness on that "SQL Apprentice" blog. > If you are that bothered by it then contact the ISP and have it removed.
Personally I didn't think you where IT literate enough to have a blog..... -- Tony Rogerson SQL Server MVP http://sqlblogcasts.com/blogs/tonyrogerson - technical commentary from a SQL Server Consultant http://sqlserverfaq.com - free video tutorials Show quote "--CELKO--" <jcelko***@earthlink.net> wrote in message news:1157855268.221004.7520@b28g2000cwb.googlegroups.com... > > PUBLIC NOTICE: > I have no blog. I have never had a blog. I have no idea who is using > my name, postings and likeness on that "SQL Apprentice" blog. > >> If you are that bothered by it then contact the ISP and have it removed. << As long as it is public quotes, I cannot do much about it. It is likeNexis, Google or any other news source. But I do not want people to think I am blogging. I have turned down offers from software companies and trade publishers to do blogs for them back it was the new hot thing. I just cannot get into doing that much writing without making money on it. I can do an article in less time I would blog for a week and get a check. I can write a book and create an income stream that lasts for decades in a few months. Yeah, there are blogs that are making 6-digit incomes with ads and subscriptions (see "in Blogging for dollars" by Paul Sloan and Paul Kaihla, Business 2.0 Magazine Sep 2006) and changing the world with political disclosures. But let's be real; most blogs are a hobby, a public service and/or an ego booster. I prefer spending time on newsgroups for my hobby and contribution to the community. Interesting stance, I doubt they are making that much out of you; there has
only been about 7,000 hits since April according your counter. If it had happened to me I'd be on to them like a shot to have it closed down. > contribution to the community. Now that really is a contradiction in terms! I guess you don't "contribute" to sell your books...... -- Tony Rogerson SQL Server MVP http://sqlblogcasts.com/blogs/tonyrogerson - technical commentary from a SQL Server Consultant http://sqlserverfaq.com - free video tutorials Show quote "--CELKO--" <jcelko***@earthlink.net> wrote in message news:1157894898.239875.234330@d34g2000cwd.googlegroups.com... >>> If you are that bothered by it then contact the ISP and have it removed. >>> << > > As long as it is public quotes, I cannot do much about it. It is like > Nexis, Google or any other news source. > > But I do not want people to think I am blogging. I have turned down > offers from software companies and trade publishers to do blogs for > them back it was the new hot thing. I just cannot get into doing that > much writing without making money on it. I can do an article in less > time I would blog for a week and get a check. I can write a book and > create an income stream that lasts for decades in a few months. > > Yeah, there are blogs that are making 6-digit incomes with ads and > subscriptions (see "in Blogging for dollars" by Paul Sloan and Paul > Kaihla, Business 2.0 Magazine Sep 2006) and changing the world with > political disclosures. But let's be real; most blogs are a hobby, a > public service and/or an ego booster. I prefer spending time on > newsgroups for my hobby and contribution to the community. > >> I guess you don't "contribute" to sell your books.. << Sure! And to get consulting work, too. But if I put the effort intopromotion instead of giving away free consulting, I would do better. Does your blog result in more or less work for you? My blog is geared around me sharing my experiences, that costs nothing; as I
learn other people learn and I also learn from their comments - its a good model that perhaps you'd benefit from (no doubt there!). > Does your blog result in more or less work for you? Not directly and that is not what my blog or what I do with the UK user group is about; note: how often do you see me give direct plugs for my consultancy (akin to direct plugs you give to your books), answer: rarely to never. -- Tony Rogerson SQL Server MVP http://sqlblogcasts.com/blogs/tonyrogerson - technical commentary from a SQL Server Consultant http://sqlserverfaq.com - free video tutorials Show quote "--CELKO--" <jcelko***@earthlink.net> wrote in message news:1157904468.478861.85280@d34g2000cwd.googlegroups.com... >>> I guess you don't "contribute" to sell your books.. << > > Sure! And to get consulting work, too. But if I put the effort into > promotion instead of giving away free consulting, I would do better. > Does your blog result in more or less work for you? > "Tony Rogerson" <tonyroger***@sqlserverfaq.com> wrote in message Yeah, I understand the concept. How often do you see me plug RAC?news:etlxMsR1GHA.4176@TK2MSFTNGP06.phx.gbl... >. > how often do you see me give direct plugs for my consultancy (akin to > direct plugs you give to your books), answer: rarely to never. best, www.rac4sql.net http://racster.blogspot.com Steve doe not plug RAC
He's not sales rep on attack On this, I know jack! -- Arnie Rowland, Ph.D. Westwood Consulting, Inc Most good judgment comes from experience. Most experience comes from bad judgment. - Anonymous -- Arnie Rowland, Ph.D. Westwood Consulting, Inc Most good judgment comes from experience. Most experience comes from bad judgment. - Anonymous Show quote "Steve Dassin" <steve@nospamrac4sql.net> wrote in message news:etq3JBS1GHA.4796@TK2MSFTNGP03.phx.gbl... > "Tony Rogerson" <tonyroger***@sqlserverfaq.com> wrote in message > news:etlxMsR1GHA.4176@TK2MSFTNGP06.phx.gbl... >>. >> how often do you see me give direct plugs for my consultancy (akin to >> direct plugs you give to your books), answer: rarely to never. > > Yeah, I understand the concept. How often do you see me plug RAC? > > best, > www.rac4sql.net > http://racster.blogspot.com > "Arnie Rowland" <ar***@1568.com> wrote in message Golden! :)news:OK7glKU1GHA.4228@TK2MSFTNGP06.phx.gbl... > Steve doe not plug RAC > He's not sales rep on attack > On this, I know jack! There once was a girl named Sue Who came up with a crosstab result out of the blue, Here an MVP came to her resue, In a way befitting a guru, To which Steve replied with a smack, As the MVP was obviously thinking sack, It's not that his answer lacked, But oh the time wasted getting back, As he would have had much better luck, Had he first thought of Rac. best, >> how often do you see me give direct plugs for my consultancy (akin to direct plugs you give to your books), answer: rarely to never. << Every signature on every posting?> Every signature on every posting? You plank - thats a link to the technical content."TECHNICAL COMMENTARY FROM <MY JOB TITLE>" "VIDEO TUTORIALS...." A tad different to "you need to get a copy of my book trees and graphs....." without actually answering the OP's post...... -- Tony Rogerson SQL Server MVP http://sqlblogcasts.com/blogs/tonyrogerson - technical commentary from a SQL Server Consultant http://sqlserverfaq.com - free video tutorials Show quote "--CELKO--" <jcelko***@earthlink.net> wrote in message news:1157924882.948772.220250@h48g2000cwc.googlegroups.com... >>> how often do you see me give direct plugs for my consultancy (akin to >>> direct plugs you give to your books), answer: rarely to never. << > > Every signature on every posting? > Perhaps I should change my signature to a list of my books instead of
the vague "consultant" and "MVP" instead? Perhaps I should add 10 years on ANSO X3H2 to balance out the "MVP" signature? Sure loooks like plug to me. Get real! If any of us wished to be "humble", we would use a false names and no links. Oh, I use no links and you do! Gee, so doI ! Et al ! Duh! One of the functions of newsgroups is to hook up newbie problems with the 30+ year old vets, the smart kids, the aread experts. etc. to gert an answer. The BADF news is that the newbie is more often than not given a kludge that gets him over his problem ( i.e. "Take more Heroin and you will not feel the pain", or "get 'er done" in the word of 'Larry the Cable Guy' on USA television's Jeff Foxwhorthy shows). Tony, you, me, Steve, and others here are pros who are looking for the next job. You are looking for a coding job for a few weeks; Steve wants a RAC sale immediately and I want a training class series on a Fortuen 500 corporate basis or code review advisor job or "evegantistic role" for a good product. The target is dependent on what level or niche we aim at. The newsgroups are a change for us to do "community service" by postings. If Tony says "get 'er done with an IDENTITY column!!" and I say "Dr. Codd.. blah, blah, so you need to look for Relational keys .. blah, blah" , the reader should Google the postings, sources, etc. and then decide. --CELKO-- wrote:
<snip> Did you put in more typo's than usual just to make your fake blog look bad? ;-) >> Did you put in more typo's than usual just to make your fake blog look bad? <, TYPOS?! No, I am just back back from my niece' sbirhtday weekendn partyand I am druuunk. I think.... Wow - what an ego..... but we all know that....
The trouble is your postings only reflect you as somebody with little real world experience, class room bound and unable to learn new techniques and ideals; your dress, ideas and attitude is stuck in the late 70's and because you don't get industry exposure you are unaware how things have changed, and my broad experience of enterprise (fortune 500) mainly banks is that they are mainly 3 - 5 years behind current technology and thinking. As for me being a coder (rflol), yes, I do occaisionnally code for clients but 90% of my work is SQL consultancy 'mentoring', 'tuning', 'reviews' and my clients are from small businesses through to fortune 500.... Tony says 'get the job done with surrogate keys' - at least get that right! I don't want all the consistency, locking and scalability problems you get when you copy the natural key (http://en.wikipedia.org/wiki/Natural_key) everywhere as the foreign key (there is no such thing as a relational key - even wikipedia.org hasn't a reference to it - when are you going to use the correct terminology so newbies can google.....); if you had done any coding you would realise it isn't practical to use composite keys inside an application. -- Tony Rogerson SQL Server MVP http://sqlblogcasts.com/blogs/tonyrogerson - technical commentary from a SQL Server Consultant http://sqlserverfaq.com - free video tutorials Show quote "--CELKO--" <jcelko***@earthlink.net> wrote in message news:1158034189.319136.262460@d34g2000cwd.googlegroups.com... > Perhaps I should change my signature to a list of my books instead of > the vague "consultant" and "MVP" instead? Perhaps I should add 10 years > on ANSO X3H2 to balance out the "MVP" signature? Sure loooks like plug > to me. > > Get real! If any of us wished to be "humble", we would use a false > names and no links. Oh, I use no links and you do! Gee, so doI ! Et > al ! > > Duh! One of the functions of newsgroups is to hook up newbie problems > with the 30+ year old vets, the smart kids, the aread experts. etc. to > gert an answer. The BADF news is that the newbie is more often than > not given a kludge that gets him over his problem ( i.e. "Take more > Heroin and you will not feel the pain", or "get 'er done" in the word > of 'Larry the Cable Guy' on USA television's Jeff Foxwhorthy shows). > > Tony, you, me, Steve, and others here are pros who are looking for the > next job. You are looking for a coding job for a few weeks; Steve > wants a RAC sale immediately and I want a training class series on a > Fortuen 500 corporate basis or code review advisor job or "evegantistic > role" for a good product. The target is dependent on what level or > niche we aim at. > > The newsgroups are a change for us to do "community service" by > postings. If Tony says "get 'er done with an IDENTITY column!!" and I > say "Dr. Codd.. blah, blah, so you need to look for Relational keys .. > blah, blah" , the reader should Google the postings, sources, etc. and > then decide. > On a side note...
Regarding using composite keys in an application, and the locking and scalability problems that come with them, would you consider this a limitation of SQL Server? I ask because I have used composite keys in applications extensively with Oracle. Oracle has a completely different approach to locking and I have never seen the sorts of problems that I see with SQL Server. Although the composite keys required more typing for the joins, it also saved time by not making me have to go through EMPLOYEES --> JOBS --> ANNUAL_REVIEWS --> REVIEW_COMMENTS in order to get the review comments for employee 123456. With surrogate keys, this is what I end up doing, but with natural, composite keys, I go straight to the review comments table. Granted, I have a 4 part key in that table without surrogates, and it takes up more space, but I find it much more intuitive than having to track surrogates all over the database. Show quote "Tony Rogerson" <tonyroger***@sqlserverfaq.com> wrote in message news:OLCrqGj1GHA.1132@TK2MSFTNGP02.phx.gbl... > Wow - what an ego..... but we all know that.... > > The trouble is your postings only reflect you as somebody with little real > world experience, class room bound and unable to learn new techniques and > ideals; your dress, ideas and attitude is stuck in the late 70's and because > you don't get industry exposure you are unaware how things have changed, and > my broad experience of enterprise (fortune 500) mainly banks is that they > are mainly 3 - 5 years behind current technology and thinking. > > As for me being a coder (rflol), yes, I do occaisionnally code for clients > but 90% of my work is SQL consultancy 'mentoring', 'tuning', 'reviews' and > my clients are from small businesses through to fortune 500.... > > Tony says 'get the job done with surrogate keys' - at least get that right! > I don't want all the consistency, locking and scalability problems you get > when you copy the natural key (http://en.wikipedia.org/wiki/Natural_key) > everywhere as the foreign key (there is no such thing as a relational key - > even wikipedia.org hasn't a reference to it - when are you going to use the > correct terminology so newbies can google.....); if you had done any coding > you would realise it isn't practical to use composite keys inside an > application. > > -- > Tony Rogerson > SQL Server MVP > http://sqlblogcasts.com/blogs/tonyrogerson - technical commentary from a SQL > Server Consultant > http://sqlserverfaq.com - free video tutorials > > > "--CELKO--" <jcelko***@earthlink.net> wrote in message > news:1158034189.319136.262460@d34g2000cwd.googlegroups.com... > > Perhaps I should change my signature to a list of my books instead of > > the vague "consultant" and "MVP" instead? Perhaps I should add 10 years > > on ANSO X3H2 to balance out the "MVP" signature? Sure loooks like plug > > to me. > > > > Get real! If any of us wished to be "humble", we would use a false > > names and no links. Oh, I use no links and you do! Gee, so doI ! Et > > al ! > > > > Duh! One of the functions of newsgroups is to hook up newbie problems > > with the 30+ year old vets, the smart kids, the aread experts. etc. to > > gert an answer. The BADF news is that the newbie is more often than > > not given a kludge that gets him over his problem ( i.e. "Take more > > Heroin and you will not feel the pain", or "get 'er done" in the word > > of 'Larry the Cable Guy' on USA television's Jeff Foxwhorthy shows). > > > > Tony, you, me, Steve, and others here are pros who are looking for the > > next job. You are looking for a coding job for a few weeks; Steve > > wants a RAC sale immediately and I want a training class series on a > > Fortuen 500 corporate basis or code review advisor job or "evegantistic > > role" for a good product. The target is dependent on what level or > > niche we aim at. > > > > The newsgroups are a change for us to do "community service" by > > postings. If Tony says "get 'er done with an IDENTITY column!!" and I > > say "Dr. Codd.. blah, blah, so you need to look for Relational keys .. > > blah, blah" , the reader should Google the postings, sources, etc. and > > then decide. > > > > Surely the data change is a problem even for Oracle? What system resources
would Oracle consume giving out the different versions of the rows.... The problem is more in the disconnected model aka browser technoligies, how do you know that 'yournaturalkey' is really still the row that you pulled down (and disconnected from server with)? How do you know that the key hasn't been modified since you last checked? You can't use timestamps because the key you are using might be pointing to a different row..... Consider the html <select> tag, how do you specify composite keys for the value clause? CSV is very clunky..... Far easier and safer to disconnect the 'meta' that is the natural key data by using surrogate keys throughout the application and within the foreign key relationships -- Tony Rogerson SQL Server MVP http://sqlblogcasts.com/blogs/tonyrogerson - technical commentary from a SQL Server Consultant http://sqlserverfaq.com - free video tutorials Show quote "Jim Underwood" <james.underwoodATfallonclinic.com> wrote in message news:%23LIPk8m1GHA.2036@TK2MSFTNGP05.phx.gbl... > On a side note... > > Regarding using composite keys in an application, and the locking and > scalability problems that come with them, would you consider this a > limitation of SQL Server? > > I ask because I have used composite keys in applications extensively with > Oracle. Oracle has a completely different approach to locking and I have > never seen the sorts of problems that I see with SQL Server. Although the > composite keys required more typing for the joins, it also saved time by > not > making me have to go through EMPLOYEES --> JOBS --> ANNUAL_REVIEWS --> > REVIEW_COMMENTS in order to get the review comments for employee 123456. > With surrogate keys, this is what I end up doing, but with natural, > composite keys, I go straight to the review comments table. Granted, I > have > a 4 part key in that table without surrogates, and it takes up more space, > but I find it much more intuitive than having to track surrogates all over > the database. > > > > "Tony Rogerson" <tonyroger***@sqlserverfaq.com> wrote in message > news:OLCrqGj1GHA.1132@TK2MSFTNGP02.phx.gbl... >> Wow - what an ego..... but we all know that.... >> >> The trouble is your postings only reflect you as somebody with little >> real >> world experience, class room bound and unable to learn new techniques and >> ideals; your dress, ideas and attitude is stuck in the late 70's and > because >> you don't get industry exposure you are unaware how things have changed, > and >> my broad experience of enterprise (fortune 500) mainly banks is that they >> are mainly 3 - 5 years behind current technology and thinking. >> >> As for me being a coder (rflol), yes, I do occaisionnally code for >> clients >> but 90% of my work is SQL consultancy 'mentoring', 'tuning', 'reviews' >> and >> my clients are from small businesses through to fortune 500.... >> >> Tony says 'get the job done with surrogate keys' - at least get that > right! >> I don't want all the consistency, locking and scalability problems you >> get >> when you copy the natural key (http://en.wikipedia.org/wiki/Natural_key) >> everywhere as the foreign key (there is no such thing as a relational > key - >> even wikipedia.org hasn't a reference to it - when are you going to use > the >> correct terminology so newbies can google.....); if you had done any > coding >> you would realise it isn't practical to use composite keys inside an >> application. >> >> -- >> Tony Rogerson >> SQL Server MVP >> http://sqlblogcasts.com/blogs/tonyrogerson - technical commentary from a > SQL >> Server Consultant >> http://sqlserverfaq.com - free video tutorials >> >> >> "--CELKO--" <jcelko***@earthlink.net> wrote in message >> news:1158034189.319136.262460@d34g2000cwd.googlegroups.com... >> > Perhaps I should change my signature to a list of my books instead of >> > the vague "consultant" and "MVP" instead? Perhaps I should add 10 years >> > on ANSO X3H2 to balance out the "MVP" signature? Sure loooks like plug >> > to me. >> > >> > Get real! If any of us wished to be "humble", we would use a false >> > names and no links. Oh, I use no links and you do! Gee, so doI ! Et >> > al ! >> > >> > Duh! One of the functions of newsgroups is to hook up newbie problems >> > with the 30+ year old vets, the smart kids, the aread experts. etc. to >> > gert an answer. The BADF news is that the newbie is more often than >> > not given a kludge that gets him over his problem ( i.e. "Take more >> > Heroin and you will not feel the pain", or "get 'er done" in the word >> > of 'Larry the Cable Guy' on USA television's Jeff Foxwhorthy shows). >> > >> > Tony, you, me, Steve, and others here are pros who are looking for the >> > next job. You are looking for a coding job for a few weeks; Steve >> > wants a RAC sale immediately and I want a training class series on a >> > Fortuen 500 corporate basis or code review advisor job or "evegantistic >> > role" for a good product. The target is dependent on what level or >> > niche we aim at. >> > >> > The newsgroups are a change for us to do "community service" by >> > postings. If Tony says "get 'er done with an IDENTITY column!!" and I >> > say "Dr. Codd.. blah, blah, so you need to look for Relational keys .. >> > blah, blah" , the reader should Google the postings, sources, etc. and >> > then decide. >> > >> >> > > > making me have to go through EMPLOYEES --> JOBS --> ANNUAL_REVIEWS --> Why? The application would pass back the surrogate employee_id 123456 and > REVIEW_COMMENTS in order to get the review comments for employee 123456. you'd only join back out to get the meta data....So, even lookups are quicker.... -- Tony Rogerson SQL Server MVP http://sqlblogcasts.com/blogs/tonyrogerson - technical commentary from a SQL Server Consultant http://sqlserverfaq.com - free video tutorials Show quote "Jim Underwood" <james.underwoodATfallonclinic.com> wrote in message news:%23LIPk8m1GHA.2036@TK2MSFTNGP05.phx.gbl... > On a side note... > > Regarding using composite keys in an application, and the locking and > scalability problems that come with them, would you consider this a > limitation of SQL Server? > > I ask because I have used composite keys in applications extensively with > Oracle. Oracle has a completely different approach to locking and I have > never seen the sorts of problems that I see with SQL Server. Although the > composite keys required more typing for the joins, it also saved time by > not > making me have to go through EMPLOYEES --> JOBS --> ANNUAL_REVIEWS --> > REVIEW_COMMENTS in order to get the review comments for employee 123456. > With surrogate keys, this is what I end up doing, but with natural, > composite keys, I go straight to the review comments table. Granted, I > have > a 4 part key in that table without surrogates, and it takes up more space, > but I find it much more intuitive than having to track surrogates all over > the database. > > > > "Tony Rogerson" <tonyroger***@sqlserverfaq.com> wrote in message > news:OLCrqGj1GHA.1132@TK2MSFTNGP02.phx.gbl... >> Wow - what an ego..... but we all know that.... >> >> The trouble is your postings only reflect you as somebody with little >> real >> world experience, class room bound and unable to learn new techniques and >> ideals; your dress, ideas and attitude is stuck in the late 70's and > because >> you don't get industry exposure you are unaware how things have changed, > and >> my broad experience of enterprise (fortune 500) mainly banks is that they >> are mainly 3 - 5 years behind current technology and thinking. >> >> As for me being a coder (rflol), yes, I do occaisionnally code for >> clients >> but 90% of my work is SQL consultancy 'mentoring', 'tuning', 'reviews' >> and >> my clients are from small businesses through to fortune 500.... >> >> Tony says 'get the job done with surrogate keys' - at least get that > right! >> I don't want all the consistency, locking and scalability problems you >> get >> when you copy the natural key (http://en.wikipedia.org/wiki/Natural_key) >> everywhere as the foreign key (there is no such thing as a relational > key - >> even wikipedia.org hasn't a reference to it - when are you going to use > the >> correct terminology so newbies can google.....); if you had done any > coding >> you would realise it isn't practical to use composite keys inside an >> application. >> >> -- >> Tony Rogerson >> SQL Server MVP >> http://sqlblogcasts.com/blogs/tonyrogerson - technical commentary from a > SQL >> Server Consultant >> http://sqlserverfaq.com - free video tutorials >> >> >> "--CELKO--" <jcelko***@earthlink.net> wrote in message >> news:1158034189.319136.262460@d34g2000cwd.googlegroups.com... >> > Perhaps I should change my signature to a list of my books instead of >> > the vague "consultant" and "MVP" instead? Perhaps I should add 10 years >> > on ANSO X3H2 to balance out the "MVP" signature? Sure loooks like plug >> > to me. >> > >> > Get real! If any of us wished to be "humble", we would use a false >> > names and no links. Oh, I use no links and you do! Gee, so doI ! Et >> > al ! >> > >> > Duh! One of the functions of newsgroups is to hook up newbie problems >> > with the 30+ year old vets, the smart kids, the aread experts. etc. to >> > gert an answer. The BADF news is that the newbie is more often than >> > not given a kludge that gets him over his problem ( i.e. "Take more >> > Heroin and you will not feel the pain", or "get 'er done" in the word >> > of 'Larry the Cable Guy' on USA television's Jeff Foxwhorthy shows). >> > >> > Tony, you, me, Steve, and others here are pros who are looking for the >> > next job. You are looking for a coding job for a few weeks; Steve >> > wants a RAC sale immediately and I want a training class series on a >> > Fortuen 500 corporate basis or code review advisor job or "evegantistic >> > role" for a good product. The target is dependent on what level or >> > niche we aim at. >> > >> > The newsgroups are a change for us to do "community service" by >> > postings. If Tony says "get 'er done with an IDENTITY column!!" and I >> > say "Dr. Codd.. blah, blah, so you need to look for Relational keys .. >> > blah, blah" , the reader should Google the postings, sources, etc. and >> > then decide. >> > >> >> > > Tony,
Actually, I treat employee ID as a natural key, which may be incorrect in itself, but that's a different topic. In this case, with surrogate keys, I would use the employee Id to look up the surrogate keys in the JOBS table, which I would use to look up the surrogate keys in the ANNUAL_REVIEWS table, which I would use to look up the comments for those reviews in the REVIEW_COMMENTS table. With natuaral keys (again, I count employee ID as a natural key) I would simply get all of the rows from REVIEW_COMMENTS with EMPLOYEE_ID as part of it's composite key. Once I had retrieved the rows, the rest of the key (ReviewDate, ReviewSequence if more than one per date, and comment line) would tell me everything I needed to know about that review. As for changing data, if the natural key changes while I am trying to update that row, how will I update the row? This is a good point that you make, but here is another. If the natural key changed, even though the surrogate remains the same, how do I know that I still want to update that row? Surely I selected it based on the data that makes up the natural key, and not on the surrogate key? If the natural key changes, so does the basis of the entity which it represents. Subsequent attempts to update these rows should fail, IMO, and the user should be prompted to reload the data and make the change again. If I am updating an employees record, and correcting his job title in JOBS for a date of 1/1/2001, and someone else corrects that date to be 6/1/2002, I do not want to reupdate the updated record, which was just corrected. Now, if you are speaking about employees having a surrogate of employeeID, or vehicles having a VIN#, this is very different (IMO) than placing an IDENTITY column on every table (which some do recomend). To me, both of those IDs are characteristics of the entity, rather than surrogate keys. Show quote "Tony Rogerson" <tonyroger***@sqlserverfaq.com> wrote in message (http://en.wikipedia.org/wiki/Natural_key)news:%232%233Dnn1GHA.4452@TK2MSFTNGP02.phx.gbl... > > making me have to go through EMPLOYEES --> JOBS --> ANNUAL_REVIEWS --> > > REVIEW_COMMENTS in order to get the review comments for employee 123456. > > Why? The application would pass back the surrogate employee_id 123456 and > you'd only join back out to get the meta data....So, even lookups are > quicker.... > > -- > Tony Rogerson > SQL Server MVP > http://sqlblogcasts.com/blogs/tonyrogerson - technical commentary from a SQL > Server Consultant > http://sqlserverfaq.com - free video tutorials > > > "Jim Underwood" <james.underwoodATfallonclinic.com> wrote in message > news:%23LIPk8m1GHA.2036@TK2MSFTNGP05.phx.gbl... > > On a side note... > > > > Regarding using composite keys in an application, and the locking and > > scalability problems that come with them, would you consider this a > > limitation of SQL Server? > > > > I ask because I have used composite keys in applications extensively with > > Oracle. Oracle has a completely different approach to locking and I have > > never seen the sorts of problems that I see with SQL Server. Although the > > composite keys required more typing for the joins, it also saved time by > > not > > making me have to go through EMPLOYEES --> JOBS --> ANNUAL_REVIEWS --> > > REVIEW_COMMENTS in order to get the review comments for employee 123456. > > With surrogate keys, this is what I end up doing, but with natural, > > composite keys, I go straight to the review comments table. Granted, I > > have > > a 4 part key in that table without surrogates, and it takes up more space, > > but I find it much more intuitive than having to track surrogates all over > > the database. > > > > > > > > "Tony Rogerson" <tonyroger***@sqlserverfaq.com> wrote in message > > news:OLCrqGj1GHA.1132@TK2MSFTNGP02.phx.gbl... > >> Wow - what an ego..... but we all know that.... > >> > >> The trouble is your postings only reflect you as somebody with little > >> real > >> world experience, class room bound and unable to learn new techniques and > >> ideals; your dress, ideas and attitude is stuck in the late 70's and > > because > >> you don't get industry exposure you are unaware how things have changed, > > and > >> my broad experience of enterprise (fortune 500) mainly banks is that they > >> are mainly 3 - 5 years behind current technology and thinking. > >> > >> As for me being a coder (rflol), yes, I do occaisionnally code for > >> clients > >> but 90% of my work is SQL consultancy 'mentoring', 'tuning', 'reviews' > >> and > >> my clients are from small businesses through to fortune 500.... > >> > >> Tony says 'get the job done with surrogate keys' - at least get that > > right! > >> I don't want all the consistency, locking and scalability problems you > >> get > >> when you copy the natural key Show quote > >> everywhere as the foreign key (there is no such thing as a relational > > key - > >> even wikipedia.org hasn't a reference to it - when are you going to use > > the > >> correct terminology so newbies can google.....); if you had done any > > coding > >> you would realise it isn't practical to use composite keys inside an > >> application. > >> > >> -- > >> Tony Rogerson > >> SQL Server MVP > >> http://sqlblogcasts.com/blogs/tonyrogerson - technical commentary from a > > SQL > >> Server Consultant > >> http://sqlserverfaq.com - free video tutorials > >> > >> > >> "--CELKO--" <jcelko***@earthlink.net> wrote in message > >> news:1158034189.319136.262460@d34g2000cwd.googlegroups.com... > >> > Perhaps I should change my signature to a list of my books instead of > >> > the vague "consultant" and "MVP" instead? Perhaps I should add 10 years > >> > on ANSO X3H2 to balance out the "MVP" signature? Sure loooks like plug > >> > to me. > >> > > >> > Get real! If any of us wished to be "humble", we would use a false > >> > names and no links. Oh, I use no links and you do! Gee, so doI ! Et > >> > al ! > >> > > >> > Duh! One of the functions of newsgroups is to hook up newbie problems > >> > with the 30+ year old vets, the smart kids, the aread experts. etc. to > >> > gert an answer. The BADF news is that the newbie is more often than > >> > not given a kludge that gets him over his problem ( i.e. "Take more > >> > Heroin and you will not feel the pain", or "get 'er done" in the word > >> > of 'Larry the Cable Guy' on USA television's Jeff Foxwhorthy shows). > >> > > >> > Tony, you, me, Steve, and others here are pros who are looking for the > >> > next job. You are looking for a coding job for a few weeks; Steve > >> > wants a RAC sale immediately and I want a training class series on a > >> > Fortuen 500 corporate basis or code review advisor job or "evegantistic > >> > role" for a good product. The target is dependent on what level or > >> > niche we aim at. > >> > > >> > The newsgroups are a change for us to do "community service" by > >> > postings. If Tony says "get 'er done with an IDENTITY column!!" and I > >> > say "Dr. Codd.. blah, blah, so you need to look for Relational keys ... > >> > blah, blah" , the reader should Google the postings, sources, etc. and > >> > then decide. > >> > > >> > >> > > > > > > Employee ID is an actual surrogate key! The real 'natural key' to an
employee would surely be something like national insurance number? I'll try and blog about it with some examples, it sounds as though you are using the surrogate approach anyway! > but here is another. If the natural key changed, even though the You can timestamp the rows so on your trip back to the server to change the > surrogate > remains the same, how do I know that I still want to update that row? > Surely I selected it based on the data that makes up the natural key, and row you can check the row hasn't been updated using the timestamps (datetime). From that point on its a business decision as to what happens, most of the time the user will enter another row or try anyway and then enter into a complete user confusion stage.... Without the timestamp, imagine the situation that the natural key got changed to something else but a user entered a new record with the same old natural key, then the user (thinking they are updating the original row) goes and updates - ouch; these problems cannot happen when using the surrogate key approach because you can always pinpoint the 'correct' record and use techniques such as the datetime (last updated) to detect row updates... > Now, if you are speaking about employees having a surrogate of employeeID, This is where celko likes to try and be clever because he just doesn't get > or vehicles having a VIN#, this is very different (IMO) than placing an > IDENTITY column on every table (which some do recomend). To me, both of > those IDs are characteristics of the entity, rather than surrogate keys. the implementation phase. I say all tables should have a surrogate and in a non-distributed database the best way to do that is with IDENTITY, all tables should also (where one exists and lets face it not everything has a 'practical' natural key) be a natural key - you use a primary key constraint on the natural key and a unqiue constraint on the surrogate (IDENTITY). Tony. -- Tony Rogerson SQL Server MVP http://sqlblogcasts.com/blogs/tonyrogerson - technical commentary from a SQL Server Consultant http://sqlserverfaq.com - free video tutorials Show quote "Jim Underwood" <james.underwoodATfallonclinic.com> wrote in message news:eAuGt4n1GHA.1292@TK2MSFTNGP03.phx.gbl... > Tony, > Actually, I treat employee ID as a natural key, which may be incorrect in > itself, but that's a different topic. > > In this case, with surrogate keys, I would use the employee Id to look up > the surrogate keys in the JOBS table, which I would use to look up the > surrogate keys in the ANNUAL_REVIEWS table, which I would use to look up > the > comments for those reviews in the REVIEW_COMMENTS table. > > With natuaral keys (again, I count employee ID as a natural key) I would > simply get all of the rows from REVIEW_COMMENTS with EMPLOYEE_ID as part > of > it's composite key. Once I had retrieved the rows, the rest of the key > (ReviewDate, ReviewSequence if more than one per date, and comment line) > would tell me everything I needed to know about that review. > > As for changing data, if the natural key changes while I am trying to > update > that row, how will I update the row? This is a good point that you make, > but here is another. If the natural key changed, even though the > surrogate > remains the same, how do I know that I still want to update that row? > Surely I selected it based on the data that makes up the natural key, and > not on the surrogate key? If the natural key changes, so does the basis > of > the entity which it represents. Subsequent attempts to update these rows > should fail, IMO, and the user should be prompted to reload the data and > make the change again. If I am updating an employees record, and > correcting > his job title in JOBS for a date of 1/1/2001, and someone else corrects > that > date to be 6/1/2002, I do not want to reupdate the updated record, which > was > just corrected. > > Now, if you are speaking about employees having a surrogate of employeeID, > or vehicles having a VIN#, this is very different (IMO) than placing an > IDENTITY column on every table (which some do recomend). To me, both of > those IDs are characteristics of the entity, rather than surrogate keys. > > > > "Tony Rogerson" <tonyroger***@sqlserverfaq.com> wrote in message > news:%232%233Dnn1GHA.4452@TK2MSFTNGP02.phx.gbl... >> > making me have to go through EMPLOYEES --> JOBS --> ANNUAL_REVIEWS --> >> > REVIEW_COMMENTS in order to get the review comments for employee >> > 123456. >> >> Why? The application would pass back the surrogate employee_id 123456 and >> you'd only join back out to get the meta data....So, even lookups are >> quicker.... >> >> -- >> Tony Rogerson >> SQL Server MVP >> http://sqlblogcasts.com/blogs/tonyrogerson - technical commentary from a > SQL >> Server Consultant >> http://sqlserverfaq.com - free video tutorials >> >> >> "Jim Underwood" <james.underwoodATfallonclinic.com> wrote in message >> news:%23LIPk8m1GHA.2036@TK2MSFTNGP05.phx.gbl... >> > On a side note... >> > >> > Regarding using composite keys in an application, and the locking and >> > scalability problems that come with them, would you consider this a >> > limitation of SQL Server? >> > >> > I ask because I have used composite keys in applications extensively > with >> > Oracle. Oracle has a completely different approach to locking and I > have >> > never seen the sorts of problems that I see with SQL Server. Although > the >> > composite keys required more typing for the joins, it also saved time >> > by >> > not >> > making me have to go through EMPLOYEES --> JOBS --> ANNUAL_REVIEWS --> >> > REVIEW_COMMENTS in order to get the review comments for employee >> > 123456. >> > With surrogate keys, this is what I end up doing, but with natural, >> > composite keys, I go straight to the review comments table. Granted, I >> > have >> > a 4 part key in that table without surrogates, and it takes up more > space, >> > but I find it much more intuitive than having to track surrogates all > over >> > the database. >> > >> > >> > >> > "Tony Rogerson" <tonyroger***@sqlserverfaq.com> wrote in message >> > news:OLCrqGj1GHA.1132@TK2MSFTNGP02.phx.gbl... >> >> Wow - what an ego..... but we all know that.... >> >> >> >> The trouble is your postings only reflect you as somebody with little >> >> real >> >> world experience, class room bound and unable to learn new techniques > and >> >> ideals; your dress, ideas and attitude is stuck in the late 70's and >> > because >> >> you don't get industry exposure you are unaware how things have > changed, >> > and >> >> my broad experience of enterprise (fortune 500) mainly banks is that > they >> >> are mainly 3 - 5 years behind current technology and thinking. >> >> >> >> As for me being a coder (rflol), yes, I do occaisionnally code for >> >> clients >> >> but 90% of my work is SQL consultancy 'mentoring', 'tuning', 'reviews' >> >> and >> >> my clients are from small businesses through to fortune 500.... >> >> >> >> Tony says 'get the job done with surrogate keys' - at least get that >> > right! >> >> I don't want all the consistency, locking and scalability problems you >> >> get >> >> when you copy the natural key > (http://en.wikipedia.org/wiki/Natural_key) >> >> everywhere as the foreign key (there is no such thing as a relational >> > key - >> >> even wikipedia.org hasn't a reference to it - when are you going to >> >> use >> > the >> >> correct terminology so newbies can google.....); if you had done any >> > coding >> >> you would realise it isn't practical to use composite keys inside an >> >> application. >> >> >> >> -- >> >> Tony Rogerson >> >> SQL Server MVP >> >> http://sqlblogcasts.com/blogs/tonyrogerson - technical commentary from > a >> > SQL >> >> Server Consultant >> >> http://sqlserverfaq.com - free video tutorials >> >> >> >> >> >> "--CELKO--" <jcelko***@earthlink.net> wrote in message >> >> news:1158034189.319136.262460@d34g2000cwd.googlegroups.com... >> >> > Perhaps I should change my signature to a list of my books instead >> >> > of >> >> > the vague "consultant" and "MVP" instead? Perhaps I should add 10 > years >> >> > on ANSO X3H2 to balance out the "MVP" signature? Sure loooks like > plug >> >> > to me. >> >> > >> >> > Get real! If any of us wished to be "humble", we would use a false >> >> > names and no links. Oh, I use no links and you do! Gee, so doI ! > Et >> >> > al ! >> >> > >> >> > Duh! One of the functions of newsgroups is to hook up newbie > problems >> >> > with the 30+ year old vets, the smart kids, the aread experts. etc. > to >> >> > gert an answer. The BADF news is that the newbie is more often than >> >> > not given a kludge that gets him over his problem ( i.e. "Take >> >> > more >> >> > Heroin and you will not feel the pain", or "get 'er done" in the >> >> > word >> >> > of 'Larry the Cable Guy' on USA television's Jeff Foxwhorthy shows). >> >> > >> >> > Tony, you, me, Steve, and others here are pros who are looking for > the >> >> > next job. You are looking for a coding job for a few weeks; Steve >> >> > wants a RAC sale immediately and I want a training class series on a >> >> > Fortuen 500 corporate basis or code review advisor job or > "evegantistic >> >> > role" for a good product. The target is dependent on what level or >> >> > niche we aim at. >> >> > >> >> > The newsgroups are a change for us to do "community service" by >> >> > postings. If Tony says "get 'er done with an IDENTITY column!!" >> >> > and > I >> >> > say "Dr. Codd.. blah, blah, so you need to look for Relational keys > .. >> >> > blah, blah" , the reader should Google the postings, sources, etc. > and >> >> > then decide. >> >> > >> >> >> >> >> > >> > >> >> > > Ahhhh... I think I understand where you are coming from. You keep the
natural key on the table, but supplement it with a surrogate key. This provides a layer of redundancy by which you can verify key changes, and act according to your business needs. In Oracle, you would use ROWID, which is essentially a GUID that uniquely identifies every row (perhaps like a bookmark in a clustered index). You can select a rowid FOR UPDATE to insure no one changes it while you are working with it, or you can simply check the rowid when you go back to the database to see if it was updated. Now IIRC, the rowid will change if the row is updated or deleted, so you can't reference it from day to day, but because it is a GUID you can be certain that if it is still there, then no one touched the row. Instead of IDENTITY Oracle has SEQUENCE, which requires a little extra coding as it is not tied to a table, but rather is an independent object. Show quote "Tony Rogerson" <tonyroger***@sqlserverfaq.com> wrote in message news:e0fGPAo1GHA.3908@TK2MSFTNGP05.phx.gbl... > Employee ID is an actual surrogate key! The real 'natural key' to an > employee would surely be something like national insurance number? > > I'll try and blog about it with some examples, it sounds as though you are > using the surrogate approach anyway! > > > but here is another. If the natural key changed, even though the > > surrogate > > remains the same, how do I know that I still want to update that row? > > Surely I selected it based on the data that makes up the natural key, and > > You can timestamp the rows so on your trip back to the server to change the > row you can check the row hasn't been updated using the timestamps > (datetime). From that point on its a business decision as to what happens, > most of the time the user will enter another row or try anyway and then > enter into a complete user confusion stage.... > > Without the timestamp, imagine the situation that the natural key got > changed to something else but a user entered a new record with the same old > natural key, then the user (thinking they are updating the original row) > goes and updates - ouch; these problems cannot happen when using the > surrogate key approach because you can always pinpoint the 'correct' record > and use techniques such as the datetime (last updated) to detect row > updates... > > > Now, if you are speaking about employees having a surrogate of employeeID, > > or vehicles having a VIN#, this is very different (IMO) than placing an > > IDENTITY column on every table (which some do recomend). To me, both of > > those IDs are characteristics of the entity, rather than surrogate keys. > > This is where celko likes to try and be clever because he just doesn't get > the implementation phase. > > I say all tables should have a surrogate and in a non-distributed database > the best way to do that is with IDENTITY, all tables should also (where one > exists and lets face it not everything has a 'practical' natural key) be a > natural key - you use a primary key constraint on the natural key and a > unqiue constraint on the surrogate (IDENTITY). > > Tony. > > -- > Tony Rogerson > SQL Server MVP > http://sqlblogcasts.com/blogs/tonyrogerson - technical commentary from a SQL > Server Consultant > http://sqlserverfaq.com - free video tutorials > > > "Jim Underwood" <james.underwoodATfallonclinic.com> wrote in message > news:eAuGt4n1GHA.1292@TK2MSFTNGP03.phx.gbl... > > Tony, > > Actually, I treat employee ID as a natural key, which may be incorrect in > > itself, but that's a different topic. > > > > In this case, with surrogate keys, I would use the employee Id to look up > > the surrogate keys in the JOBS table, which I would use to look up the > > surrogate keys in the ANNUAL_REVIEWS table, which I would use to look up > > the > > comments for those reviews in the REVIEW_COMMENTS table. > > > > With natuaral keys (again, I count employee ID as a natural key) I would > > simply get all of the rows from REVIEW_COMMENTS with EMPLOYEE_ID as part > > of > > it's composite key. Once I had retrieved the rows, the rest of the key > > (ReviewDate, ReviewSequence if more than one per date, and comment line) > > would tell me everything I needed to know about that review. > > > > As for changing data, if the natural key changes while I am trying to > > update > > that row, how will I update the row? This is a good point that you make, > > but here is another. If the natural key changed, even though the > > surrogate > > remains the same, how do I know that I still want to update that row? > > Surely I selected it based on the data that makes up the natural key, and > > not on the surrogate key? If the natural key changes, so does the basis > > of > > the entity which it represents. Subsequent attempts to update these rows > > should fail, IMO, and the user should be prompted to reload the data and > > make the change again. If I am updating an employees record, and > > correcting > > his job title in JOBS for a date of 1/1/2001, and someone else corrects > > that > > date to be 6/1/2002, I do not want to reupdate the updated record, which > > was > > just corrected. > > > > Now, if you are speaking about employees having a surrogate of employeeID, > > or vehicles having a VIN#, this is very different (IMO) than placing an > > IDENTITY column on every table (which some do recomend). To me, both of > > those IDs are characteristics of the entity, rather than surrogate keys. > > > > > > > > "Tony Rogerson" <tonyroger***@sqlserverfaq.com> wrote in message > > news:%232%233Dnn1GHA.4452@TK2MSFTNGP02.phx.gbl... > >> > making me have to go through EMPLOYEES --> JOBS --> ANNUAL_REVIEWS --> > >> > REVIEW_COMMENTS in order to get the review comments for employee > >> > 123456. > >> > >> Why? The application would pass back the surrogate employee_id 123456 and > >> you'd only join back out to get the meta data....So, even lookups are > >> quicker.... > >> > >> -- > >> Tony Rogerson > >> SQL Server MVP > >> http://sqlblogcasts.com/blogs/tonyrogerson - technical commentary from a > > SQL > >> Server Consultant > >> http://sqlserverfaq.com - free video tutorials > >> > >> > >> "Jim Underwood" <james.underwoodATfallonclinic.com> wrote in message > >> news:%23LIPk8m1GHA.2036@TK2MSFTNGP05.phx.gbl... > >> > On a side note... > >> > > >> > Regarding using composite keys in an application, and the locking and > >> > scalability problems that come with them, would you consider this a > >> > limitation of SQL Server? > >> > > >> > I ask because I have used composite keys in applications extensively > > with > >> > Oracle. Oracle has a completely different approach to locking and I > > have > >> > never seen the sorts of problems that I see with SQL Server. Although > > the > >> > composite keys required more typing for the joins, it also saved time > >> > by > >> > not > >> > making me have to go through EMPLOYEES --> JOBS --> ANNUAL_REVIEWS --> > >> > REVIEW_COMMENTS in order to get the review comments for employee > >> > 123456. > >> > With surrogate keys, this is what I end up doing, but with natural, > >> > composite keys, I go straight to the review comments table. Granted, I > >> > have > >> > a 4 part key in that table without surrogates, and it takes up more > > space, > >> > but I find it much more intuitive than having to track surrogates all > > over > >> > the database. > >> > > >> > > >> > > >> > "Tony Rogerson" <tonyroger***@sqlserverfaq.com> wrote in message > >> > news:OLCrqGj1GHA.1132@TK2MSFTNGP02.phx.gbl... > >> >> Wow - what an ego..... but we all know that.... > >> >> > >> >> The trouble is your postings only reflect you as somebody with little > >> >> real > >> >> world experience, class room bound and unable to learn new techniques > > and > >> >> ideals; your dress, ideas and attitude is stuck in the late 70's and > >> > because > >> >> you don't get industry exposure you are unaware how things have > > changed, > >> > and > >> >> my broad experience of enterprise (fortune 500) mainly banks is that > > they > >> >> are mainly 3 - 5 years behind current technology and thinking. > >> >> > >> >> As for me being a coder (rflol), yes, I do occaisionnally code for > >> >> clients > >> >> but 90% of my work is SQL consultancy 'mentoring', 'tuning', 'reviews' > >> >> and > >> >> my clients are from small businesses through to fortune 500.... > >> >> > >> >> Tony says 'get the job done with surrogate keys' - at least get that > >> > right! > >> >> I don't want all the consistency, locking and scalability problems you > >> >> get > >> >> when you copy the natural key > > (http://en.wikipedia.org/wiki/Natural_key) > >> >> everywhere as the foreign key (there is no such thing as a relational > >> > key - > >> >> even wikipedia.org hasn't a reference to it - when are you going to > >> >> use > >> > the > >> >> correct terminology so newbies can google.....); if you had done any > >> > coding > >> >> you would realise it isn't practical to use composite keys inside an > >> >> application. > >> >> > >> >> -- > >> >> Tony Rogerson > >> >> SQL Server MVP > >> >> http://sqlblogcasts.com/blogs/tonyrogerson - technical commentary from > > a > >> > SQL > >> >> Server Consultant > >> >> http://sqlserverfaq.com - free video tutorials > >> >> > >> >> > >> >> "--CELKO--" <jcelko***@earthlink.net> wrote in message > >> >> news:1158034189.319136.262460@d34g2000cwd.googlegroups.com... > >> >> > Perhaps I should change my signature to a list of my books instead > >> >> > of > >> >> > the vague "consultant" and "MVP" instead? Perhaps I should add 10 > > years > >> >> > on ANSO X3H2 to balance out the "MVP" signature? Sure loooks like > > plug > >> >> > to me. > >> >> > > >> >> > Get real! If any of us wished to be "humble", we would use a false > >> >> > names and no links. Oh, I use no links and you do! Gee, so doI ! > > Et > >> >> > al ! > >> >> > > >> >> > Duh! One of the functions of newsgroups is to hook up newbie > > problems > >> >> > with the 30+ year old vets, the smart kids, the aread experts. etc. > > to > >> >> > gert an answer. The BADF news is that the newbie is more often than > >> >> > not given a kludge that gets him over his problem ( i.e. "Take > >> >> > more > >> >> > Heroin and you will not feel the pain", or "get 'er done" in the > >> >> > word > >> >> > of 'Larry the Cable Guy' on USA television's Jeff Foxwhorthy shows). > >> >> > > >> >> > Tony, you, me, Steve, and others here are pros who are looking for > > the > >> >> > next job. You are looking for a coding job for a few weeks; Steve > >> >> > wants a RAC sale immediately and I want a training class series on a > >> >> > Fortuen 500 corporate basis or code review advisor job or > > "evegantistic > >> >> > role" for a good product. The target is dependent on what level or > >> >> > niche we aim at. > >> >> > > >> >> > The newsgroups are a change for us to do "community service" by > >> >> > postings. If Tony says "get 'er done with an IDENTITY column!!" > >> >> > and > > I > >> >> > say "Dr. Codd.. blah, blah, so you need to look for Relational keys > > .. > >> >> > blah, blah" , the reader should Google the postings, sources, etc. > > and > >> >> > then decide. > >> >> > > >> >> > >> >> > >> > > >> > > >> > >> > > > > > > The arguments over natural vs. surrogate keys is always one that seems to be
very convoluted and improperly presented. One could easily and eloquently argue that a National_ID, or VIN, or SSN, or Tax_ID, etc., are only surrogate keys created by and imported from another system, and are not NATURAL characteristics of the entity. In fact, I posit that attempting to identify individuals using only natural keys would be so unwieldy as to be impractical. Some form of surrogate keys will have to be introduced, or created, in order to efficiently handle the data. I ask, and this is a million dollar question, what combination of characteristics will absolutely, positively identify an individual WITHOUT resorting to the use of a surrogate key? It is interesting to read that Oracle's ROWID is now being brought into the discussion. It seems that in usage, Oracle's ROWID is quite similar to a column set to a TIMESTAMP datatype, which I often find quite useful to determine if a row has been altered. (And don't get me started about the lousy choice of a name for the TIMESTAMP datatype -should have been ROWVERSION.) -- Arnie Rowland, Ph.D. Westwood Consulting, Inc Most good judgment comes from experience. Most experience comes from bad judgment. - Anonymous Show quote "Jim Underwood" <james.underwoodATfallonclinic.com> wrote in message news:O5pWCKo1GHA.968@TK2MSFTNGP03.phx.gbl... > Ahhhh... I think I understand where you are coming from. You keep the > natural key on the table, but supplement it with a surrogate key. This > provides a layer of redundancy by which you can verify key changes, and > act > according to your business needs. > > In Oracle, you would use ROWID, which is essentially a GUID that uniquely > identifies every row (perhaps like a bookmark in a clustered index). You > can select a rowid FOR UPDATE to insure no one changes it while you are > working with it, or you can simply check the rowid when you go back to the > database to see if it was updated. Now IIRC, the rowid will change if the > row is updated or deleted, so you can't reference it from day to day, but > because it is a GUID you can be certain that if it is still there, then no > one touched the row. > > Instead of IDENTITY Oracle has SEQUENCE, which requires a little extra > coding as it is not tied to a table, but rather is an independent object. > > "Tony Rogerson" <tonyroger***@sqlserverfaq.com> wrote in message > news:e0fGPAo1GHA.3908@TK2MSFTNGP05.phx.gbl... >> Employee ID is an actual surrogate key! The real 'natural key' to an >> employee would surely be something like national insurance number? >> >> I'll try and blog about it with some examples, it sounds as though you >> are >> using the surrogate approach anyway! >> >> > but here is another. If the natural key changed, even though the >> > surrogate >> > remains the same, how do I know that I still want to update that row? >> > Surely I selected it based on the data that makes up the natural key, > and >> >> You can timestamp the rows so on your trip back to the server to change > the >> row you can check the row hasn't been updated using the timestamps >> (datetime). From that point on its a business decision as to what >> happens, >> most of the time the user will enter another row or try anyway and then >> enter into a complete user confusion stage.... >> >> Without the timestamp, imagine the situation that the natural key got >> changed to something else but a user entered a new record with the same > old >> natural key, then the user (thinking they are updating the original row) >> goes and updates - ouch; these problems cannot happen when using the >> surrogate key approach because you can always pinpoint the 'correct' > record >> and use techniques such as the datetime (last updated) to detect row >> updates... >> >> > Now, if you are speaking about employees having a surrogate of > employeeID, >> > or vehicles having a VIN#, this is very different (IMO) than placing an >> > IDENTITY column on every table (which some do recomend). To me, both >> > of >> > those IDs are characteristics of the entity, rather than surrogate >> > keys. >> >> This is where celko likes to try and be clever because he just doesn't >> get >> the implementation phase. >> >> I say all tables should have a surrogate and in a non-distributed >> database >> the best way to do that is with IDENTITY, all tables should also (where > one >> exists and lets face it not everything has a 'practical' natural key) be >> a >> natural key - you use a primary key constraint on the natural key and a >> unqiue constraint on the surrogate (IDENTITY). >> >> Tony. >> >> -- >> Tony Rogerson >> SQL Server MVP >> http://sqlblogcasts.com/blogs/tonyrogerson - technical commentary from a > SQL >> Server Consultant >> http://sqlserverfaq.com - free video tutorials >> >> >> "Jim Underwood" <james.underwoodATfallonclinic.com> wrote in message >> news:eAuGt4n1GHA.1292@TK2MSFTNGP03.phx.gbl... >> > Tony, >> > Actually, I treat employee ID as a natural key, which may be incorrect > in >> > itself, but that's a different topic. >> > >> > In this case, with surrogate keys, I would use the employee Id to look > up >> > the surrogate keys in the JOBS table, which I would use to look up the >> > surrogate keys in the ANNUAL_REVIEWS table, which I would use to look >> > up >> > the >> > comments for those reviews in the REVIEW_COMMENTS table. >> > >> > With natuaral keys (again, I count employee ID as a natural key) I > would >> > simply get all of the rows from REVIEW_COMMENTS with EMPLOYEE_ID as >> > part >> > of >> > it's composite key. Once I had retrieved the rows, the rest of the key >> > (ReviewDate, ReviewSequence if more than one per date, and comment >> > line) >> > would tell me everything I needed to know about that review. >> > >> > As for changing data, if the natural key changes while I am trying to >> > update >> > that row, how will I update the row? This is a good point that you > make, >> > but here is another. If the natural key changed, even though the >> > surrogate >> > remains the same, how do I know that I still want to update that row? >> > Surely I selected it based on the data that makes up the natural key, > and >> > not on the surrogate key? If the natural key changes, so does the >> > basis >> > of >> > the entity which it represents. Subsequent attempts to update these > rows >> > should fail, IMO, and the user should be prompted to reload the data >> > and >> > make the change again. If I am updating an employees record, and >> > correcting >> > his job title in JOBS for a date of 1/1/2001, and someone else corrects >> > that >> > date to be 6/1/2002, I do not want to reupdate the updated record, >> > which >> > was >> > just corrected. >> > >> > Now, if you are speaking about employees having a surrogate of > employeeID, >> > or vehicles having a VIN#, this is very different (IMO) than placing an >> > IDENTITY column on every table (which some do recomend). To me, both >> > of >> > those IDs are characteristics of the entity, rather than surrogate >> > keys. >> > >> > >> > >> > "Tony Rogerson" <tonyroger***@sqlserverfaq.com> wrote in message >> > news:%232%233Dnn1GHA.4452@TK2MSFTNGP02.phx.gbl... >> >> > making me have to go through EMPLOYEES --> JOBS --> > ANNUAL_REVIEWS --> >> >> > REVIEW_COMMENTS in order to get the review comments for employee >> >> > 123456. >> >> >> >> Why? The application would pass back the surrogate employee_id 123456 > and >> >> you'd only join back out to get the meta data....So, even lookups are >> >> quicker.... >> >> >> >> -- >> >> Tony Rogerson >> >> SQL Server MVP >> >> http://sqlblogcasts.com/blogs/tonyrogerson - technical commentary from > a >> > SQL >> >> Server Consultant >> >> http://sqlserverfaq.com - free video tutorials >> >> >> >> >> >> "Jim Underwood" <james.underwoodATfallonclinic.com> wrote in message >> >> news:%23LIPk8m1GHA.2036@TK2MSFTNGP05.phx.gbl... >> >> > On a side note... >> >> > >> >> > Regarding using composite keys in an application, and the locking >> >> > and >> >> > scalability problems that come with them, would you consider this a >> >> > limitation of SQL Server? >> >> > >> >> > I ask because I have used composite keys in applications extensively >> > with >> >> > Oracle. Oracle has a completely different approach to locking and I >> > have >> >> > never seen the sorts of problems that I see with SQL Server. > Although >> > the >> >> > composite keys required more typing for the joins, it also saved >> >> > time >> >> > by >> >> > not >> >> > making me have to go through EMPLOYEES --> JOBS --> > ANNUAL_REVIEWS --> >> >> > REVIEW_COMMENTS in order to get the review comments for employee >> >> > 123456. >> >> > With surrogate keys, this is what I end up doing, but with natural, >> >> > composite keys, I go straight to the review comments table. >> >> > Granted, > I >> >> > have >> >> > a 4 part key in that table without surrogates, and it takes up more >> > space, >> >> > but I find it much more intuitive than having to track surrogates >> >> > all >> > over >> >> > the database. >> >> > >> >> > >> >> > >> >> > "Tony Rogerson" <tonyroger***@sqlserverfaq.com> wrote in message >> >> > news:OLCrqGj1GHA.1132@TK2MSFTNGP02.phx.gbl... >> >> >> Wow - what an ego..... but we all know that.... >> >> >> >> >> >> The trouble is your postings only reflect you as somebody with > little >> >> >> real >> >> >> world experience, class room bound and unable to learn new > techniques >> > and >> >> >> ideals; your dress, ideas and attitude is stuck in the late 70's >> >> >> and >> >> > because >> >> >> you don't get industry exposure you are unaware how things have >> > changed, >> >> > and >> >> >> my broad experience of enterprise (fortune 500) mainly banks is >> >> >> that >> > they >> >> >> are mainly 3 - 5 years behind current technology and thinking. >> >> >> >> >> >> As for me being a coder (rflol), yes, I do occaisionnally code for >> >> >> clients >> >> >> but 90% of my work is SQL consultancy 'mentoring', 'tuning', > 'reviews' >> >> >> and >> >> >> my clients are from small businesses through to fortune 500.... >> >> >> >> >> >> Tony says 'get the job done with surrogate keys' - at least get >> >> >> that >> >> > right! >> >> >> I don't want all the consistency, locking and scalability problems > you >> >> >> get >> >> >> when you copy the natural key >> > (http://en.wikipedia.org/wiki/Natural_key) >> >> >> everywhere as the foreign key (there is no such thing as a > relational >> >> > key - >> >> >> even wikipedia.org hasn't a reference to it - when are you going to >> >> >> use >> >> > the >> >> >> correct terminology so newbies can google.....); if you had done >> >> >> any >> >> > coding >> >> >> you would realise it isn't practical to use composite keys inside >> >> >> an >> >> >> application. >> >> >> >> >> >> -- >> >> >> Tony Rogerson >> >> >> SQL Server MVP >> >> >> http://sqlblogcasts.com/blogs/tonyrogerson - technical commentary > from >> > a >> >> > SQL >> >> >> Server Consultant >> >> >> http://sqlserverfaq.com - free video tutorials >> >> >> >> >> >> >> >> >> "--CELKO--" <jcelko***@earthlink.net> wrote in message >> >> >> news:1158034189.319136.262460@d34g2000cwd.googlegroups.com... >> >> >> > Perhaps I should change my signature to a list of my books >> >> >> > instead >> >> >> > of >> >> >> > the vague "consultant" and "MVP" instead? Perhaps I should add 10 >> > years >> >> >> > on ANSO X3H2 to balance out the "MVP" signature? Sure loooks >> >> >> > like >> > plug >> >> >> > to me. >> >> >> > >> >> >> > Get real! If any of us wished to be "humble", we would use a > false >> >> >> > names and no links. Oh, I use no links and you do! Gee, so doI >> >> >> > ! >> > Et >> >> >> > al ! >> >> >> > >> >> >> > Duh! One of the functions of newsgroups is to hook up newbie >> > problems >> >> >> > with the 30+ year old vets, the smart kids, the aread experts. > etc. >> > to >> >> >> > gert an answer. The BADF news is that the newbie is more often > than >> >> >> > not given a kludge that gets him over his problem ( i.e. "Take >> >> >> > more >> >> >> > Heroin and you will not feel the pain", or "get 'er done" in the >> >> >> > word >> >> >> > of 'Larry the Cable Guy' on USA television's Jeff Foxwhorthy > shows). >> >> >> > >> >> >> > Tony, you, me, Steve, and others here are pros who are looking >> >> >> > for >> > the >> >> >> > next job. You are looking for a coding job for a few weeks; >> >> >> > Steve >> >> >> > wants a RAC sale immediately and I want a training class series >> >> >> > on > a >> >> >> > Fortuen 500 corporate basis or code review advisor job or >> > "evegantistic >> >> >> > role" for a good product. The target is dependent on what level > or >> >> >> > niche we aim at. >> >> >> > >> >> >> > The newsgroups are a change for us to do "community service" by >> >> >> > postings. If Tony says "get 'er done with an IDENTITY column!!" >> >> >> > and >> > I >> >> >> > say "Dr. Codd.. blah, blah, so you need to look for Relational > keys >> > .. >> >> >> > blah, blah" , the reader should Google the postings, sources, >> >> >> > etc. >> > and >> >> >> > then decide. >> >> >> > >> >> >> >> >> >> >> >> > >> >> > >> >> >> >> >> > >> > >> >> > > You are absolutley correct about your first two points. In truth, no ordinary piece of data will do this, although fingerprints, voice prints, and retina scans can be used (as rediculously impracticle such a thing would be). The Oracle ROWID does much more than timestamp, although I think you can use it for a similar function. It is also the single fastest way to access a row in a table, even faster than using the PK index. Show quote "Arnie Rowland" <ar***@1568.com> wrote in message news:%232P2p0o1GHA.1568@TK2MSFTNGP03.phx.gbl... > The arguments over natural vs. surrogate keys is always one that seems to be > very convoluted and improperly presented. > > One could easily and eloquently argue that a National_ID, or VIN, or SSN, or > Tax_ID, etc., are only surrogate keys created by and imported from another > system, and are not NATURAL characteristics of the entity. In fact, I posit > that attempting to identify individuals using only natural keys would be so > unwieldy as to be impractical. Some form of surrogate keys will have to be > introduced, or created, in order to efficiently handle the data. I ask, and > this is a million dollar question, what combination of characteristics will > absolutely, positively identify an individual WITHOUT resorting to the use > of a surrogate key? > > It is interesting to read that Oracle's ROWID is now being brought into the > discussion. It seems that in usage, Oracle's ROWID is quite similar to a > column set to a TIMESTAMP datatype, which I often find quite useful to > determine if a row has been altered. (And don't get me started about the > lousy choice of a name for the TIMESTAMP datatype -should have been > ROWVERSION.) > > -- > Arnie Rowland, Ph.D. > Westwood Consulting, Inc > > Most good judgment comes from experience. > Most experience comes from bad judgment. > - Anonymous > > > "Jim Underwood" <james.underwoodATfallonclinic.com> wrote in message > news:O5pWCKo1GHA.968@TK2MSFTNGP03.phx.gbl... > > Ahhhh... I think I understand where you are coming from. You keep the > > natural key on the table, but supplement it with a surrogate key. This > > provides a layer of redundancy by which you can verify key changes, and > > act > > according to your business needs. > > > > In Oracle, you would use ROWID, which is essentially a GUID that uniquely > > identifies every row (perhaps like a bookmark in a clustered index). You > > can select a rowid FOR UPDATE to insure no one changes it while you are > > working with it, or you can simply check the rowid when you go back to the > > database to see if it was updated. Now IIRC, the rowid will change if the > > row is updated or deleted, so you can't reference it from day to day, but > > because it is a GUID you can be certain that if it is still there, then no > > one touched the row. > > > > Instead of IDENTITY Oracle has SEQUENCE, which requires a little extra > > coding as it is not tied to a table, but rather is an independent object. > > > > "Tony Rogerson" <tonyroger***@sqlserverfaq.com> wrote in message > > news:e0fGPAo1GHA.3908@TK2MSFTNGP05.phx.gbl... > >> Employee ID is an actual surrogate key! The real 'natural key' to an > >> employee would surely be something like national insurance number? > >> > >> I'll try and blog about it with some examples, it sounds as though you > >> are > >> using the surrogate approach anyway! > >> > >> > but here is another. If the natural key changed, even though the > >> > surrogate > >> > remains the same, how do I know that I still want to update that row? > >> > Surely I selected it based on the data that makes up the natural key, > > and > >> > >> You can timestamp the rows so on your trip back to the server to change > > the > >> row you can check the row hasn't been updated using the timestamps > >> (datetime). From that point on its a business decision as to what > >> happens, > >> most of the time the user will enter another row or try anyway and then > >> enter into a complete user confusion stage.... > >> > >> Without the timestamp, imagine the situation that the natural key got > >> changed to something else but a user entered a new record with the same > > old > >> natural key, then the user (thinking they are updating the original row) > >> goes and updates - ouch; these problems cannot happen when using the > >> surrogate key approach because you can always pinpoint the 'correct' > > record > >> and use techniques such as the datetime (last updated) to detect row > >> updates... > >> > >> > Now, if you are speaking about employees having a surrogate of > > employeeID, > >> > or vehicles having a VIN#, this is very different (IMO) than placing an > >> > IDENTITY column on every table (which some do recomend). To me, both > >> > of > >> > those IDs are characteristics of the entity, rather than surrogate > >> > keys. > >> > >> This is where celko likes to try and be clever because he just doesn't > >> get > >> the implementation phase. > >> > >> I say all tables should have a surrogate and in a non-distributed > >> database > >> the best way to do that is with IDENTITY, all tables should also (where > > one > >> exists and lets face it not everything has a 'practical' natural key) be > >> a > >> natural key - you use a primary key constraint on the natural key and a > >> unqiue constraint on the surrogate (IDENTITY). > >> > >> Tony. > >> > >> -- > >> Tony Rogerson > >> SQL Server MVP > >> http://sqlblogcasts.com/blogs/tonyrogerson - technical commentary from a > > SQL > >> Server Consultant > >> http://sqlserverfaq.com - free video tutorials > >> > >> > >> "Jim Underwood" <james.underwoodATfallonclinic.com> wrote in message > >> news:eAuGt4n1GHA.1292@TK2MSFTNGP03.phx.gbl... > >> > Tony, > >> > Actually, I treat employee ID as a natural key, which may be incorrect > > in > >> > itself, but that's a different topic. > >> > > >> > In this case, with surrogate keys, I would use the employee Id to look > > up > >> > the surrogate keys in the JOBS table, which I would use to look up the > >> > surrogate keys in the ANNUAL_REVIEWS table, which I would use to look > >> > up > >> > the > >> > comments for those reviews in the REVIEW_COMMENTS table. > >> > > >> > With natuaral keys (again, I count employee ID as a natural key) I > > would > >> > simply get all of the rows from REVIEW_COMMENTS with EMPLOYEE_ID as > >> > part > >> > of > >> > it's composite key. Once I had retrieved the rows, the rest of the key > >> > (ReviewDate, ReviewSequence if more than one per date, and comment > >> > line) > >> > would tell me everything I needed to know about that review. > >> > > >> > As for changing data, if the natural key changes while I am trying to > >> > update > >> > that row, how will I update the row? This is a good point that you > > make, > >> > but here is another. If the natural key changed, even though the > >> > surrogate > >> > remains the same, how do I know that I still want to update that row? > >> > Surely I selected it based on the data that makes up the natural key, > > and > >> > not on the surrogate key? If the natural key changes, so does the > >> > basis > >> > of > >> > the entity which it represents. Subsequent attempts to update these > > rows > >> > should fail, IMO, and the user should be prompted to reload the data > >> > and > >> > make the change again. If I am updating an employees record, and > >> > correcting > >> > his job title in JOBS for a date of 1/1/2001, and someone else corrects > >> > that > >> > date to be 6/1/2002, I do not want to reupdate the updated record, > >> > which > >> > was > >> > just corrected. > >> > > >> > Now, if you are speaking about employees having a surrogate of > > employeeID, > >> > or vehicles having a VIN#, this is very different (IMO) than placing an > >> > IDENTITY column on every table (which some do recomend). To me, both > >> > of > >> > those IDs are characteristics of the entity, rather than surrogate > >> > keys. > >> > > >> > > >> > > >> > "Tony Rogerson" <tonyroger***@sqlserverfaq.com> wrote in message > >> > news:%232%233Dnn1GHA.4452@TK2MSFTNGP02.phx.gbl... > >> >> > making me have to go through EMPLOYEES --> JOBS --> > > ANNUAL_REVIEWS --> > >> >> > REVIEW_COMMENTS in order to get the review comments for employee > >> >> > 123456. > >> >> > >> >> Why? The application would pass back the surrogate employee_id 123456 > > and > >> >> you'd only join back out to get the meta data....So, even lookups are > >> >> quicker.... > >> >> > >> >> -- > >> >> Tony Rogerson > >> >> SQL Server MVP > >> >> http://sqlblogcasts.com/blogs/tonyrogerson - technical commentary from > > a > >> > SQL > >> >> Server Consultant > >> >> http://sqlserverfaq.com - free video tutorials > >> >> > >> >> > >> >> "Jim Underwood" <james.underwoodATfallonclinic.com> wrote in message > >> >> news:%23LIPk8m1GHA.2036@TK2MSFTNGP05.phx.gbl... > >> >> > On a side note... > >> >> > > >> >> > Regarding using composite keys in an application, and the locking > >> >> > and > >> >> > scalability problems that come with them, would you consider this a > >> >> > limitation of SQL Server? > >> >> > > >> >> > I ask because I have used composite keys in applications extensively > >> > with > >> >> > Oracle. Oracle has a completely different approach to locking and I > >> > have > >> >> > never seen the sorts of problems that I see with SQL Server. > > Although > >> > the > >> >> > composite keys required more typing for the joins, it also saved > >> >> > time > >> >> > by > >> >> > not > >> >> > making me have to go through EMPLOYEES --> JOBS --> > > ANNUAL_REVIEWS --> > >> >> > REVIEW_COMMENTS in order to get the review comments for employee > >> >> > 123456. > >> >> > With surrogate keys, this is what I end up doing, but with natural, > >> >> > composite keys, I go straight to the review comments table. > >> >> > Granted, > > I > >> >> > have > >> >> > a 4 part key in that table without surrogates, and it takes up more > >> > space, > >> >> > but I find it much more intuitive than having to track surrogates > >> >> > all > >> > over > >> >> > the database. > >> >> > > >> >> > > >> >> > > >> >> > "Tony Rogerson" <tonyroger***@sqlserverfaq.com> wrote in message > >> >> > news:OLCrqGj1GHA.1132@TK2MSFTNGP02.phx.gbl... > >> >> >> Wow - what an ego..... but we all know that.... > >> >> >> > >> >> >> The trouble is your postings only reflect you as somebody with > > little > >> >> >> real > >> >> >> world experience, class room bound and unable to learn new > > techniques > >> > and > >> >> >> ideals; your dress, ideas and attitude is stuck in the late 70's > >> >> >> and > >> >> > because > >> >> >> you don't get industry exposure you are unaware how things have > >> > changed, > >> >> > and > >> >> >> my broad experience of enterprise (fortune 500) mainly banks is > >> >> >> that > >> > they > >> >> >> are mainly 3 - 5 years behind current technology and thinking. > >> >> >> > >> >> >> As for me being a coder (rflol), yes, I do occaisionnally code for > >> >> >> clients > >> >> >> but 90% of my work is SQL consultancy 'mentoring', 'tuning', > > 'reviews' > >> >> >> and > >> >> >> my clients are from small businesses through to fortune 500.... > >> >> >> > >> >> >> Tony says 'get the job done with surrogate keys' - at least get > >> >> >> that > >> >> > right! > >> >> >> I don't want all the consistency, locking and scalability problems > > you > >> >> >> get > >> >> >> when you copy the natural key > >> > (http://en.wikipedia.org/wiki/Natural_key) > >> >> >> everywhere as the foreign key (there is no such thing as a > > relational > >> >> > key - > >> >> >> even wikipedia.org hasn't a reference to it - when are you going to > >> >> >> use > >> >> > the > >> >> >> correct terminology so newbies can google.....); if you had done > >> >> >> any > >> >> > coding > >> >> >> you would realise it isn't practical to use composite keys inside > >> >> >> an > >> >> >> application. > >> >> >> > >> >> >> -- > >> >> >> Tony Rogerson > >> >> >> SQL Server MVP > >> >> >> http://sqlblogcasts.com/blogs/tonyrogerson - technical commentary > > from > >> > a > >> >> > SQL > >> >> >> Server Consultant > >> >> >> http://sqlserverfaq.com - free video tutorials > >> >> >> > >> >> >> > >> >> >> "--CELKO--" <jcelko***@earthlink.net> wrote in message > >> >> >> news:1158034189.319136.262460@d34g2000cwd.googlegroups.com... > >> >> >> > Perhaps I should change my signature to a list of my books > >> >> >> > instead > >> >> >> > of > >> >> >> > the vague "consultant" and "MVP" instead? Perhaps I should add 10 > >> > years > >> >> >> > on ANSO X3H2 to balance out the "MVP" signature? Sure loooks > >> >> >> > | |||||||||||||||||||||||
