允许查询构建的数据层

Question

我需要提供一个小应用程序，允许客户端针对其本地数据库创建查询（或“规则”）并触发某些操作（发送邮件，短信和内容）。

由于他们将被允许为作业说明实际的SQL，我想知道我的数据层应该是什么样子。我似乎不需要实体和存储库，因为所有数据交互都将被弱化。

那么我的数据层应该做什么？打开连接，接受输入SQL，并返回属性包列表？我甚至需要一个数据层吗？

[更新]

这是客户希望在他的应用程序中拥有的，能够针对他们的数据库编写或构建查询。它将在本地计算机上运行，​​这意味着恶意员工不需要SQL注入攻击。

但即使我有构建查询的可视化控件，验证并清理它，这个层的最终结果是SQL代码，不是吗？如果我想测试它，我该如何抽象呢？

Answer 1

通常，直接从用户接受SQL或SQL查询的任何输入被认为是危险的，因为这样的代码容易发生SQL Injection攻击。相反，如果这不是一次性案例，并且您希望为用户提供查询任何内容的灵活性，则应定义用户将用于指定其过滤条件的中间语言，该语言将用于SQL查询生成。这样，你有

1. 有机会在将用户输入添加到您的查询之前对其进行清理。
2. 将您的对象模型与用户分离，因此如果您希望稍后更改对象模型或存储本身，只要您将适配器从此中间语言编写到修改后，用户就不会受到任何影响对象模型或新存储。

我们在其中一个项目中做到了这一点，为用户提供了对基础数据模型的任何属性进行过滤，排序，分组的灵活性，这种方法非常有效。

Answer 2

使用PL / SQL或更好的ETL工具构建报告数据库/星型模式，这将允许您清理/丰富数据，预先应用业务规则，使用列和表的业务语言而不是技术术语，并使用户查询快速返回，并将像Cognos这样的报告工具放在星型模式上，该模式预先加入用户的所有表格，并允许您应用州长规则以防止用户愚蠢。

这是最简单，最有效的方法，但并不便宜。

Answer 3

实际上，我们在十多年前遇到了几乎相同的问题（尽管它不在本地数据库中）。恕我直言的临时SQL查询（但是它们是创建的，用户可能只有一个文本shell来键入它们），DAL没有多大意义 - 对于应用程序的通用报告/查询部分。这并不意味着您无法为修改数据或将数据输入数据库的应用程序部分使用DAL。

但是，你应该注意一些事情。显然，语法错误的查询应该提供有意义的错误消息，并且应该有可能中断长时间运行的查询。

将特定视图的即席查询访问限制在某些特定视图中，或者提供一定数量的视图，以隐藏数据模型的技术部分，远离用户，这也是一个好主意。我会避免允许您的用户以类似的临时方式修改任何数据 - 确保他们不能将任何UPDATE语句注入由它们创建的SELECT语句中。