> 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
> > 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).

"--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.
>

"--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.
>

"--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.
>

"--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?
>

"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
>

"--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?
>

"--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 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.
> >
>
>

"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.
>> >
>>
>>
>
>

"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 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

> >> 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.
> >> >
> >>
> >>
> >
> >
>
>

"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.
>> >> >
>> >>
>> >>
>> >
>> >
>>
>>
>
>

"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.
> >> >> >
> >> >>
> >> >>
> >> >
> >> >
> >>
> >>
> >
> >
>
>

"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.
>> >> >> >
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >>
>> >>
>> >
>> >
>>
>>
>
>

"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
> >> >> >> > 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.
> >> >> >> >
> >> >> >>
> >> >> >>
> >> >> >
> >> >> >
> >> >>
> >> >>
> >> >
> >> >
> >>
> >>
> >
> >
>
>

"ML" <M*@discussions.microsoft.com> wrote in message
news:22002E31-3CEB-4D06-A841-26A66925BF64@microsoft.com...
> Can the image of a person's fingerprints be encoded as a key? (i.e. less
> than
> 900 bytes for SQL Server)
>
>
> ML
>
> ---
> http://milambda.blogspot.com/

> Can the image of a person's fingerprints be encoded as a key? (i.e. less than
> 900 bytes for SQL Server)
>
>
> ML
>
> ---
> http://milambda.blogspot.com/

> Stu wrote:
> > Just to continue this hypothetical discussion, fingerprints are not
> > immutable.  I don't have fingerprints on two of my fingers (due to an
> > unfortunate high school chemistry prank)
> >
>
> You have no natural key, does that mean you don't exist?  :-)
>
>
> --
> Tracy McKibben
> MCDBA
> http://www.realsqlguy.com

"ML" <M*@discussions.microsoft.com> wrote in message
news:35E29A03-9CDB-455C-A1DD-1FA00A4D24B7@microsoft.com...
> 18 + 2 nulls is still pretty good. :)
>
>
> ML
>
> ---
> http://milambda.blogspot.com/

"Tracy McKibben" <tr***@realsqlguy.com> wrote in message
news:4507039A.7010408@realsqlguy.com...
> ML wrote:
> > 18 + 2 nulls is still pretty good. :)
> >
> >
> > ML
> >
> > ---
> > http://milambda.blogspot.com/
>
> He said fingerprints, not toeprints.  You don't understand that fingers
> are not toes, hands are not feet.
>
>
> --
> Tracy McKibben
> MCDBA
> http://www.realsqlguy.com

"Tracy McKibben" <tr***@realsqlguy.com> wrote in message
news:4507039A.7010408@realsqlguy.com...
> ML wrote:
>> 18 + 2 nulls is still pretty good. :)
>>
>>
>> ML
>>
>> ---
>> http://milambda.blogspot.com/
>
> He said fingerprints, not toeprints.  You don't understand that fingers
> are not toes, hands are not feet.
>
>
> --
> Tracy McKibben
> MCDBA
> http://www.realsqlguy.com

"Arnie Rowland" <ar***@1568.com> wrote in message
news:%23tx0PIq1GHA.1292@TK2MSFTNGP03.phx.gbl...
> ... and arms are not legs, therefore there is NO discernable relationship
> between them all.
>
> --
> Arnie Rowland, Ph.D.
> Westwood Consulting, Inc
>
> Most good judgment comes from experience.
> Most experience comes from bad judgment.
> - Anonymous
>
>
> "Tracy McKibben" <tr***@realsqlguy.com> wrote in message
> news:4507039A.7010408@realsqlguy.com...
> > ML wrote:
> >> 18 + 2 nulls is still pretty good. :)
> >>
> >>
> >> ML
> >>
> >> ---
> >> http://milambda.blogspot.com/
> >
> > He said fingerprints, not toeprints.  You don't understand that fingers
> > are not toes, hands are not feet.
> >
> >
> > --
> > Tracy McKibben
> > MCDBA
> > http://www.realsqlguy.com
>
>

