Anchor buoy method vs normal method?

[El_Pablo]

Hi,

Small question here.

Is the anchor buoy relationships method is better than the normal "spiderweb" method?

Usually, when I develop a database I use the normal method, but I stepped on the anchor buoy that seems to apply mainly to FM world.

Is that method portable to other database system?

[RalphL]

The relation graph is unique to FileMaker. Anchor-buoy is one method of creating the relational graph. Neither is directly portable to a different database system such as SQL.

Is it better? That is a matter of personal preferences.

[El_Pablo]

I guess the main problem with a-b method is the duplication of TOs and some of them with pretty lengthly prefixes.

[Ocean West]

Yes you do have many duplicate TO's but the trade of in being able to focus on a single task at hand or chain of thought is much easier to dive in - especially once you do not visit that part of the graph often.

Using Base Elements though will help you over time make sure that you can safely remove unreferenced or abandoned duplicate TO's

If you come back months later to add a feature or enhance a process you can jump in to that area creating the necessary relationships as needed. And not have to refresh your self and figure out what and where every thing is.

Also to with AB you can have separate TOGS just for cascade deletes

so that when you need to change them you only need to look in one place.

Also if you ever need to take a single file solution and break it off into the separation model I think its a bit easier to to make the transition when the file starts out as AB

It's really the only way to go if you are co-developing coupled with a good naming convention

[El_Pablo]

So for a basic products - invoiceLines - invoices graph, I should have the following relationships.

PROD_PRODUCTS 1-M prod_INVOICELINES M-1 prod_il_INVOICES

INV_INVOICES 1-M inv_INVOICELINES M-1 inv_il_PRODUCTS

IL_INVOICELINES M-1 il_PRODUCTS

IL_INVOICELINES M-1 il_INVOICES

Am I correct?