代码之家  ›  专栏  ›  技术社区  ›  Marius Burz

具有多个RDBMS的PHP、Python、Ruby应用程序

  •  2
  • Marius Burz  · 技术社区  · 16 年前

    当我看到所有这些生成SQL的数据库抽象层和所有这些窗体时,我开始觉得自己很过时,尽管我还远没有老。我理解他们的需要,但他们的使用扩散到了他们通常不属于的地方。

    我坚信,使用数据库抽象层来生成SQL并不是编写应该在多个数据库引擎上运行的数据库应用程序的正确方法,尤其是当您插入非常昂贵的数据库(如Oracle)时。这或多或少是全球性的,它不适用于少数几种语言。

    仅举一个简单的例子,使用查询分页和插入:使用Oracle时,可以使用第一行并附加提示(如果合适)。在高级示例中,我可以提到在数据库中放入许多有意义的存储过程/包。每个RDBMS都是不同的。

    通过只使用一组有限的特性(通常可用于许多RDBMS),人们不会利用那些昂贵的高级数据库引擎所提供的可能性。

    所以回到问题的核心:如何开发应该在多个数据库引擎上运行的PHP、Python、Ruby等应用程序?

    我特别感兴趣的是,您如何分离/使用专门为在单个RDBMS上运行而编写的查询。假设您有一个应该在3个RDBMS上运行的语句:Oracle、DB2和SQL Server,对于每一个都编写一个单独的SQL语句,以便利用RDBMS提供的所有功能。你是怎么做到的?

    把这件事放在一边,你觉得走这条路怎么样?你觉得值得吗?为什么?为什么不呢?

    4 回复  |  直到 16 年前
        1
  •  2
  •   Adam Byrtek    16 年前

    你不能吃蛋糕然后吃它,选择下面的选项。

    • 尽可能使用数据库抽象层,在极少数情况下,如果需要手工查询(例如性能原因),请坚持使用最低的公分母,不要使用存储过程或数据库必须提供的任何专有扩展。在这种情况下,在不同的RDBMS上部署应用程序应该是很简单的。
    • 使用昂贵的RDBMS的全部功能,但是要考虑到您的应用程序不容易移植。当需要时,您将不得不在移植和维护上花费大量的精力。当然,将所有差异封装在一个模块或类中的体面的分层设计将有助于这项工作。

    换句话说,您应该考虑将应用程序部署到多个RDBMSE的可能性,并做出明智的选择。

        2
  •  2
  •   timdev    16 年前

    如果您想利用各种RDBMSE的钟声和哨声,您当然可以做到。只需应用标准OO原则。找出持久性层需要提供哪种API。

    最后您将编写一组同构持久性适配器类。从模型代码的角度(将调用适配器方法来加载和存储数据),这些类是相同的。编写好的测试覆盖应该很容易,好的测试会让生活变得容易很多。决定持久性适配器提供了多少抽象是最棘手的部分,并且在很大程度上是特定于应用程序的。

    至于这是否值得麻烦:这要看情况而定。如果你以前从未做过,这是一个很好的练习。如果你不确定你的目标数据库是什么,这可能还为时过早。

    一个好的策略可能是启动两个持久性适配器。假设您希望最常见的后端将是MySQL。实现一个为MySQL调优的适配器。实现第二种方法,使用您选择的数据库抽象库,并且只使用标准的、广泛可用的SQL特性。现在,您已经获得了对大量后端的支持(所有内容都由您选择的抽象库支持),以及对MySQL的优化支持。如果您决定要从Oracle提供一个优化的适配器,您可以在空闲时实现它,并且您将知道您的应用程序可以支持可交换的数据库后端。

        3
  •  0
  •   Azeem.Butt    16 年前

    如果为一个平台编写的代码彼此都能工作而不做任何修改,那就太好了,但通常情况并非如此,而且可能永远不会如此。当前的框架所做的是尽可能多的工作。

        4
  •  0
  •   mhawke    16 年前

    它甚至比现代的变形金刚更“老式”,但没有 ODBC 解决这个问题?