数据库独立性

Question

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

从我在网上读到的内容来看，数据库独立性是一个非常糟糕的主意:它会导致代码难以维护、数据库设计在所有受支持的 DBMS 中具有最不常见的功能、糟糕的性能和糟糕的可扩展性.我个人的直觉是，与其他任何功能相比，此功能的复杂性可能会成倍地增加开发成本和时间。代码将是可怕的。

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

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

此外，团队讨论的一种可能性是在第一次迭代中支持一个 DBMS(例如 SQL Server)，然后在后续迭代中添加对其他 DBMS 的支持。我认为，由于我们需要一个具有最少通用特性的数据库设计，所以这种开发策略是不好的，因为在我们开始为第一个 DBMS 编写代码之前，我们需要了解所有数据库的所有特性。关于这种可能性，我也需要听听您的意见。

Answer 1

你看过Comparison of different SQL implementations了吗？ ？

这是一个有趣的比较，我相信它是最新的。

为您的应用程序设计良好的关系数据模型应该与数据库无关，原因很简单，所有 RDBMS 都旨在支持关系数据模型的特性。

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

从字里行间看出，数据库独立性的要求是从上面传下来的，并指示做到这一点。该应用程序似乎也可能用于销售而不是内部使用。在上下文中，潜在客户的数据库偏好在这个阶段是未知的。

鉴于这样的要求，那么实际的问题包括:

1. 谁将支持每个特定数据库的设计和开发？这一点很重要，因为需要协调每个人的个人偏好以实现数据库中立的解决方案。如果特定数据库没有冠军，那么在此数据库上实现应用程序可能会做得很差，如果有的话。
2. 谁拥有丰富的数据库经验来担任冠军的主持人？这个人有时不得不做出一些艰难的决定，但讨价还价是乐趣的一部分。
3. 如果没有他们个人最喜欢的所有功能，编程团队能否保持高效？存储过程、触发器等是 RDBM 之间可移植性最低的功能。

应用程序本身的规范还需要明确区分与数据库无关的和特定于数据库的设计元素/章节/模块/等等。除其他事项外，这允许首先使用一个 DBMS 实现，然后为每个后续 DBMS 实现所需的明确工作。

与数据库无关的部分应该包括所有的 DML，或者如果你使用 ORM。

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

信不信由你，vanilla-flavoured sql 仍然是一种非常强大的编程语言，我个人认为如果没有特定于数据库的功能，您不太可能无法创建高性能应用程序，如果您愿意 .

总而言之，设计与数据库无关的应用程序是一个简单规则的扩展:

---

Encapsulate what varies

---