查询构建器项目的数据库设计

时间:2016-04-23 10:13:37

标签: database database-design database-schema

我有这个项目,用户可以使用基于Web的UI创建查询,其中将列出列和适用的运算符。以后的用户也可以编辑这些查询。所以我需要将它存储在数据库中。

我可以将查询作为简单的字符串存储在表中,但是无法进行编辑,所以我需要以其他方式存储它。所以我设法按照这种方式设计它。

Proposed schema

因此,我要说我必须存储此查询:

C1 > 8 AND (C2 <= 7 OR (C4 LIKE '%all%' AND (C1 > 15 OR C2 <= 3)))

其中:C表示某列

如果我必须将其存储在DB中,如图所示,

  • 我会将每个条件分组并将其存储在sub_operand table
  • 然后在op_master表中为sub_operand表中的每个条目提供递归映射条目
  • 最后将在op_master
  • 中输入主条目

但是处理插入和更新似乎太复杂了。有人可以帮我弄这个吗?我非常困在这里。

更新:我想我在架构中遗漏了一些东西。按照我的想法,它不会起作用。我会在纠正后立即更新问题。

1 个答案:

答案 0 :(得分:1)

我不太确定您使用数据结构来表示公式的树结构的方式。有关此方面,请参阅我对Logical Expressions rules in relational datamodel的回答。 (但你的问题不是那个问题的副本。)

我没有看到插入和更新的复杂性。我能看到的唯一复杂方面是用户输入和编辑这些递归公式的GUI。它有点复杂,因为公式的宽度和深度无限制,您不能只为列和操作数选择定义一个下拉字段集,但是随着用户增加宽度和深度,GUI元素的数量将需要增长。

一旦解决了这个问题,您将拥有以下架构:

Formula GUI --buildFormula--> Formula --storeFormula--> Database
            <--display-------         <-readFormula----

这意味着您在域图层中有一些公式的抽象表示,您可以使用它来实际评估这些公式。而且你需要在数据库中持久化公式。还会显示将公式从GUI传播到域并进一步传播到数据库的操作,反之亦然。

正如我所说,GUI是最复杂的部分。在GUI上使用公式表示,将其发送到域并在编程语言中构建其结构相同的对应物并不是一个问题。如果公式被编辑,即如果它具有现在被用户修改的先前结构,我将不会尝试逐步更新域对象,而是将其丢弃并从头开始构建。存储在数据库中也是如此:删除它的所有部分并将其作为一个整体存储。

阅读也很简单,再次花费一些精力来构建GUI表示。

顺便说一下,将公式的所有子项表示为数据库中的记录并非绝对必要。如果您永远不会查询这些子项,而只是存储和读取整个公式,如果您从未有像select all formulas using a specific column那样的查询,那么将公式存储为单个字符串就足够了。