Хранение параметризованных определений наборов элементов и однопроходных запросов для извлечения их в SQL

Question

Предположим, что таблица базы данных содержит свойства некоторых элементов:

Table Element (let's say 1 000 000 rows):
ElementId    Property_1    Property_2    Property_3
-------      ----------    ----------    ----------
1            abc            1            1
2            bcd            1            2
3            def            2            4
...

Таблица часто обновляется. Я хотел бы сохранить определения наборов этих элементов, чтобы с помощью одного оператора SQL я мог получить, например.

SetId    Element
---      -------
A        2
B        1
B        3
C        2
C        3
...

Я также хотел бы изменить определения, когда это необходимо. До сих пор я сохранял определения множеств как объединения пересечений, подобные этому:

Table Subset (~1 000 rows):
SubsetId    Property    Value    Operator
--------    --------    -----    --------
1            1          bcd      =
1            3          1        >
2            2          3        <=
...

а также

Table Set (~300 rows):
SetId    SubsetId
---      ------
...
E        3
E        4
F        7
F        9
...

Я полагаю, что в SQL я мог бы генерировать множество выражений падежа из таблиц, но пока я только что загрузил таблицы и использовал внешний инструмент, чтобы сделать по существу то же самое.

Когда я придумал это, я был доволен (и также реализовал это). В последнее время мне стало интересно, так ли это прекрасно, как я думал. Есть ли лучший способ хранить определения наборов?

Answer 1

Я бы подумал, что использование Duck-Typing может быть интуитивно понятным в качестве альтернативы.

Например, все современные языки (C#, Java, Python) имеют концепцию множеств. Если вы собираетесь "пересекать" или "объединять" (операторы множеств) через SQL, то вы должны хранить их реляционным способом. Иначе, почему бы не хранить их на родном языке? (в отличие от реляционных). По сути, я хотел бы сказать, что если бы это было сделано в Python, и мы использовали набор Python, то это то, что я бы сохранил. То же самое с Java или C#.

Таким образом, если set-id 10 имеет элементы 1,4,5,6, он будет сохранен в БД следующим образом:

      SetId              Set
______________________________________
10                       1,4,5,6
11                       2,3
12                       null

Несомненно, это имеет тот недостаток, что он может быть закрытым или даже неэффективным, что вы, вероятно, можете сказать, имея полное определение проблемы. Если вам нужен SQL для анализа, возможно, у моего предложения есть и другие недостатки.

В некотором смысле, функция представления набора каждого из этих языков похожа на DSL (предметно-ориентированный язык) - если вам нужно будет "много говорить" о множестве вещей между классами / объектами приложения, то почему бы не использовать естественный поместиться?