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*
-- jesse mcconnell [EMAIL PROTECTED]
