代码之家  ›  专栏  ›  技术社区  ›  Promit

以统一的方式查询不同数据库引擎的最佳方法?

  •  2
  • Promit  · 技术社区  · 15 年前

    我在C客户机应用程序上工作( SlimTune Profiler )它使用关系型(并且可能是嵌入式)数据库引擎作为后备存储。当前版本已经需要处理sqlite和SQL Server Compact,我想尝试支持其他系统,如mysql、firebird等。更糟的是,我希望它支持插件 任何 其他支持数据存储——理想情况下不一定是基于SQL的。最重要的是,前端本身支持插件,所以我在查询代码和处理查询的引擎之间有一个未知的多对多映射。

    现在,查询基本上是通过原始SQL代码处理的。我已经遇到了使复杂的选择以可移植的方式工作的麻烦。随着时间的推移,问题只会变得更糟,这甚至没有考虑支持非SQL数据的想法。那么,以理智的方式查询完全不同的引擎的最佳方法是什么呢?

    我考虑过一些基于LINQ的东西,可能是 DbLinq 项目。另一种选择是对象持久性框架, Subsonic 例如。但我不太确定外面有什么,有什么限制,或者我只是希望太多。

    (顺便说一下,对于一个不可避免的问题,为什么我不解决一个引擎。我喜欢让用户选择最适合他们的引擎。SQL Compact允许复制到完整的SQL Server实例。sqlite是可移植的,支持内存数据库。我可以想象这样一种情况:一家公司希望插入一个MySQL插件,这样他们就可以轻松地存储和整理一个应用程序的性能数据。最后,最重要的是,我发现我必须依赖底层数据库引擎的实现细节的想法是荒谬的。)

    3 回复  |  直到 15 年前
        1
  •  1
  •   Community paulsm4    7 年前

    使用对象关系映射器。这将提供远离不同数据库引擎的高级别抽象,并且不会对您可以运行的查询类型施加(许多)限制。许多ORM还包括LINQ支持。关于提供建议和比较(例如 What is your favorite ORM for .NET? 似乎是最新的,并与其他几个链接)。

        2
  •  2
  •   Paul Mendoza    15 年前

    最好的办法是为所有数据库访问使用一个接口。然后,对于您希望支持的每个数据库类型,执行该数据库的接口实现。这就是我过去为项目所做的。

    许多数据库系统和存储工具的问题在于它们旨在解决不同的问题。您甚至可能不想将数据存储在SQL数据库中,而是将其作为文件存储在Web应用程序的app_data文件夹中。通过接口方法,您可以很容易地做到这一点。

    一般来说,没有一个解决方案能够很好地适应所有数据库和存储解决方案,甚至其中的一些解决方案也很好。如果你找到一个声称是的,我还是不相信。当你对其中一个数据库有问题时,对你来说挖掘你的对象要比挖掘他们的对象容易得多。

        3
  •  0
  •   NerdFury    15 年前

    我建议使用存储库模式。您可以创建一个类来封装您需要数据库执行的所有操作,然后为您想要支持的每个数据库类型创建不同的实现。在许多情况下,对于相对数据存储,可以使用ADO.NET抽象(IDBConnection、IDataReader、IDataAdapter等),创建单个通用存储库,并且只为不提供ADO.NET驱动程序的数据库类型编写特定的实现。

    public interface IExecutionResultsRepository
    {
      void SaveExecutionResults(string name, ExecutionResults results);
      ExecutionResults GetExecutionResults(int id);
    }
    

    我真的不知道你在存储什么,所以你必须根据你的实际需要调整它。我还猜想这需要一些重的重构,因为您的代码中可能到处都是SQL语句。将它们取出并封装可能是不可行的。但依我看,这是实现你想做的最好的方法。