Database 交换数据库？

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

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

---

有没有人有过在大型系统中从一个数据库切换到另一个数据库以及处理代码中的含义的经验？从代码中抽象出实际的数据库值得吗？

我唯一一次看到数据库切换是在项目进展的早期开发阶段从HSQL切换到Oracle。ORM使这变得容易

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

对于ORM，我认为其目标不是让您能够切换数据库，而是让您不必担心不同数据库实现的复杂性，也不必担心数据从关系到对象表示的转换细节

---

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

我不同意这样做的目的是为了能够交换数据库，我认为您对ORM导致这一目标的怀疑是正确的

---

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

我认为数据库抽象（通过ORM工具）的主要用例是能够提供与多个数据库品牌协同工作的产品。我相信公司很少会在数据库供应商之间进行切换，但这仍然是一个用例

我曾经做过这样的工作：我们开始使用MySQL是出于金钱上的原因（比如一家初创公司），后来我们开始赚钱，想转用Oracle。我们最终没有做出改变，但有了选择真是太好了

尽管如此，ORM工具并不是一个完全没有泄漏的抽象，我知道我们的迁移仍然是痛苦和昂贵的。这完全取决于您正在构建什么，但根据我的经验，出于性能原因，通常情况下，您要么使用ORM解决方案，要么在某个时候利用特定于供应商的特性

问题1:有人有过类似的经验吗 从一个数据库切换到另一个数据库 在一个大系统中，处理 代码中的含义

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

请注意：

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

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

SQL语句：（选择、更新、删除、插入、创建表）并确保它们与SQL数据库兼容。令人惊讶的是，所有的RDBMS在细节（日期格式、数字格式、搜索格式、字符串格式、连接语法、创建表语法、存储过程、用户定义函数、（自动）主键等）上有多大的不同

报告生成：根据您的数据库，您可能会使用不同的报告工具。我们的客户有200多份复杂的报告。转换所有这些报告非常耗时

性能：所有RDBMS在不同的环境中具有不同的性能。通常，性能优化在很大程度上依赖于RDBMS

成本：工具、开发人员、服务器和用户许可证的成本差异很大。它的范围从免费到非常昂贵。免费并不意味着便宜和昂贵并不总是等同于好。必须进行成本/价值比较

经验：充分利用RDBMS需要经验。如果您必须开发一个“未知”的RDBMS，那么您的生产力将受到影响

问题2:值得担心吗 从数据库中提取实际数据库 你的密码

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