> unless of course arms and legs are both limbs, and fingers and toes are
> child entities of those limbs independent of the type of limb to which their
> FK refers...
>
> "Arnie Rowland" <ar***@1568.com> wrote in message
> news:%23tx0PIq1GHA.1292@TK2MSFTNGP03.phx.gbl...
> > ... and arms are not legs, therefore there is NO discernable relationship
> > between them all.
> >
> > --
> > Arnie Rowland, Ph.D.
> > Westwood Consulting, Inc
> >
> > Most good judgment comes from experience.
> > Most experience comes from bad judgment.
> > - Anonymous
> >
> >
> > "Tracy McKibben" <tr***@realsqlguy.com> wrote in message
> > news:4507039A.7010408@realsqlguy.com...
> > > ML wrote:
> > >> 18 + 2 nulls is still pretty good. :)
> > >>
> > >>
> > >> ML
> > >>
> > >> ---
> > >> http://milambda.blogspot.com/
> > >
> > > He said fingerprints, not toeprints.  You don't understand that fingers
> > > are not toes, hands are not feet.
> > >
> > >
> > > --
> > > Tracy McKibben
> > > MCDBA
> > > http://www.realsqlguy.com
> >
> >

"SQL Menace" <denis.g***@gmail.com> wrote in message
news:1158093138.593236.143080@m73g2000cwd.googlegroups.com...
> Or we can take it all the way to Tetrapod Transitionals  ;-)
>
>
> Denis the SQL Menace
> http://sqlservercode.blogspot.com/
>
>
>
> Jim Underwood wrote:
> > unless of course arms and legs are both limbs, and fingers and toes are
> > child entities of those limbs independent of the type of limb to which
their
> > FK refers...
> >
> > "Arnie Rowland" <ar***@1568.com> wrote in message
> > news:%23tx0PIq1GHA.1292@TK2MSFTNGP03.phx.gbl...
> > > ... and arms are not legs, therefore there is NO discernable
relationship
> > > between them all.
> > >
> > > --
> > > Arnie Rowland, Ph.D.
> > > Westwood Consulting, Inc
> > >
> > > Most good judgment comes from experience.
> > > Most experience comes from bad judgment.
> > > - Anonymous
> > >
> > >
> > > "Tracy McKibben" <tr***@realsqlguy.com> wrote in message
> > > news:4507039A.7010408@realsqlguy.com...
> > > > ML wrote:
> > > >> 18 + 2 nulls is still pretty good. :)
> > > >>
> > > >>
> > > >> ML
> > > >>
> > > >> ---
> > > >> http://milambda.blogspot.com/
> > > >
> > > > He said fingerprints, not toeprints.  You don't understand that
fingers
> > > > are not toes, hands are not feet.
> > > >
> > > >
> > > > --
> > > > Tracy McKibben
> > > > MCDBA
> > > > http://www.realsqlguy.com
> > >
> > >
>

"Jim Underwood" <james.underwoodATfallonclinic.com> wrote in message
news:%23xyfntq1GHA.1132@TK2MSFTNGP02.phx.gbl...
> The whatsawhosicals?
> "SQL Menace" <denis.g***@gmail.com> wrote in message
> news:1158093138.593236.143080@m73g2000cwd.googlegroups.com...
> > Or we can take it all the way to Tetrapod Transitionals  ;-)
> >
> >
> > Denis the SQL Menace
> > http://sqlservercode.blogspot.com/
> >
> >
> >
> > Jim Underwood wrote:
> > > unless of course arms and legs are both limbs, and fingers and toes
are
> > > child entities of those limbs independent of the type of limb to which
> their
> > > FK refers...
> > >
> > > "Arnie Rowland" <ar***@1568.com> wrote in message
> > > news:%23tx0PIq1GHA.1292@TK2MSFTNGP03.phx.gbl...
> > > > ... and arms are not legs, therefore there is NO discernable
> relationship
> > > > between them all.
> > > >
> > > > --
> > > > Arnie Rowland, Ph.D.
> > > > Westwood Consulting, Inc
> > > >
> > > > Most good judgment comes from experience.
> > > > Most experience comes from bad judgment.
> > > > - Anonymous
> > > >
> > > >
> > > > "Tracy McKibben" <tr***@realsqlguy.com> wrote in message
> > > > news:4507039A.7010408@realsqlguy.com...
> > > > > ML wrote:
> > > > >> 18 + 2 nulls is still pretty good. :)
> > > > >>
> > > > >>
> > > > >> ML
> > > > >>
> > > > >> ---
> > > > >> http://milambda.blogspot.com/
> > > > >
> > > > > He said fingerprints, not toeprints.  You don't understand that
> fingers
> > > > > are not toes, hands are not feet.
> > > > >
> > > > >
> > > > > --
> > > > > Tracy McKibben
> > > > > MCDBA
> > > > > http://www.realsqlguy.com
> > > >
> > > >
> >
>
>

