Question

假设您有一个巨大的应用程序，其数据访问层绑定到SQL 您希望提供其他非SQL DAL，例如GoogleAppEngine实例或基于XML的备份。您将如何处理迁移到不同的存储范例，但灵活性有限，因为它是遗留的。

我可能在这里缺少信息，但我想到的一个解决方案是首先将当前的旧DAL重写为标准API库，例如JDO;从那里开始，基于特定技术的学习曲线，与任何存储接口将是一个时间问题。

AND OR NAND？

Answer 1

很大程度上取决于具体细节，但根据您的描述，我可能会首先构建一个带DAO的数据访问层，明确定义接口和当前商店的实现。

一旦启动并运行，您就可以开始创建新存储接口的实现并逐步迁移。

Answer 2

理论上，正如您所提到的，您只需要使用一些标准接口（如JPA），并更改其背后的实现或存储。不幸的是，在实践中，这并不是那么顺利。它可以做到，但你肯定会花一些时间在你没想到的问题上。

我首先要稳定服务界面，然后按功能迁移功能。从最简单的一个开始，这个东西足够小并且与系统的其他部分分开。

但是，作为第一步，重写代码以使用某些标准接口并不是一个坏主意。众所周知， JDO 可以更好地处理非关系数据库，因此您可以从选择它中受益。

对于 Google App Engine ，如果您已经考虑过RDBMS，那么很可能需要完全更改您的数据模型。仅举几个约束，没有JOIN，你也不能在查询中使用OR。所以我建议你在进入一个庞大的迁移项目之前先试验一下。

Answer 3

GAE / J for BigTable使用的DataNucleus也支持使用JDO对XML进行持久化。因此，支持对此的持久性也是微不足道的。你在GAE / J中的加入能力有限......不是JDO的限制，只是他们如何在GAE / J插件中实现这样的东西。

- 安迪（DataNucleus）

Answer 4

实际上， GAE / J确实有a limited JDO API;他们使用JDO命名是误导...... :(

另一方面，正如您所建议的那样，JDO支持Joins，as annotations和/或as metadata，之后可以使用JDOQL查询检索它们。

如果我错了，请纠正我，但JDO \ JDOQL感觉不如SQL查询强大。 SQL的强大功能是能够动态连接多个相关表。我仍然无法看到如何从我的webapp支持这个简单示例的查询。

（人）架构：产品系列有许多目录，其中包含许多产品，任何< em> invoice 包含任何产品

SELECT a.id, a.name, b.id, b.name, c.id, c.name  from products a
left join catalog b on b.id = a.fk_catalog_id
left join productline c on c.id = b.fk_productline_id
where a.id in (select distinct product_id from invoice_product where invoice_id = <PARAM> )

坚持不懈;或将遗留的webapp移动到非关系型商店

4 个答案: