0

いくつかの要素のプロパティを含むデータベーステーブルを想定します。

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では、テーブルから多くのケース式を生成できると思いますが、これまでのところ、テーブルをロードし、外部ツールを使用して基本的に同じことを実行しました。

私がこれを思いついたとき、私は満足しました（そしてそれを実装しました）。最近、思ったほど素晴らしいのかと思っていました。セットの定義を保存するためのより良い方法はありますか？

4

1 に答える 1

1

代わりに、ここではダックタイピングを使用するのが直感的かもしれないと思います。

たとえば、すべての現代語（C＃、Java、Python）にはセットの概念があります。SQLを介して「交差」または「和集合」（集合演算子）を実行する場合は、それらをリレーショナルな方法で格納する必要があります。それ以外の場合は、言語ネイティブの方法でそれらを保存しませんか？（リレーショナルとは対照的に）。ネイティブの方法では、Pythonで実行され、Pythonセットを使用した場合、それが永続化されることを意味します。JavaまたはC＃と同じです。

したがって、set-id 10にメンバー1、4、5、6がある場合、次のようにDBに永続化されます。

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

確かに、これには、独自仕様である可能性がある、またはパフォーマンスが低い可能性があるという欠点があります。これは、完全な問題定義があるため、おそらくわかります。それを分析するためにSQLが必要な場合、おそらく私の提案にはさらに欠点があります。

ある意味で、これらの各言語のセット表現機能はDSL（ドメイン固有言語）のようなものです-アプリケーションクラス/オブジェクト間で多くのセットを「話す」必要がある場合は、自然なものを使用してみませんかフィット？

于 2009-11-30T21:32:24.237 に答える