Jump to content
Salesforce and other SMB Solutions are coming soon. ×

Multiple TOGs


hypodermis
 Share

Recommended Posts

i have a relatively large table (table a) in which about 200 fields are related to several fields of other tables (xtable_1 to xtable_10). this approach is needed because of the underlying business structure. the table names are fictitious...

 

i'd like to simplify the relationships graph visually, based on the anchor-buoy (or squid) approach.

 

i set up multiple occurrences of an anchor table ("table a", naming them tables a1 to a10) and then displayed the relationships between table a1 and xtable_1..xtable_10, table a2 and xtable_1..xtable_10 (etc) as separate TOGs.

 

the only way it worked for me if i related the occurrences of "table a" (tables a1 ... a10) to "table a" through a common key field, essentially creating the relations via a self-join. i call it the siamese squids.

 

then i read in a fm book that one should not have relations set up between the anchor tables of table occurrence groups. does this principle apply only to anchor tables that represent different data or does it apply also to my approach? what can go wrong? what am i missing?

 

any insight and enlightenment would be appreciated.

Link to comment
Share on other sites

"based on the anchor-buoy (or squid) approach."

 

"i set up multiple occurrences of an anchor table"

 

First, these are incongruent statements - the anchor-buoy approach explicitly uses a single anchor TO for each table.

 

Second, what you seem to have set up is poor structure. Just because it works does not mean it is right. I can't really see how it simplifies things.

Link to comment
Share on other sites

what i want to achieve is a "structured view" of a database. in this database i have several relations that are more complex than the business structures reflected in various filemaker resources.

 

the busiest part of the graph is caused by eight fields in my anchor table. in each one of these eight fields i need to show the price of an item from a vendor (different items in each field) but only one vendor for a given record. i have 14 vendors that have different prices for the same product. the price lists are in separate tables for each vendor. thus i have 8 x 14 = 112 buoys.

 

the relations and portals work but the diagram is rather unappealing, looking like the spiderweb-types experts suggest to avoid.

 

i know that i have to have a single anchor TO for each table. my conundrum is how to display it in a visually more appealing way even though this may be a departure from the usual.

 

since it is not possible to simplify the business structure i wanted to simplify its VIEW only. sorry if i was not clear in the first posting.

Link to comment
Share on other sites

I've been developing for years and my rel diagrams for pretty much any solution of any real complexity ends up looking like snarled-up nylon fishing line.

 

While an unexpectedly complex rel diagram can be a giveaway that the structure needs to be rethought, there are many well-structured solutions in which the relational structure is well thought out and non-redundant that look ridiculous on the rel diagram.

 

One can end up having a significant amount of one's design decisions determined by "how is that going to look on my diagram".

 

That's like buying books based on how their covers are going to look on the shelves of your library.

 

However,

the busiest part of the graph is caused by eight fields in my anchor table. in each one of these eight fields i need to show the price of an item from a vendor (different items in each field) but only one vendor for a given record. i have 14 vendors that have different prices for the same product. the price lists are in separate tables for each vendor. thus i have 8 x 14 = 112 buoys

 

the fact that I've read this several times over and still can't grasp what you're trying to do or why does not bode well. It could be a reading comprehension problem on my part, granted, but... could you explain what table houses your vendors, what table(s) houses your list(s) of products and prices and how it ties to the vendors thereof, and whyfore you need eight different fields in the same table to show the "price of an item from a vendor"? I do think I've come to understand that you're trying to do a price comparision between multiple vendors for the same item, and perhaps do that over and over again for each item respectively in a list of items?

 

VERY loosely speaking (with the assumption that I understand maybe 15% of what you're trying to do, and may be wrong about some of that), I suspect what you want to do is set up one relationship where the parameter on the local side is a global or a calculated value referencing a global, and in a script run through the range of variables — probably abstracted from a value list —*in a loop until you've hit all the vendors/priced items, resulting in a grid with vendors down the side and priced items along the top (or vice versa), and the prices in the intersections like a spreadsheet.

Link to comment
Share on other sites

i have 14 vendors that have different prices for the same product. the price lists are in separate tables for each vendor. thus i have 8 x 14 = 112 buoys.

Consider a Vendor table - one Vendor for each record (containing Vendor details) and ONE Pricing table (each record containing VendorID and ProductID). It can even be many-to-many structure, ie, one Vendor for multiple products - one product has multiple Vendors.

Link to comment
Share on other sites

This thread is quite old. Please start a new thread rather than reviving this one.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share



×
×
  • Create New...

Important Information

Terms of Use