N all-way relationship

Поиск
Список
Период
Сортировка
От Ryan
Тема N all-way relationship
Дата
Msg-id 11523.65.102.128.233.1052835391.squirrel@fordparts.com
обсуждение исходный текст
Ответы Re: N all-way relationship
Re: N all-way relationship
Re: N all-way relationship
Список 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



В списке pgsql-sql по дате отправления:

Предыдущее
От: "A.Bhuvaneswaran"
Дата:
Сообщение: Re: Why this query does not work?
Следующее
От: Adam Sherman
Дата:
Сообщение: Locating all Children given Set of Parents