continuum-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Edward Gruber <>
Subject Re: project group shortcuts
Date Sat, 04 Nov 2006 21:54:17 GMT
Yep.  Compound business keys == good.  Compound surrogate (raw database)
keys == bad. :)

I'm with the program.  Please proceed.  It sounds awesome.


Jesse McConnell wrote:
> I am not actually referring to anything about how they are stored in
> the database, that is purely integer keys in the jdo store in in this
> case, the projects are logically stored in the group object that is
> persisted into whatever store.
> I am referring to how you programmatically refer to them, to access
> the group you ask for it by the string groupId, to get a particular
> project you need to know the group id it is in and then the string
> projectId of that project.  right now it is possible to get the
> project instance directly by knowing the integer id of that project
> which is currently that internal jdo index number.
> this would be so that you could have two instance of a project group
> loaded up and maintain the same projectIds for the same projects in
> those groups, and then distinguish between them by the group they are
> a member of.  this is because I think it would be annoying as sin to
> load up Doxia and make a DoxiaCore project in it, and then load up a
> DoxiaBranchFoo and have to name the DoxiaCore something like
> DoxiaCoreBranch just to make it unique.
> is that clearer?
> jesse
> p.s. great feedback, thanks
> On 11/4/06, Christian Edward Gruber <> wrote:
>> Cool,  more comment in-line.
>> Jesse McConnell wrote:
>> > On 11/4/06, Christian Edward Gruber <> 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** + bus 905.640.1119 + mob 416.998.6023*


*christian** gruber + process coach and architect*

*Israfil Consulting Services Corporation*

*email** + bus 905.640.1119 + mob 416.998.6023*

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