Can a BO be owned by more than one other BO?

BLOMASKY

My logic when deciding if something is a peer relationship vs. owner / owned by is can a record stand alone if the peer was deleted. So, in the case of 3 BOs, Inventory, PurchaseHeader PurchaseLines. It is obvious that the PurchaseLines is owned by the Header, since if the header was deleted the line items would have no valid context.

However, since each PurchaseLine is related to an inventory record, If the Item is deleted then the purchase line has no value. I would have a quantity and price, but have no idea what item is being purchased. Therefore, in my design, I would have the PurchaseLine a child of both the Header and Inventory.

I was told by a much smarter (and better looking) developer that you should never have an item have more than one "owned by". Is this true? Is there any reason to not have more than one parent?

Thanks
Bruce

BenHayat

I had been in the exact situation many times and I would NOT have a BO to have Two fathers. It's NOT a sound design, and religiously, it's unethical 😃

So I use Peer relationship between Line and Inventory with one extra step. I add a rule to my Inventory BO, that it can not be deleted if any other Peer Objects have already used it.
a) If it's not used anywhere, the code will allow the deletion.
b) If it "is" used, then the code will flag it as "Inactive", which that inventory will not show up in dropdown choices or any type of selections. But any other objects who used it before, will not be affected.

Aware makes it very easy to add such powerful feature.
Hope this helps!

BLOMASKY

Thanks for the answer Father (or is it Priest, or perhaps Rabbi) Ben. I do HATE to go against any religion 🙂

However, my 0.02 cents is that the only diff. is that if an OWNER is deleted then all of the children will cascade delete. otherwise, the system works the same. So I do have rules to stop me from deleting records where there are children records. From my point of view, a I can exist with or without a PEER. It just gives me more info. But if my existence requires 2 (or 8-) parents. Then, I want to know that.

With SQL this is done by foreign keys and triggers. Since I am using Mark's naming for relationships, OB, OM, PS, PM, if I see any OM in an object, then I know I have to tread carefully if I plan to delete the item. If I see any PS or PM, then delete away and "cry havoc and let slip the hounds of war" (I never have found a good place to use that quote. Prolly not a good place here either.

Thanks for your intelligent, well thought out, logical response sir!

Bruce

BenHayat

BLOMASKY wrote
Thanks for your intelligent, well thought out, logical response sir!

Bruce

My pleasure my "Child"! 😃

BenHayat

I'm surprised we didn't get comments or opinions from other forum members regarding this important and valid question.

johntalbott

From what I can tell the BO ownership concept in AwareIM is just a way to create a "foreign key" and turn on "cascading deletes" without having to configure a rule to manage parent/child BOs. If you just want a foreign key but not cascading deletes, it looks like one would make it be a peer.

In other words ... a database table doesn't "own" another database table. There may be a parent/child relationship, but I feel that the context is slightly different.

Having said all this, I'm not in love with having all the relationships managed outside of the RDMS. I'd prefer to have the db enforce referential integrity and data quality. Other non-AwareIM applications may use that same data which happens a lot in the enterprise.

BenHayat

johntalbott wrote
From what I can tell the BO ownership concept in AwareIM is just a way to create a "foreign key" and turn on "cascading deletes" without having to configure a rule to manage parent/child BOs. If you just want a foreign key but not cascading deletes, it looks like one would make it be a peer.

In other words ... a database table doesn't "own" another database table. There may be a parent/child relationship, but I feel that the context is slightly different.

Having said all this, I'm not in love with having all the relationships managed outside of the RDMS. I'd prefer to have the db enforce referential integrity and data quality. Other non-AwareIM applications may use that same data which happens a lot in the enterprise.

I hope Support gets to read this thread.
It would be great that we can get options (when creating a new Object/Table) to have Aware to create FK and configure Parent/Child relationship for the underlying Database system. This way, it helps for third party Reporting/Diagramming or other tools to use the tables in a conventional way, as if they were created by DB management tools.
This way, Aware can use it's own proprietary system for it's own use, and others can use the conventional system.
Hope this helps!