似乎许多 ORM 工具和自定义数据访问层(DAO 模式等)的目标是将数据库抽象到可以用最少的工作换出整个数据库系统的程度。
在代码中遵循常见的 DAL 模式通常是一个好主意,但换出数据库似乎永远不会是最小的工作。(成本、培训、数据迁移等)
有没有人有在大型系统中将一个数据库换成另一个数据库并处理代码中的影响的经验?是否值得担心从代码中抽象出实际的数据库?
似乎许多 ORM 工具和自定义数据访问层(DAO 模式等)的目标是将数据库抽象到可以用最少的工作换出整个数据库系统的程度。
在代码中遵循常见的 DAL 模式通常是一个好主意,但换出数据库似乎永远不会是最小的工作。(成本、培训、数据迁移等)
有没有人有在大型系统中将一个数据库换成另一个数据库并处理代码中的影响的经验?是否值得担心从代码中抽象出实际的数据库?
我不同意其目的是能够交换数据库,并且我认为您对导致该目标的 ORM 表示怀疑是正确的。
但是,我仍然会使用 ORM,因为它抽象出了数据访问的细节。这不是面向对象编程的目标吗?把你的顾虑分开。
我认为数据库抽象(通过 ORM 工具)的主要用例是能够发布与多个数据库品牌一起使用的产品。我相信公司在数据库供应商之间切换的情况很少见,但这仍然是用例之一。
我从事过一些工作,我们出于金钱原因开始使用 MySQL(想想一家初创公司),并且我们开始赚钱,想切换到 Oracle。我们最终没有做出改变,但很高兴有这个选择。
尽管如此,ORM 工具并不是一个完全无泄漏的抽象,我知道我们的迁移仍然会很痛苦且代价高昂。这完全取决于您要构建的内容,但根据我的经验,通常出于性能原因,您最终要么围绕您的 ORM 解决方案工作,要么在某些时候利用供应商特定的功能。
问题 1:是否有人在大型系统中将一个数据库换成另一个数据库,并处理代码中的影响?
是的,我们试过了。我们的客户正在使用一个大型的基于 MS Access 的 Delphi 客户端服务器应用程序。大约五年后,我们考虑切换到 SQL Server。我们分析了这个问题并得出结论,交换数据库的成本非常高,而且只能提供一些优势。客户决定不交换数据库。该应用程序仍然运行良好,客户仍然很高兴。
注意:
您必须考虑的最重要的问题:
问题 2:是否值得担心从代码中抽象出实际的数据库?
是的。在理想情况下,交换数据库只是调整数据连接字符串。在现实世界中这是不可能的,因为所有数据库都是不同的。它们都有表和 SQL 支持,但区别在于细节。如果您可以通过抽象来屏蔽数据库的差异 - 请这样做。列出您需要支持的数据库。检查所选数据库系统是否存在差异。提供集中式代码来处理差异。支持一个 RDBMS 并为将来支持其他 RDBMS 提供存根。
我唯一一次看到数据库切换是在项目进展期间从早期开发期间的 HSQL 到 Oracle。ORM 让这一切变得简单。
我经常使用 DAO 模式来交换数据服务(从数据库到 Web 服务或将 Web 服务交换到测试存根)。
对于 ORM,我不认为目标是让您能够切换数据库 - 它是让您远离不同数据库实现的复杂性,并且无需担心将数据的关系表示转换为对象表示的精细细节。
通过让某人聪明地编写一个处理缓存的 ORM,只更新已更改的字段、分组更新等,我不需要。虽然在我需要一些特殊的情况下,如果我愿意,我仍然可以恢复到 SQL。