glue-wg-bounces@ogf.org [mailto:glue-wg-bounces@ogf.org] On Behalf Of David Horat said:
Having an object ObjectA related to object ObjectB and being the relationship ObjectA 0..* - 0..* ObjectB, - ObjectA will contain the attribute ObjectAObjectBFK pointing to ObjectB's DN - ObjectB will contain the attribute ObjectBObjectAFK pointing to ObjectA's DN
I have another general point about foreign keys (aside from the fact that they should point to an ID and not a DN). Even though the relationship has two ends there is no particular reason to have the keys in both the objects. In your example above, even if the second attribute is missing I can navigate in both directions: either I query A for the B ID in its FK attribute and then query for B by its ID, or I query B for its ID and then query for the A which has an FK which references it. There might be marginal performance differences but I don't think it's significant in practice. That might not matter, except that there can also be practical impacts because the multiplicities can in some cases be enormous. For example, consider the ComputingShare/ComputingActivity relation. There could be a huge number of jobs, so if you put all the references into the Share it will inflate the size of the object substantially. There are also practical implications for the way the info providers are written. The info provider has to be able to know the IDs of all the objects it references explicitly. The natural way to to it is to generate the objects in a hierarchical way, so in the same case you'd generate the Share with its ID and then loop over all the jobs passing the share ID in. If you want to have the Activity keys in the Share you'd have to duplicate the loop over the jobs so you could put their IDs into the Share, and also cache the information because otherwise the list might change in between. Stephen -- Scanned by iCritical.