Re: Complex Relationships ... ugh. How to set up?

#1

On Mar 5, 8:14 am, "Grip" <g... (AT) cybermesa (DOT) com> wrote:

Quote:

I think you need a couple extra join tables in there and I don't think
you can get everything done on one layout.

Just to clarify, a Model doesn't stand by itself, it needs a Variation
to contain PartLoc info, right? In other words a Variation isnt
varying from a Model, but from the other Variations?

Let me summarize what I think your db has:
A Model table. Each Model record contains an id for the Model,
probably along with a description.
The Model table is related to the Variations table.
Each Variations record has a Model id (relating to the the Model) and
its own unique Variation ID, along with a designation fields like 001
and New York. And presumably a calc field of the cost of the
materials.
The Variations table is related to the PartLocations table with the
Variations id.
The PartLocations table contains the fields designating number (1, 2
or 3), BodyParts, Materials id, and MaterialsName.
PartLocations relates to Materials via MaterialsID.

I'd recommend one more table: Models_PartLoc_Join. Since you want any
change to a PartLoc to affect all Models, create this table that will
be a reference for your Variations. When you change your
Models_PartLoc_Join table, you can easily script an update for all the
Variations.

For data entry, a layout based on the highest table in a hierarchy is
usually best. For printing, it's the lowest element. So you base you
layout on Models, have a portal to Variations. You create another
relationship from Models to PartLocs. In that include a global field
from Models to the PartLoc variations id. When a portal row in the
Models-Variations portal is selected, you script the Models global to
be set to that Variations id, bring up the PartLoc records in the
other portal.

Sounds like you've got most of it worked out aside from a few
details. It helps to know what the db is supposed to accomplish.
Knowing that gives others the ability to answer questions you're not
even asking (but maybe should be).

G

Hi Grip, thanks for the response. I've been working on implementing
what I have and I'll be putting this 'Variations' thing in the next
version of the DB.

You are correct in stating that Variations vary from other Variations,
and not Models.

The DB will be used to track the development of our products that I'm
generically calling 'Models'. Each has a different colour-way, and
I've tried to generalize that into 'Variations', but despite the
different colours, each 'Model' is uniform in terms of material,
composition and manufacturing process.

The list of materials is going to be finite and should be consistent
across the different Models, and by putting them in a master list and
my using references, I'd be able to update our line of products'
materials simply by editing this list.

I'll work on the new iteration of the db over the next couple weeks
(this is a side project as I polish v1 of this thing). Thanks for
taking your time to go over my questions!

Best Regards,

K.

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

Re: Complex Relationships ... ugh. How to set up?

comp.databases.filemaker comp.databases.filemaker

Re: Complex Relationships ... ugh. How to set up? - 03-08-2007 , 08:59 PM