N all-way relationship

From: "Ryan" <pgsql-sql(at)seahat(dot)com>
To: <pgsql-sql(at)postgresql(dot)org>
Subject: N all-way relationship
Date: 2003-05-13 14:16:31
Message-ID: 11523.65.102.128.233.1052835391.squirrel@fordparts.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-sql

OK SQL wizards, chew on this.

I am trying to visualize the best way to store and retrieve information in
a an all-way relationship with an unknown number of elements.

This is largely related to cross referencing part numbers. You have a
factory part and any number of aftermarket vendors making compatible parts
for that factory part (they are all theoretically interchangeable).

So given a factory number of 123.
if one vendor makes the part 456 that equates to 123, then, well that's
quite easy. You need a lookup table that corresponds 123 to 456, and for
reverse lookups you store 456 - 123. (you have a whopping two records)

But if you throw in a few more vendors and things get a bit more crazy.
All of a sudden parts 789, ABC and XYZ now all copy 123 (and by proxy, 456)
so you could keep doing things the structured way,
123 - 456
123 - 789
123 - ABC
123 - XYZ
456 - 123
456 - 789
456 - ABC
456 - XYZ
...
XYZ - 789
XYZ - ABC

You get the idea, you now have 20 records for five parts. Now multiply
that by the hundreds of thousands. If another vendor added a compatable
part, you just added 10 new records.

Now to the meat of my question.

Is there a better way to do this?

How could I store all this information in a single record with the unknown
number of matches, yet at any point ask for a single part and get all the
parts that would be compatible? Without breaking joins? (Each vendor has
its own price book.)

It just seems to me that there would be a more elegant solution.

Ryan

Responses

Browse pgsql-sql by date

  From Date Subject
Next Message Adam Sherman 2003-05-13 16:19:42 Locating all Children given Set of Parents
Previous Message SEB Menard 2003-05-13 12:15:44 Questions for experts