I must agree…. every time I’ve used flattened relationships, I eventually find a reason to undo it.
For instance, a lot of my databases have a transID that represents a foreign key relationship to a table that tracks the responsible party for each transaction. Even though I may not add data to the join table right now, I still want to have a way to track who created/updated/deleted it. > On Oct 20, 2014, at 4:06 PM, Ray Kiddy <[email protected]> wrote: > > On Mon, 20 Oct 2014 17:41:00 -0200 > Flavio Donadio <[email protected]> wrote: > >> Hello, people! >> >> I am experimenting a little more... and hitting some roadblocks! >> >> Example: I have these entities called Product and Quote. A Quote has >> many products. But each quoted product has more information, like >> price, quantity and lead time. So, I am using this QuotedProduct >> entity, which "binds" the Product id, the Quote id and the other >> information. >> >> The relationship could be expressed like this: >> >> Quote <--->> QuotedProduct <<---> Product >> >> I understand I shouldn't flatten any of these relationships. Am I >> right? >> >> >> Cheers, >> Flavio > > You are definitely right. You cannot have the QuotedProduct be both the > target of a class-property relationship and also a part of a flattened > relationship. > > I often do this kind of join table and I usually think that I can use > the (in this case) quotePk and productPk attributes, together, as the > primary key of the QuotedProduct entity. Lately, I most often just go > ahead and create a single pk column in the QuotedProduct entity. I do > not feel that I need to do this, but it ends up being better in the > long run, avoids some problems that seem to pop up with the > dual-attribute pk. That is just my experience. > > By the way, if you end up wanting the to have the "product" link in the > QuotedProduct point to other kinds of objects, inherited entities or > such as that, the pk will be much more helpful. > > cheers - ray > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Webobjects-dev mailing list ([email protected]) > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/webobjects-dev/kenlists%40anderhome.com > > This email sent to [email protected] _______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
