将 ORM 与 NoSQL 存储一起使用是不好的做法？答案

【问题标题】：Bad practice to have ORMs with NoSQL stores?将 ORM 与 NoSQL 存储一起使用是不好的做法？
【发布时间】：2014-01-15 20:25:32
【问题描述】：

我在我的 Python 平台中使用 Redis (redis-py)。最近有人建议我切换到 ORM。

例如：python-stdnet、rom 或 redisco

在 NoSQL 世界中使用 ORM 是否被视为不好的做法？

【问题讨论】：

Redis 的 ORM 甚至可以做什么？ Redis 是一个键值对存储。
我知道。目的是为语义“模型”提供抽象接口。我目前有一个名为“User”的类，有一堆 StrictRedis 调用。使用（例如：rom || redisco）以使我的 User 类更简洁+通用是不好的做法吗？
我在节点上遇到了与 Mongoose 类似的问题。对于 No-SQL，我认为 ODM 术语更为普遍。我总结了一件事，“如果你认为你可以取消它，那么就不要使用它”。至于您的查询，我不会像 Blender 之前提到的那样去做，它是一个键值存储。当您处理基于模式的数据库时，ODM 非常有用，而这在 Redis 中显然很少使用。
ORM 表示对象 relational 映射器，如 relational 数据库。当您处理 Redis 等非关系型数据库时，该术语是用词不当。

标签： python orm nosql redis key-value-store

【解决方案1】：

最终问题归结为你想在哪一层写代码。

您想编写代码来操作远程数据库中的数据结构，还是想编写使用建立在这些数据结构之上的抽象的高级代码？你可以把它想象成一个关于关系数据库的类似问题，你想写 SQL，还是想写更高级的代码？

就个人而言，尽管我自己使用rom 来完成各种任务（我是作者），但我也在有意义的相同项目中直接操作 Redis。

【讨论】：

我同意这个答案。我探索了 redisco 和 this blog，这个库简单地使用了 redis 的功能，但使存储、检索和引用对象变得非常容易。最终它会节省时间，尽管 @Josiah 会判断 rom 是否有时间效率。
如果您以前使用过 ORM，那么使用 rom 会比较省时。它没有连接，因此取决于项目可能不是所有问题的完美解决方案。但对于大多数新项目，我通常从 rom 开始。

【解决方案2】：

指出 ORM 中的 R 用于关系的评论在技术上是正确的。这并不意味着抽象 redis 的库没有有效的用途和理由。

有一些很棒的库可以让与 redis 的交互感觉更好，更符合您所使用的语言。对于像ohm 或redis-native_hash （披露：我写了那个）这样的ruby 库，就这样做。对于 python，有像 redisco 这样的工具，当然还有其他工具。这些使得持久化对象到 redis 变得非常简单，并且让使用 redis 感觉更像 ruby 或 python-ish。

以下是使用最基本的抽象的更多好处，例如您可以编写并保留在应用程序中的非常薄的包装器：

切换 redis 客户端会更容易。也许你永远不会这样做，但如果你这样做了，在一个地方（你的包装器）更改对 redis 的调用比在使用 redis 的任何地方更改它们要简单得多。
如果您的调用是通过某种抽象进行的，那么实现扩展可能需要的东西（例如分片或连接池）可能会更容易。
如果有抽象，用其他键/值存储或数据结构服务器替换 redis 会更简单。

我并不是在提倡使用对象映射库或构建您自己的抽象，只是指出您这样做的正当理由。由您来评估您的需求并选择最适合您的方法。直接调用redis也没有错。

【讨论】：

+1 在抽象方面。 ORM 中的“R”更多地与关系代数相关，而不是关系数据库。关系代数定义了"Projection" 操作，根据底层数据模型，它可以有不同的实现。关系代数从未指定“TABLE”。它使用常用的数学工具（集合、元组、有序集合等）指定数据描述。