"Tracy McKibben" <tr***@realsqlguy.com> wrote in message
news:45071CB6.6090804@realsqlguy.com...
> SQL Menace wrote:
> > Or we can take it all the way to Tetrapod Transitionals  ;-)
> >
>
> Ahh, another entry for my book "Conversations Not To Have In A Bar"
>
>
>
> --
> Tracy McKibben
> MCDBA
> http://www.realsqlguy.com

"Steve Dassin" <steve@nospamrac4sql.net> wrote in message
news:e63L8kr1GHA.3656@TK2MSFTNGP04.phx.gbl...
> "Jim Underwood" <james.underwoodATfallonclinic.com> wrote in message
> news:uS%234F1q1GHA.4392@TK2MSFTNGP04.phx.gbl...
> > Actually I find scientific, religious, and political discussions far
more
> > interesting after a few drinks.  They rank right up there with
discussions
> > on "Family Guy" and the "American Pie" movies.
>
> Ah, you drink alone.
>
>

"Jim Underwood" <james.underwoodATfallonclinic.com> wrote in message
news:edA7Vaz1GHA.4748@TK2MSFTNGP04.phx.gbl...
> Ouch.
> I walked into that one.

> ML wrote:
> > 18 + 2 nulls is still pretty good. :)
> >
> >
> > ML
> >
> > ---
> > http://milambda.blogspot.com/
>
> He said fingerprints, not toeprints.  You don't understand that fingers
> are not toes, hands are not feet.
>
>
> --
> Tracy McKibben
> MCDBA
> http://www.realsqlguy.com

> finger (en) = prst (sl)
> toe (en) = prst (sl)
>
> Another language-dependent property. :)
>
>
> ML
>
> ---
> http://milambda.blogspot.com/

"ML" <M*@discussions.microsoft.com> wrote in message
news:22002E31-3CEB-4D06-A841-26A66925BF64@microsoft.com...
> Can the image of a person's fingerprints be encoded as a key? (i.e. less
than
> 900 bytes for SQL Server)
>
>
> ML
>
> ---
> http://milambda.blogspot.com/

>
> In the US we use the Henry Galt classification system.  There are
> several others in use in South America, Eastern and Western Europe.
>
> NIST (National Institute for Standards and Technology nee National
> Bureau of Standards) has a standard for an extended version of  the US
> system.  PrintTrac de la Rue and a Japanese company (cannot remember
> which one!) had scanners that do the work automatically years ago.  I
> have been away from Georgia prisons for a lot of years now, so I am
> behind on the technology.  (Sorry about the staight line, but I used
> more math there than I did in the DOT's road design section to get
> stats in a seriously skewed population)
>
> The degree of trust issue applies here.  A thumb print is "good enough"
> for an ATM or POS system.  But you want to see a full "Ten Card" for
> criminal identification to get an 8 point match.
>

"Alexander Kuznetsov" <AK_TIREDOFSPAM@hotmail.COM> wrote in message
news:1158082872.602317.221190@i3g2000cwc.googlegroups.com...
> > 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?
>
> More to the point, in 21st century it is kinda difficult to find a
> practitioner still willing to use SS# as a primary key. Exposing
> confidential information any more than necessary is becoming a major
> business risk. Lots of shops had to redesign their databases to some
> extent and replace SS# with surrogate keys.
> Do you guys still see your SS# on your health insurance card?
>

"Chris Lim" <blackca***@hotmail.com> wrote in message
news:1158100748.418120.169520@p79g2000cwp.googlegroups.com...
> Tony Rogerson wrote:
>> 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).
>
> Wouldn't you always make the primary key constraint based on the
> surrogate key (since it's used as a foreign key to other tables) and
> place a unique constraint on the natural key?
>
> Chris
>

"--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.
>