Yep. Compound business keys == good. Compound surrogate (raw database) keys == bad. :)
I'm with the program. Please proceed. It sounds awesome. Christian. 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 <[EMAIL PROTECTED]> wrote: >> 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* >> >> >> > > -- *christian** gruber + process coach and architect* *Israfil Consulting Services Corporation* *email** [EMAIL PROTECTED] + bus 905.640.1119 + mob 416.998.6023*
