From: Todd Benson Date: 2008-06-27T03:39:26+09:00 Subject: Re: Sequel primary keys On Wed, Jun 25, 2008 at 1:12 PM, Rimantas Liubertas wrote: > <...> >> If my DB is a model of real world entities as it >> should be then there should be a unique indentifier for said entities which >> means I shouldn't have to number them just because. >> >> In other words I am using necessary table elements as keys. > > The problem with "real world" unique identifiers is that even if they > stay uniqui they > _may_ change You mean schema change, or something else? > The worst part it that they do change, even those you though would > never ever possible change. Please clarify. > Surrogate keys do not have this problem. They may have other problems, > but it is worth it, > imho. > > Regards, > Rimantas That sounds more like a schema design problem than a programming one. Of course, this debate will go on forever in db circles. Some swear upon OO and other styles of dbs, even. I sort of side with Celko (smart guy with a somewhat bearable cocky attitude that writes db books and used to frequent -- maybe still does -- comp.databases.theory) and personally like the RDBMS. Even though Ruby is very OO, it does lend itself well to set theory. But, to each his or her own. There's nothing wrong with surrogate keys, really. But the whole arbitrary number defining a tuple's existence and uniqueness doesn't move well across platforms. Not only that, having to define extra UNIQUE constraints to make logical sense is redundant.. This is one of the reasons I tend to avoid using Rails simply because it's not simple to do what I want. Taking care of such a thing in the app will not scale well. For situations where you prefer convenience instead of data integrity or all the unit tests you want to write to ensure that integrity, then I guess it's applicable. Todd P.S. Sorry for calling Glen Greg.