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

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

0 голосов
/ 07 августа 2009

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

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, я полагаю, я мог бы генерировать множество выражений падежа из таблиц, но до сих пор я только что загрузил таблицы и использовал внешний инструмент, чтобы сделать по существу то же самое.

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

1 Ответ

1 голос
/ 01 декабря 2009

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

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

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

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

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

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

...