Cool, more comment in-line. Jesse McConnell wrote: > On 11/4/06, Christian Edward Gruber <[EMAIL PROTECTED]> 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** [EMAIL PROTECTED] + bus 905.640.1119 + mob 416.998.6023*
