基于Web的特定于域的查询构建器的模式或构思(不用于报告)吗?

时间:2010-12-15 05:05:59

标签: sql adhoc

也许这是在黑暗中拍摄的,但我试图找出是否有人对我们提出的这个问题有所了解。

情况是我们有一个数据库,其中包含有关大型项目列表的各种数据。有许多表都提供有关项目的支持信息,以1对1的方式,其中一些特定类型的项目信息(比如ProjectInfoTypeA)可能存储在名为ProjectInfoTypeA的表中,我们将进行内部联接在它和项目表之间,以及1到多个,例如ProjectScopeKeywords,其中可以为项目分配N个属性,或者在这种情况下为许多不同的属性/查找表分配“关键字”。

最后,我们需要让用户在我们的网络应用中构建如下内容: 向我展示过去5年内完成的至少需要4年时间完成的所有项目,成本至少为1百万美元,并且将所有这3个关键字(x,y,z)与之相关联。

我们还希望用户能够保存他们的查询,以便他们和其他用户可以从已保存的查询列表中选择它们。

一旦我们从他们的过滤器中获取项目列表,我们就需要以各种方式使用它:但不是作为报告。如果这是一份报告,我只是给他们一些报告构建器,但我们需要在Web应用程序中使用他们的过滤列表。

目前我们正在考虑两种不同的想法: 1)我们只是尝试编写自己的UI来构建查询,然后创建一些巨大的SQL语句。

2)我们将有关每个过滤器的数据存储在数据库中,然后当他们点击“搜索”时,我们基本上会通过迭代地剥离与每个查询不匹配的项目来删除项目列表。他们存储在数据库中的数据。

我猜测没有人不得不处理这样的事情,但如果你们有任何人,我会有兴趣听到任何值得研究的建议/模式。

1 个答案:

答案 0 :(得分:1)

我建议选择选项1.我在许多项目中使用了查询构建器方法,具有不同程度的复杂程度,具体取决于需求的复杂程度。

如果您可以使用现成的解决方案,可以在网上找到几个:http://www.google.com/search?q=sql+query+builder

对于自定义构建的解决方案,您至少可能希望为用户提供展平视图以进行查询;这将简化设计器的复杂性,减少用户的学习曲线,并提供一些针对未来架构更改的抽象。

在定义基础数据源之后,您需要提供用户可以选择特定列,定义过滤条件,指定值聚合和定义子查询(基于示例查询要求)的方法。列选择和过滤器定义不应该太难,但是值聚合和子查询创建对于定义来说并不重要。您应该能够使用现成的解决方案作为如何向用户提供此功能的示例。