交换数据库？

Question

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

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

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

Answer 1

我不同意我的目的是能够换出数据库，而且我认为你对ORM导致这一目标的怀疑是正确的。

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

Answer 2

我认为数据库抽象的主要用例（通过ORM工具）能够运送适用于多个数据库品牌的产品。我相信公司在数据库供应商之间切换是一种罕见的情况，但这仍然是用例之一。

我从事过工作，我们开始使用MySQL出于货币原因（想想一家初创公司），而我们开始赚钱，想转向Oracle。我们最终没有进行切换，但很高兴有选择。

尽管如此，ORM工具并不是一个完全无泄漏的抽象，而且我知道我们的迁移仍然会带来痛苦和代价。这完全取决于您正在构建的内容，但我的经验是 - 出于性能原因，通常 - 您最终要么在处理ORM解决方案，要么在某些时候利用特定于供应商的功能。

Answer 3

  

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

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

请注意：

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

我看到数据库切换的唯一一次是在项目进行过程中从早期开发到Oracle的HSQL。 ORM使这很容易。

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

对于ORM，我认为目标不是让你切换数据库 - 它是为了隐藏不同数据库实现的复杂性，并且无需担心从关系到对象表示的翻译的细节。你的数据。

通过让某人智能编写处理缓存的ORM，只更新已更改的字段，组更新等，我不需要。虽然在我需要特殊内容的情况下，如果我愿意，我仍然可以恢复到SQL。