Re: Modeling combinations (options and dependencies)

Поиск
Список
Период
Сортировка
От Peter J. Holzer
Тема Re: Modeling combinations (options and dependencies)
Дата
Msg-id 20230519202504.76plyonjhdt32flz@hjp.at
обсуждение исходный текст
Ответ на Modeling combinations (options and dependencies)  (eacil <eacil@proton.me>)
Список pgsql-general
On 2023-05-18 19:21:23 +0000, eacil wrote:
> -------------------------------------
> DATA
> -------------------------------------
>
> -You have objects that are linked to many tables describing their
> properties, such as an object__tag table.
> -These objects are sold in releases.
> -Thing is, objects can be made of objects. I call them superobjects
> when they assume that container role (as objects, they can be part of
> other superobjects). Multiple releases can be linked to one
> superobject. Yes, it's a parts scenario.
> -Objects can be shuffled in all sorts of unpredictable ways so it's
> useless to think that if one object is contained inside some
> superobject A, if that superobject A will be contained inside another
> superobject B, superobject B will inherit all objects from superobject
> A. In fact, my attempt at a solution will instantiate objects to link
> them to superobjects.
> -In a superobject, multiple objects can be grouped together into a set
> of options. One option can be made of multiple objects (majority of
> the time, just one). You can choose how many options minimum and
> maximum (aka a range) you can choose from a set (majority of the time,
> just one). It's possible to have a NONE choice aka you don't choose
> any option.
> -Any object can have 0 (common), 1 (common), or more (very rare)
> dependencies.
>
> That's pretty much all.

Not sure if I followed that completely, but it certainly looks like a
quite complicated system of constraints.

> CREATE TABLE pairing (
> superobject_id integer NOT NULL,
> instance_a integer NOT NULL,
> instance_b integer NOT NULL,
> CONSTRAINT pairing__pk PRIMARY KEY (superobject_id,instance_a,instance_b)
> );

So if I understand this correctly, you are computing all the
combinations somewhere outside the database and then filling in the
pairings table with all valid pairs? Doesn't that have the same problem
of possibly generating an exponential number of combinations?

I'm also not sure if this is sufficient. If (A,B),(A,C),(A,D),(B,C),
(B,D),(C,D) are all valid combinations within superobject S, does that really
mean that (A,B,C,D) is a valid combination? I suspect you still have to
validate the results.

If you have to validate the results anyway, maybe you can radically
simplify the filter: Just add one row for each object which can possibly
appear in each super-object (or even: 1 row for each super-object with
an array of objects). Then find all super-objects which can contain all
the objects you are looking for and finally filter those in your
application. (Although I wonder how fast that validation is: That also
looks like it could potentially have exponential runtime)

        hp

--
   _  | Peter J. Holzer    | Story must make more sense than reality.
|_|_) |                    |
| |   | hjp@hjp.at         |    -- Charles Stross, "Creative writing
__/   | http://www.hjp.at/ |       challenge!"

Вложения

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

Предыдущее
От: "Peter J. Holzer"
Дата:
Сообщение: Re: Is there a good way to handle sum types (or tagged unions) in PostgreSQL?
Следующее
От: Laurenz Albe
Дата:
Сообщение: Re: Unexpected cross-database vacuum impact with hot_standby_feedback=on