数据库独立性

Question

我们正处于设计具有多个模块的大型业务应用程序的早期阶段.其中一个要求是应用程序应该独立于数据库,它应该支持SQL Server,Oracle,MySQL和DB2.

根据我在网上看到的内容,数据库独立性是一个非常糟糕的主意:它会导致难以维护的代码,数据库设计在所有受支持的DBMS中具有最不常见的功能,性能差和可扩展性差.我个人的直觉是,这个功能的复杂性,比任何其他功能更多,可能会以指数方式增加开发成本和时间.代码将是可怕的.

但我不能说服任何人忽略这个功能.问题是关于这个问题的大多数数据都是经验数据,缺乏支持案例的数字.如果有人可以在这个问题上分享任何数字支持的数据,我将不胜感激.

其中一个可能的设计选项是将Entity框架用于数据库层,并为每个DBMS使用提供程序.我个人的感觉是,在没有任何ORM的情况下手动编写SQL语句将是"必须",因为您无法控制实体框架生成的SQL,并且独立于数据库的场景需要基于DBMS进行一些SQL调整,代码是定位,我认为第三方实体框架提供商将有大量的错误,这些错误只出现在应用程序将具有的复杂场景中.我希望听到之前有过使用实体框架进行数据库独立场景的经验的人.

此外,团队讨论的一种可能性是在第一次迭代中支持一个DBMS(例如SQL Server),然后在连续迭代中添加对其他DBMS的支持.我想,既然我们需要一个数据库的设计与最常见的功能,这一发展战略是不好的,因为我们需要知道的所有数据库的所有功能之前,我们开始第一个DBMS编写代码.我也需要听听你关于这种可能性的消息.

Answer 1

您是否看过不同SQL实现的比较？

这是一个有趣的比较,我相信它是合理的.

为应用程序设计良好的关系数据模型应该与数据库无关,原因很简单,所有RDBMS都旨在支持关系数据模型的功能.

另一方面,模型的实现通常受到指定实现的人的个人偏好的影响.每个人都有自己的倾向,例如你autoincremented identity在上面的评论中提到的.这些个人的实施偏好是限制可移植性的障碍.

在这些行之间进行读取,对数据库独立性的要求已经从上面传下来了,并指示了这一点.该应用程序似乎也可能是出售而非内部使用.在上下文中,潜在客户的数据库偏好在此阶段是未知的.

鉴于这些要求,实际问题包括:

1. 谁将支持每个特定的数据库进行设计和开发？这很重要,因为需要协调实现这些人的个人偏好以实现数据库中立的解决方案.如果特定数据库没有冠军,那么在这个数据库上实现应用程序的可能性很小,如果有的话.
2. 谁具有深度的数据库经验,担任冠军的主持人？这个人有时候必须做出一些艰难的决定,但是马匹是乐趣的一部分.
3. 如果没有他们个人最喜欢的功能,编程团队是否会高效工作？存储过程,触发器等是RDBM之间可移植性最差的特性.

应用程序本身的规范还需要明确区分数据库不可知和数据库特定的设计元素/章节/模块/等等.除此之外,这允许首先使用一个DBMS实现,并且需要为每个后续DBMS实现所需的定义的工作.

与数据库无关的部分应包括所有DML或ORM(如果使用的话).

特定于数据库的部件应该或多或少地限于安装和驱动程序.

信不信由你,香草风味的sql仍然是一种非常强大的编程语言,我个人认为如果你愿意的话,你不可能创建一个没有数据库特定功能的高性能应用程序.

总之,设计与数据库无关的应用程序是一个简单的指令的扩展:

封装各种不同的东西