在MVC框架中为实例应用程序组合noSQL和ORM

在过去的几年里,我一直在尝试将一些关于noSQL(couchDB,mongoDB,Redis ......)的"酷"的东西用于实际应用.

我已经习惯用Django编写应用程序,并开始使用Play!当Java是唯一可接受的部署选项时(并且也享受它).两者都有模块可以工作,例如MongoDB,django也有nonrel.但我从来没有觉得需要没有SQL.

直到我终于找到了我认为是面向文档的存储的一个很好的用例,比如MongoDB.

用例

假设我们必须管理一些复杂项目的排序和跟进(无论如何).这些项目可能有很多不同的属性,例如.过度简化我们可以:

一个可以拥有的冰箱

一两扇门,

属于A,B或C类,

表面颜色

独立或内置

一个可以有的烤箱:

燃气或电力或两者兼而有之

自我清洁与否

独立或内置

SQL/ORM解决方案

如您所见,每个对象都可以有几个可以按类型约束的属性.

在我通常使用ORM的RDBMS中,我会定义一个"产品"模型,然后继承两个模型,一个冰箱和一个烤箱.如果一个冰箱在一段时间之后再获得一个属性,我会修改模型 - 因此,模式 - ,运行迁移,并添加一列.

noSQL解决方案

我能想到的noSQL解决方案是:

使用RDF(类似Virtuoso或构建我自己的简化三元组存储)

使用面向文档的数据库,如MongoDB

问题

但是,我在了解如何失败不同的(容易)的发展将务实地仍然使用与正确的适配器(尤其是DODB)框架ORM切换到NoSQL的解决方案.

假设我通过mongodb-engine将Django与MongoDB一起使用.

我仍然使用相同的ORM,所以我仍然将这些对象描述为模型,列出所有属性.因此,ORM完成了同样的工作!如果模型发生变化,生成迁移的成本对于ORM(特别是像South这样的东西)非常有限,没有什么需要自己学习新技术.

DODB可能有/其他/有优势,有些特定于MongoDB(可伸缩性,数据处理,可能是性能)但是......我正在描述的确切用例和问题怎么样？

我很可能错过了一点,所以这里有真正的问题:

对于这个特定的用例:

这个例子对于DODB来说是好还是坏(你有一个好的)吗？

将ORM用于基本内容(用户,订单)和没有 ORM 的noSQL 用于复杂对象是否有意义,是否有一个令人信服的理由完全切换到noSQL,或者我应该继续使用ORM/SQL库存？

我理解回答这些问题可能是部分主观的,所以你可以完全了解noSQL和SQL理论,并存储ORM; 存在从库存ORM到noSQL DB的良好桥梁.让我们假设我们正在讨论MongoDB的这个用例作为noSQL替代方案.

但是有一个更普遍的问题 - 这是SO帖子的核心问题:

是不是一个好的ORM(如JPA,ActiveRecord或Django的那个)使noSQL,特别是面向文档的数据库几乎没用？

...并且使用带有"经典"ORM的noSQL值得吗？

(从编程和维护的角度来看,"少用",性能和类似标准是另一回事,需要精确的产品对产品比较)

[编辑]

我也想要了解的是,在切换到noSQL时使用ORM是不是更好.拥有更多"动态"模型会更好,例如.我可以有一个表格来描述冰箱和烤箱模型是什么(字段),代码中的冰箱和烤箱模型可以动态构建它们的视图(用于编辑的表单和用于显示的列表).

相关问题:

[编辑]:这些是在这里展示我的研究,但也澄清我所要求的不是关于noSQL与SQL的通用

使用NoSQL API的ORM是多余的吗？:相似!但我试图了解为什么大多数框架(见上文)通过他们的ORM提供noSQL访问.这是个好主意吗？

为什么使用带有NoSql的ORM(如MongoDB):比前一个更具体,但仍然是另一种方式.我在争论ORM使noSQL无用,而不是相反!

何时用NoSQL替换RDBMS/ORM

何时使用MongoDB或其他面向文档的数据库系统？

https://softwareengineering.stackexchange.com/questions/54373/when-would-someone-use-mongodb-or-similar-over-traditional-rdms

编辑 和链接:

Siena:Java的持久性API,受到Google App Engine Python数据存储区的启发,试图在SQL和NoSQL世界之间架起一座桥梁.

