我们正处于设计具有多个模块的大型业务应用程序的早期阶段。其中一个要求是应用程序应该独立于数据库，它应该支持SQL Server，Oracle，MySQL和DB2。
根据我在网上看到的内容，数据库独立性是一个非常糟糕的主意：它会导致难以维护的代码，数据库设计在所有受支持的DBMS中具有最少的共同特性，性能差和可扩展性差。我个人的直觉是，这个功能的复杂性，比任何其他功能更多，可能会以指数方式增加开发成本和时间。代码将是可怕的。
但我不能说服任何人忽略这个功能。问题是关于这个问题的大多数数据都是经验数据，缺乏支持案例的数字。如果有人可以分享任何数字支持的数据，我将不胜感激。
可能的设计选项之一是将Entity框架用于数据库层，并为每个DBMS使用提供程序。我个人的感觉是，在没有任何ORM的情况下手动编写SQL语句将是“必须”，因为您无法控制实体框架生成的SQL，并且独立于数据库的场景需要基于DBMS进行一些SQL调整，代码是定位，我认为第三方实体框架提供商将有大量的错误，这些错误只出现在应用程序将具有的复杂场景中。我希望听到之前有过使用实体框架进行数据库独立场景的经验的人。
此外，团队讨论的一个可能性是在第一次迭代中支持一个DBMS（例如SQL Server），然后在连续迭代中添加对其他DBMS的支持。我认为，由于我们需要一个具有最少公共特性的数据库设计，因此我们需要在开始为第一个DBMS编写代码之前了解所有数据库的所有功能，因此这个开发策略很糟糕。我也需要听到你关于这种可能性的消息。
答案 0 :(得分：5)
你看过Comparison of different SQL implementations吗？
这是一个有趣的比较，我相信它是合理的。
为您的应用程序设计良好的关系数据模型 应该与数据库无关 ，原因很简单，所有RDBMS都旨在支持关系数据模型的功能。 / p>
另一方面，模型的实施通常受到指定实施的人的个人偏好的影响。每个人都有自己的倾向，例如你在上面的评论中提到了autoincremented identity。这些个人的实施偏好是限制可移植性的障碍。
在这些行之间进行读取，数据库独立性的要求已经从上面传下来了，的指令使其成为。该应用程序似乎也可能是出售而非内部使用。在上下文中，潜在客户的数据库偏好在此阶段是未知的。
鉴于此类要求，实际问题包括：
应用程序本身的规范还需要明确区分数据库不可知和数据库特定的设计元素/章节/模块/等等。除此之外，这允许首先使用一个DBMS实现，并且需要为每个后续DBMS实现定义的工作。
与数据库无关的部分应包括所有DML，如果您使用的话，还应包含ORM。
特定于数据库的部分应该或多或少地限于安装和驱动程序。
不管你信不信，vanilla-flavored sql仍然是一种非常强大的编程语言，我个人认为你不可能在没有特定于数据库的特性的情况下创建一个高性能的应用程序，如果你想总之，设计与数据库无关的应用程序是一个简单的规则的扩展：
封装变化的内容
答案 1 :(得分：1)
我使用Hibernate，它给了我ORM的好处和数据库独立性。数据库特定的功能是不可能的，这通常会改善我的设计。一切（领域模型，业务逻辑和数据访问方法）都是可测试的，因此开发并不痛苦。
答案 2 :(得分：1)
مرحبا，穆罕默德！
数据库独立既不“好”也不“坏”。这是一个设计决定;这是一种权衡。
让我们谈谈选择：
这将导致难以维护的代码
这是程序员的选择。如果您使代码与数据库无关，那么您应该在代码和数据库之间使用一个层。最好的一层是其他人写的。
...所有受支持的DBMS中具有最少共同功能的数据库设计
根据定义，这是真的。幸运的是，所有支持的数据库中的共同特征相当广泛;他们都应该实现SQL-99标准。
......糟糕的性能和糟糕的可扩展性 这不应该是真的。该层应该为数据库增加最小的成本。
...这是有史以来最具特色的功能，可能会因复杂性而成倍增加开发成本和时间。代码将是可怕的。 同样，我建议您在代码和数据库之间使用一个层。
您没有指定您要撰写的语言或平台。幸运的是，许多语言已经抽象出了数据库：
答案 3 :(得分：0)
数据库独立性是一种被高估的应用程序功能。实际上，在构建和部署大型业务应用程序之后，很少将其移动到新的数据库平台上。您还可以错过DBMS特定功能和优化。
也就是说，如果你真的想要包含数据库独立性，你可能最好针对接口或抽象类编写所有数据库访问代码，比如.NET System.Data.Common命名空间中使用的那些（DbConnection，DbCommand，等）或使用支持多个数据库的O / RM库，如NHibernate。