更换数据库？

Question

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

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

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

Answer 1

问题1：有人有过这样的经验吗？
将一个数据库替换为另一个数据库
在一个大系统中，并处理
代码中的含义？

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

请注意：

• MS Access 仅用于数据存储和报告生成。
• 服务器应用程序确保仅在服务器上访问 MS Access。 普通的多用户 MS Access 应用程序将通过网络传输大块 Access 数据库 - 导致数据库功能缓慢且不可靠。 本应用程序的情况并非如此。 客户端>> 服务器<> 微软访问。 只有服务器应用程序与 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。