代码之家  ›  专栏  ›  技术社区  ›  Ville Koskinen

存储元素集的参数化定义和单次传递查询以在SQL中获取它们

  •  0
  • Ville Koskinen  · 技术社区  · 17 年前

    假设一个数据库表包含一些元素的属性:

    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中,我想我可以从表中生成许多case表达式,但到目前为止,我只是加载了表,并使用一个外部工具来做基本上相同的事情。

    当我想到这一点时,我很高兴(并且也实施了它)。最近我一直在想它是否像我想的那样美妙。有没有更好的方法来存储集合的定义?

    1 回复  |  直到 14 年前
        1
  •  1
  •   blispr    16 年前

    我想用鸭子打字 可以 在这里要直观,作为一种选择。

    例如,所有的现代语言(C语言,Java,Python)都有集合的概念。如果要通过SQL“相交”或“联合”(set operators),则必须以关系方式存储它们。否则,为什么不以语言本地方式存储它们呢?(与关系相反)。以本机方式,我的意思是如果它是在Python中完成的,并且我们使用了一个Python集,那么这就是我将坚持的内容。与Java或C语言相同。

    因此,如果集合ID 10具有成员1、4、5、6,它将在数据库中持久化,如下所示:

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

    当然,这有一个缺点,那就是它可能是专有的,甚至可能是非性能的——当您有完整的问题定义时,您可能会知道这一点。如果您需要SQL来分析它,也许我的建议有更多的缺点。

    从某种意义上说,每种语言的集合表示特性都像DSL(特定于域的语言)——如果您需要在应用程序类/对象之间“谈论”大量的集合内容,那么为什么不使用自然匹配呢?