To _REF Table, or NOT to _Ref Table -- that is the Question

PointsWell

Doh so close. I was typing without the table in front of me.

The RMA column contains the opposite NAME not ID.

For example I have a Person BO with a ps_Employer

On the Person BO the Trio is as follows:
ps_Employer_REN
ps_Employer_RID
ps_Employer_RMA

The REN indicates the related object name (or BOG)
The RID is the key
The RMA is the return attribute

So
REN=Company
RID=nnnnnn
RMA=pm_Employee

Alternatively if the Company and the Person were a Business Object Group called Contacts (and we weren't talking about employees) then the REN could be Contacts. Presumably this allows the server in the background to then do the join across Company and Person tables to provide a list of Contacts with types Person and Company.

If instead of a two direction relationship I had just used a BO as reference data, e.g. Title (Mr, Ms, Mrs) then the RMA is blank, as I have no need to be able to link back from Mr Ms Mrs etc back to Person records.

rbross

Jaymer wrote
rbross wrote
Ahh, yes when creating a 1 to many either owned by or a peer many it does check the "allow many" flag in the child BO by default. I have found though after you save the BO you can then go to the child BO and uncheck the"Allow Many" flag before publishing and everything works out OK. If you forget to uncheck that flag it will create the ref_ table but if you go back at any time and uncheck it and publish again Aware will remove the Ref_ table and add the extra reference attributes in the child BO.

Roger, this is totally incorrect. I'd hate to see that persist in this thread. Perhaps this was your experience from v7 - if so, please edit the post and clarify. But v8.1 does not do this. After a save, you can't even go to the child (which NOT marked Many) and alter it to many. You have to Delete the relationship and re-do it.

In v8.1, its actually a bit complicated to make a Many-to-Many relationship.
If you start from the Owner, you can't even do it.
The matching field (in Child) doesn't appear until after the save of Owner, and after that, you cannot goto Child and click Multiple. (dimmed)
You have to start in Child and add reference to Parent AND create Matching field as Owner Of. Click Multiple. Then Save.
Then go to Owner and turn ON Multiple and Save.
Then its a true Many to Many.

(If someone finds this is incorrect, I'll gladly correct this. PM me)

Jaymer,

I went back and did some testing on each reference type that can be added. So I'll start by saying we are both right! What I mean by that is this; when creating an owner of reference from the parent to the child and you tick the "Allow Multiple" flag on the parent and you also create the reference back to the parent, it DOES NOT tick the flag "Allow Multiple" in the Child BO. The reasoning is a child cannot be owned by multiple parents. Makes Sense.

However, if you create a reference from the parent to the child as a peer and your tick the "Allow Multiple" flag in the parent and create the reference from the child back to the parent as a peer single Aware will tick the flag in the Child BO as well by default. After you save the BO and before you go into Test mode you can edit the Child BO and untick the "Allow Multiple" flag. Since the reference was created from the parent Aware still creates the REF_ table.

If the reference was created from the Child BO whether Owned By or Peer then no REF_ table is created which you already proved. That is good to know I did not know that. I have always added references from the parent but will add from the Child from now on.

Does this clear up my previous post?

Roger

Jaymer

Yes Roger
Cool. Makes sense.
You wouldn’t think it was this complicated.
Of course, you can’t really expect a newbie to figure this out, and Vlad handles it so it’s not really an issue. The system will still work.
But since I usually did it like you, unfortunately I have a bunch of extra overhead.
I intend to try some benchmarks with and without Ref tables.
... and hope to find results that support Ref table overhead, or all this is/was for naught.

rbross

Jaymer wrote
Yes Roger
Cool. Makes sense.
You wouldn’t think it was this complicated.
Of course, you can’t really expect a newbie to figure this out, and Vlad handles it so it’s not really an issue. The system will still work.
But since I usually did it like you, unfortunately, I have a bunch of extra overhead.
I intend to try some benchmarks with and without Ref tables.
... and hope to find results that support Ref table overhead, or all this is/was for naught.

I am in the same boat as you Jaymer. The CRM Inventory app I created some Own Many and Peer Many from the parent and have REF_ tables and for some, I created from the Child and do not have REF_ Tables. I wondered why sometimes I had a REF_ Table and other time I didn't. I guess this is the answer.

You're right, it is not obvious to a newbie and if you think parent-child relationship, logic would say to create the reference from the parent for the child not from child to parent. Does Vlad have an answer for why the REF_ Table is not created when you create a reference from the child BO? If you were to create this relationship in MS-SQL using the manager you would do it from the parent table wouldn't you?

I have a new project coming up which will have lots of Owned By and Peer Many references so I will be sure to create them from the Child to avoid creating the extra REF_ Table and added overhead.

« Previous Page