continuum-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Edward Gruber <cgru...@israfil.net>
Subject Re: project group shortcuts
Date Sat, 04 Nov 2006 19:50:42 GMT
Cool,  more comment in-line.

Jesse McConnell wrote:
> On 11/4/06, Christian Edward Gruber <cgruber@israfil.net> wrote:
>> To that end, also, I think that the projects should still have an
>> internal primary key that's integer based, but that (continuum)
>> groupId+projectId should be an alternate "business key" for the
>> integerId.  This, of course, to avoid craziness between multiple copies
>> of project groups.
>
> right, the Project already has an id which is integer and is the store
> key for that object, I am proposing here that we stop using these
> internal store id's all over the place in the UI and other code.  and
> your right, groupId + projectId (the string short names) would be the
> business key for this, they would together be unique always.  I think
> projectId could be shared across multiple groups though, so to get a
> particular one of those you would need to know the groupId to get it
> from.
Meh.  I'm not a fan of compound-primary-keys, except on join tables, or
when you really have to.  If these projectIds are surrogate keys, then
they should be unique, with a foreign-key to groupId to maintain the
strong relationship.  Joins get torturous (and more expensive) when you
have compound primary keys, and the further out your join-tables, the
more times you replicate several keys.  If we're separating surrogate
keys from business keys, then let's keep single unique surrogate keys as
primary keys, and leave the composite stuff for business keys.  Just my
opinionated view... :)

Christian
-- 

*christian** gruber + process coach and architect*

*Israfil Consulting Services Corporation*

*email** cgruber@israfil.net + bus 905.640.1119 + mob 416.998.6023*


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message