如果您的用户将输入除了最简单的选择语句之外的任何内容,那么您将很难做到这一点。我想为您的项目编写一个完整的 SQL 解析器会非常昂贵,但这基本上就是您所说的。
对于我们拥有的本土 ORM,我有一个类,它将本质上预定义的 SQL 查询转换为可以与 一起使用的东西DataTable.Select
,但是 where 子句是从 SqlParameters 生成的。
可能的解决方案
也许您可以结合以下项目来接近您所追求的:
Linqer(SQL 到 LINQ 转换器)然后是 LINQ 到 DataSet
我自己没有使用过 Linqer。
其他一些想法
我相信你一直在考虑这个问题,但是这样做的困难可能意味着如果你缩小一点,会有更好的方法。严格来说,使用未知查询查询缓存意味着您必须用所有可能的数据填充缓存,或者能够在提交查询时调用该数据。根据定义,这不能提供比直接查询源更好的性能,除非您在缓存过时之前充分访问缓存以使其值得。对于临时报告系统(我的假设),我倾向于怀疑情况是否如此,并且我还担心它在除边缘情况之外的任何情况下都不会胜过数据库引擎。
@JoshC 还提到了使用 Sqlite 的可能性,还有可能符合要求的 SQL Server 2012 LocalDB,尽管这些肯定不是 .net 数据集。