minimongo:MongoDB的轻量级,无模式,Pythonic面向对象的接口

Mike Purcell.. 5

这就是我拖曳stackoverflow所得到的。很长时间以来，有人问了一个悬而未决的问题，我被迫提供2美分（冒我自己的项目时间表的风险）。

我刚刚完成了一个项目，在该项目中，我不得不将ORM与模型分离，以便可以实施NoSQL解决方案，并且发现它并不那么困难，尽管有时试图找出最佳方法很困难。因此，我不会太具体地介绍我的实现，所以我将介绍使它工作所需要做的事情，因为当您沿着相同的道路前进时，它可能会提供一些启发。

我的设置：

框架-Symfony 1.4

ORM-教义1.4

NoSQL-我自己的专有解决方案

目标：

将图像路径存储在xml文件和数据库中

将xml描述路径存储在xml文件和数据库中

我不想将图像作为Blob存储在持久性存储（数据库）中，也不想将图像路径存储在数据库中，因为我不想支付创建数据库连接和查询的开销。路径。因此，我决定将路径信息存储在NoSQL持久存储（文件系统）中。

同样，对于html描述，我不想在表上创建文本列并存储数据库中可能包含数百行html的行，其原因与上述相同。

我所有的NoSQL文件都与一个对象有关（例如，冰箱）。这些文件包含指向其相关资产（html描述和图像）的路径，在我称之为指针的指针中，它们指向文件系统上的资产。我选择使用XML格式存储数据，因此看起来像这样：

// Path to pointer file
/home/files/app/needle/myApp/refrigerator/1/1.xml

// Example pointer
/home/files/app/file/myApp/refrigerator/1.png

现在，在框架内，我必须重写save（）方法，以便可以使用NoSQL API保存上述资产。这很容易，我只检查了父调用并维护了进入方法的值，因此它们不会破坏任何我不知道的链式逻辑（使用相同参数调用其他方法的方法）。由于主save（）调用包装在try / catch块中，因此我还使自定义NoSQL API调用引发异常。在这里，您唯一需要注意的是确定NoSQL资产是否值得停止整个事务。在我的示例中，我不得不弄清楚上载图像是否会破坏将其余表单字段保存到数据库中（我选择破坏事务）。

我还不得不更改load（）方法以使用NoSQL API与标准模型逻辑来检索资产。与保存方法一样，这也不难做到。我只需要查看父类正在做什么，而不必考虑任何参数值。

一切都说完了之后，我就能够在文件系统上存储图像和html描述，并且有一个由指向它们位置的指针组成的xml文件。因此，现在我不需要每次需要资产时都进行数据库调用。

一些注意事项（这些可能包含在其他NoSQL解决方案中，我必须自己编写）：

您将无法查询包含持久性存储中的图像的冰箱。您将必须在应用程序中编写一些逻辑以从NoSQL存储中提取资产。

备份：在备份持久性存储数据时，还需要备份NoSQL数据。

孤儿：既然您的架构不知道您可能拥有的任何资产，那么从持久性存储中删除一行将孤立文件系统上的一项资产。因此，请确保您的应用程序具有删除行后清除NoSQL存储的逻辑。

我想我遇到了在使用ORM实施NoSQL解决方案时遇到的所有主要障碍，如果您有任何其他问题可以随时提出来。

-编辑-

对评论的回应：

如前所述，我不想创建数据库连接和查询只是为了获取资产的路径。我觉得最好使用NoSQL解决方案来处理此类信息，因为实际上没有理由针对此类信息（图像或html说明）运行查询。

开发自己的NoSQL解决方案更多是自我挑战。在工作中，有一个实施自定义NoSQL解决方案的项目（使用MogileFS的经验很差），并且坦率地说，该项目的设计不良且实施不佳。但是，我不只是指出坏处，还挑战了自己，提出了一个更好的解决方案，但只是针对一个附带项目。由于存在挑战，我没有研究任何已经可用的NoSQL解决方案，但事后看来，我可能应该这样做。

我仍然认为您可以通过用ORM的Model层覆盖crud函数来实现MongoDB或任何NoSQL解决方案，相对容易。实际上，不仅实现了我的NoSQL解决方案，而且还添加了在Crud函数期间将数据索引到SOLR（用于全文搜索）的功能，因此一切皆有可能。

