From: Todd Benson <caduceass@...>
Date: 2008-04-13T10:48:23+09:00
Subject: Re: [OT] Re: How to check record duplication before saving?

On Sat, Apr 12, 2008 at 8:37 PM, Todd Benson <caduceass@gmail.com> wrote:
>
> On Sat, Apr 12, 2008 at 7:14 PM, Todd Benson <caduceass@gmail.com> wrote:
>  > On Sat, Apr 12, 2008 at 3:55 PM, ara.t.howard <ara.t.howard@gmail.com> wrote:
>  >  >
>  >  >  On Apr 12, 2008, at 10:34 AM, Todd Benson wrote:
>  >  >
>  >  > >
>  >  > > In rails, I should point out I _have_ to use the integer ID for my
>  >  > > primary key, which irks me to no end because it goes against
>  >  > > everything I know about set theory.  That whining aside, I might try
>  >  > > to fix it, but the underlying rails code is intimidating.
>  >  > >
>  >  >
>  >  >  no db actually deals with sets - try to do a query and get the results back
>  >  > in different order each time.  in practice they are *ordered* tuples of key
>  >  > value pairs and every db i've used is written with this implicit
>  >  > understanding.  having an id is no different that having an 'updated_at'
>  >  > field - it simply provides a total ordering which is arbitrary.  fighting
>  >  > the id is just swimming upstream to nowhere - i know as i did it for a long
>  >  > time.  ;-)
>  >  >
>  >  >  a @ http://codeforpeople.com/
>  >
>  >  I understand that, for example, postgresql and mysql have labeled all
>  >  things with an integer.  But, in the table itself, umm, doesn't make
>  >  much sense...
>  >
>  >  create table my_set (
>  >
>  >   id int not null primary key,
>  >   a int,
>  >   b int,
>  >  );
>  >
>  >  insert into my_set values (1, 1, 1);
>  >
>  >  insert into my_set values (2, 1, 1);
>  >
>  >  It gets even worse with built in functions like auto_increment, where
>  >  you've tossed all identity of the tuple to the wind (think of moving
>  >  such a table to another db).
>  >
>  >  I'm still a firm believer in using logical primary keys instead of
>  >  arbitrary ones anyway, even if it takes a little more effort, but I'm
>  >  willing to listen to other ways :-)
>
>  I'll clarify a little (I may have told this little story before).  I
>  once worked for a company that had complete confidence in its ERP
>  database (to be nameless).  Suddenly, one day, there's about a half
>  mil missing for no real reason except for what the reports said.
>  Having been embezzled before, they wanted to find the culprit.  The
>  culprit turned out to be the database schema (and they were _so_ ready
>  for a witch hunt).
>
>  Todd

Wow.  That sounded incriminating, didn't it!  My apologies for the
noise, but it's true.  The company I worked for lost a bunch of money
because of a culmination of practices.  They were paying for new part
revs and the db didn't reflect it.  "Bad" shipments were dropped/lost
in the shipping part of the database.  Also, it was full of tables
called: 12400010, 12400011, etc.  and the relations were not even
close to sane.  The "help" was paid about $1000/hr to set it up.

Todd