交换数据库？

Question

似乎许多 ORM 工具和自定义数据访问层（DAO 模式等）的目标是将数据库抽象到可以用最少的工作换掉整个数据库系统的程度。

在代码中遵循常见的 DAL 模式通常是一个好主意，但换出数据库似乎永远不会是最小的工作。 （成本、培训、数据迁移等）

有没有人在大型系统中将一个数据库换成另一个数据库并处理代码中的影响？是否值得担心从代码中抽象出实际的数据库？

Answer 1

问题 1： 有没有人有这方面的经验 将一个数据库换成另一个 在一个大系统中，并处理 代码中的含义？

是的，我们试过了。我们的客户正在使用一个大型的基于 MS Access 的 Delphi 客户端服务器应用程序。大约五年后，我们考虑切换到 SQL Server。我们分析了这个问题并得出结论，交换数据库的成本非常高，而且只能提供一些优势。客户决定不交换数据库。应用程序仍然运行良好，客户仍然很满意。

注意：

• MS Access 仅用于数据存储和报告生成。
• 服务器应用程序确保 MS Access 仅在服务器上被访问。普通的多用户 MS Access 应用程序将通过网络传输大量 Access 数据库 - 导致数据库功能缓慢且不可靠。此应用程序不是这种情况。客户端 服务器 MS 访问。只有服务器应用程序与 MS Access 数据库通信。实际上，服务器拥有对 MS Access 数据库的独占访问权限。没有其他计算机可以打开 MS Access 数据库。结论：MS Access 正被用作真正的 RDBMS，关系数据库管理系统 - 请不要对 MS Access 低劣和不稳定感到愤怒 - 它已经运行了 10 多年。

您必须考虑的最重要的问题：

1. SQL 语句：（SELECT、UPDATE、DELETE、INSERT、CREATE TABLE）并确保它们与 SQL 数据库兼容。令人惊讶的是，所有 RDBMS 在细节上的差异（日期格式、数字格式、搜索格式、字符串格式、连接语法、创建表语法、存储过程、用户定义的函数、（自动）主键等）
2. 报告生成：根据您的数据库，您可能使用不同的报告工具。我们的客户有 200 多份复杂的报告。转换所有这些报告非常耗时。
3. 性能：所有 RDBMS 在不同的环境下都有不同的性能。通常，性能优化很大程度上取决于 RDBMS。
4. 成本：工具、开发人员、服务器和用户许可的成本差异很大。它的范围从免费到非常昂贵。免费并不意味着便宜，昂贵并不总是等同于好。必须进行成本/价值比较。
5. 经验：充分利用您的 RDBMS 需要经验。如果您必须为“未知”的 RDBMS 开发，您的工作效率将会受到影响。

问题 2： 是否值得担心 从中抽象出实际的数据库 你的代码？

是的。在理想情况下，交换数据库只是调整数据连接字符串。在现实世界中这是不可能的，因为所有数据库都是不同的。它们都有表和 SQL 支持，但区别在于细节。如果您可以通过抽象来屏蔽数据库的差异 - 请这样做。列出您需要支持的数据库。检查所选数据库系统是否存在差异。提供集中式代码来处理差异。支持一个 RDBMS 并为将来支持其他 RDBMS 提供存根。

Answer 2

我不同意其目的是能够交换数据库，并且我认为您对导致该目标的 ORM 表示怀疑是正确的。

但是，我仍然会使用 ORM，因为它抽象出了数据访问的细节。这不是面向对象编程的目标吗？将您的顾虑分开。

Answer 3

我认为数据库抽象（通过 ORM 工具）的主要用例是能够发布与多个数据库品牌一起使用的产品。我认为公司在数据库供应商之间切换的情况很少见，但这仍然是用例之一。

我曾从事过一些工作，我们出于金钱原因开始使用 MySQL（想想是一家初创公司），并且我们开始赚钱，想改用 Oracle。我们最终没有做出改变，但很高兴有这个选择。

不过，ORM 工具并非完全无泄漏的抽象，我知道我们的迁移仍然会很痛苦且代价高昂。这完全取决于您要构建的内容，但根据我的经验，通常出于性能原因，您最终要么围绕您的 ORM 解决方案工作，要么在某些时候利用供应商特定的功能。

Answer 4

我见过的唯一一次数据库切换是在项目进展过程中从早期开发期间的 HSQL 到 Oracle。 ORM 让这一切变得简单。

我经常使用 DAO 模式来交换数据服务（从数据库到 Web 服务或将 Web 服务交换到测试存根）。

对于 ORM，我不认为目标是让您能够切换数据库 - 它是让您远离不同数据库实现的复杂性，并且无需担心从关系到对象表示的转换的精细细节你的数据。

通过让某人聪明地编写一个处理缓存的 ORM，只更新已更改的字段、分组更新等，我不需要。虽然在我需要一些特殊的情况下，如果我愿意，我仍然可以恢复到 SQL。