1> Mike Purcell..：

---

这就是我拖曳stackoverflow所得到的。很长时间以来，有人问了一个悬而未决的问题，我被迫提供2美分（冒我自己的项目时间表的风险）。

我刚刚完成了一个项目，在该项目中，我不得不将ORM与模型分离，以便可以实施NoSQL解决方案，并且发现它并不那么困难，尽管有时试图找出最佳方法很困难。因此，我不会太具体地介绍我的实现，所以我将介绍使它工作所需要做的事情，因为当您沿着相同的道路前进时，它可能会提供一些启发。

我的设置：

框架-Symfony 1.4

ORM-教义1.4

NoSQL-我自己的专有解决方案

目标：

将图像路径存储在xml文件和数据库中

将xml描述路径存储在xml文件和数据库中

我不想将图像作为Blob存储在持久性存储（数据库）中，也不想将图像路径存储在数据库中，因为我不想支付创建数据库连接和查询的开销。路径。因此，我决定将路径信息存储在NoSQL持久存储（文件系统）中。

同样，对于html描述，我不想在表上创建文本列并存储数据库中可能包含数百行html的行，其原因与上述相同。

我所有的NoSQL文件都与一个对象有关（例如，冰箱）。这些文件包含指向其相关资产（html描述和图像）的路径，在我称之为指针的指针中，它们指向文件系统上的资产。我选择使用XML格式存储数据，因此看起来像这样：

// Path to pointer file
/home/files/app/needle/myApp/refrigerator/1/1.xml

// Example pointer
/home/files/app/file/myApp/refrigerator/1.png

现在，在框架内，我必须重写save（）方法，以便可以使用NoSQL API保存上述资产。这很容易，我只检查了父调用并维护了进入方法的值，因此它们不会破坏任何我不知道的链式逻辑（使用相同参数调用其他方法的方法）。由于主save（）调用包装在try / catch块中，因此我还使自定义NoSQL API调用引发异常。在这里，您唯一需要注意的是确定NoSQL资产是否值得停止整个事务。在我的示例中，我不得不弄清楚上载图像是否会破坏将其余表单字段保存到数据库中（我选择破坏事务）。

我还不得不更改load（）方法以使用NoSQL API与标准模型逻辑来检索资产。与保存方法一样，这也不难做到。我只需要查看父类正在做什么，而不必考虑任何参数值。

一切都说完了之后，我就能够在文件系统上存储图像和html描述，并且有一个由指向它们位置的指针组成的xml文件。因此，现在我不需要每次需要资产时都进行数据库调用。

一些注意事项（这些可能包含在其他NoSQL解决方案中，我必须自己编写）：

您将无法查询包含持久性存储中的图像的冰箱。您将必须在应用程序中编写一些逻辑以从NoSQL存储中提取资产。

备份：在备份持久性存储数据时，还需要备份NoSQL数据。

孤儿：既然您的架构不知道您可能拥有的任何资产，那么从持久性存储中删除一行将孤立文件系统上的一项资产。因此，请确保您的应用程序具有删除行后清除NoSQL存储的逻辑。

我想我遇到了在使用ORM实施NoSQL解决方案时遇到的所有主要障碍，如果您有任何其他问题可以随时提出来。

-编辑-

对评论的回应：

如前所述，我不想创建数据库连接和查询只是为了获取资产的路径。我觉得最好使用NoSQL解决方案来处理此类信息，因为实际上没有理由针对此类信息（图像或html说明）运行查询。

开发自己的NoSQL解决方案更多是自我挑战。在工作中，有一个实施自定义NoSQL解决方案的项目（使用MogileFS的经验很差），并且坦率地说，该项目的设计不良且实施不佳。但是，我不只是指出坏处，还挑战了自己，提出了一个更好的解决方案，但只是针对一个附带项目。由于存在挑战，我没有研究任何已经可用的NoSQL解决方案，但事后看来，我可能应该这样做。

我仍然认为您可以通过用ORM的Model层覆盖crud函数来实现MongoDB或任何NoSQL解决方案，相对容易。实际上，不仅实现了我的NoSQL解决方案，而且还添加了在Crud函数期间将数据索引到SOLR（用于全文搜索）的功能，因此一切皆有可能。