2

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

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

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

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

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

4

4 回答 4

5

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

这是一个有趣的比较，我相信它是合理的。

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

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

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

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

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

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

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

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

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

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

封装变化的东西

于 2009-12-13T10:43:28.630 回答
1

我使用 Hibernate，它给了我 ORM 和数据库独立性的好处。数据库特定的功能是不可能的，这通常会改善我的设计。一切（领域模型、业务逻辑和数据访问方法）都是可测试的，因此开发并不痛苦。

于 2009-12-13T07:42:11.930 回答
1

مرحبا , 穆罕默德！

数据库独立性既不是“好”也不是“坏”。这是一个设计决策；这是一个权衡。

让我们谈谈选择：

这将导致难以维护代码
这是您的程序员的选择。如果你让你的代码独立于数据库，那么你应该在你的代码和数据库之间使用一个层。最好的层是别人写的。

...在所有受支持的 DBMS 中具有最少通用特性的数据库设计
根据定义，这是正确的。幸运的是，所有支持的数据库中的共同特性都相当广泛。它们都应该实现 SQL-99 标准。

...糟糕的性能和糟糕的可扩展性 这不应该是真的。该层应该为数据库增加最小的成本。

...这是有史以来最复杂的功能，可能会以指数方式增加开发成本和时间。代码将是可怕的。 同样，我建议您在代码和数据库之间使用一层。

您没有指定要编写的语言或平台。幸运的是，许多语言已经抽象出数据库：

祝你好运。

于 2009-12-13T08:05:57.837 回答
0

数据库独立性是一个被高估的应用程序特性。实际上，大型业务应用程序在构建和部署后迁移到新的数据库平台的情况非常少见。您也可能会错过 DBMS 的特定功能和优化。

也就是说，如果您真的想包括数据库独立性，您最好针对接口或抽象类编写所有数据库访问代码，例如在 .NET System.Data.Common 命名空间（DbConnection、DbCommand 等）中使用的那些。或使用支持多个数据库的 O/RM 库，如NHibernate。

于 2009-12-13T07:54:47.670 回答