使用 NoSQL 保持 DRY答案

【问题标题】：Keeping DRY with NoSQL使用 NoSQL 保持 DRY
【发布时间】：2014-09-06 18:23:32
【问题描述】：

在过去的几年里，我参与了出版行业中使用 NoSQL 数据库的项目。作为一名程序员，作为一名刚开始设计 SQL 数据库的人，我努力做到 DRY。

在以文档为中心的数据库中，DRY 似乎被避开了，它甚至可能不利于性能和可扩展性。当然，这是我的同事的信念，他们曾与一些 NoSQL 供应商合作过，甚至为一些 NoSQL 供应商工作过。他们应该知道。

不过，我仍然难以实现精神上的飞跃，因为我发现 DRY 和 NoSQL 是不相容的，我很难接受。生活中的很多事情都是从一种过于偏激的方式开始的，然后以一种最有效的妥协来解决。

数据经常重复，我一直看到完整性问题。我的程序员和 BA 的态度是拥抱它，拥抱它的生命。消费服务一定要处理，还是上游团队的问题。

我想知道为什么文档不是由许多小的子文档组成并被引用、拼接在一起，就像一个视图，我猜。

“打印”到每个文档中的数据只能通过编写自定义“查找替换”之类的操作来更新，这些操作必须跨 TB 工作。因此，这些特性增加了成本，并且对敏捷故事没有明确的需求，也没有被构建。数据变得更加不一致。

将文档分解为子文档的问题是本地数据库搜索停止工作，因为它对文档-子文档关系一无所知。所以搜索必须是一个自定义过程，它搜索子文档，然后整理它们所链接的主文档的外键。

是否存在中间立场，或者是否真的可以接受权衡？在这个问题上找到很多讨论其实并不容易。

卢克

【问题讨论】：

我在谷歌搜索完全相同的东西（“nosql dry”）时发现了这个问题，因为我现在才刚刚开始阅读文档数据库（来自关系数据库背景），这是在我厌倦的主要事情上。在这么多应用程序中，这似乎是对存储空间的巨大浪费。我很惊讶你对这个问题没有答案/ cmets！你有没有发现更多？
到目前为止还没有，丹。我发现这个话题在使用 no-sql 时立即引起了人们的注意，所以我和你一样对为什么我们看起来很孤单感到困惑！ [回声]
Schema-less design guidelines for Google App Engine Datastore and other NoSQL DBs 的可能重复项
在谷歌搜索同一主题时发现了这个问题。仍然没有接受者
好问题，距@AJ. 的评论已经过去了将近一年，但没有答案。皇帝的新装。

标签： json xml nosql

【解决方案1】：

不确定您在哪个平台上，但您是否考虑过在数据库和客户端之间放置一个层？

例如，我喜欢feathersjs 的架构，它可以让您在数据库查询之前/之后运行hooks。在文档和子文档的上下文中，查看包含的钩子 populate 和 dePopulate。

这是 1:1 关系的文档示例：

// users like { _id: '111', name: 'John', roleId: '555' }
// roles like { _id: '555', permissions: ['foo', bar'] }
import { populate } from 'feathers-hooks-common';

const userRoleSchema = {
  include: {
    service: 'roles',
    nameAs: 'role',
    parentField: 'roleId',
    childField: '_id'
  }
};

app.service('users').hooks({
  after: {
    all: populate({ schema: userRoleSchema })
  }
});

// result like
// { _id: '111', name: 'John', roleId: '555',
//   role: { _id: '555', permissions: ['foo', bar'] } }

PS：feathers 支持很多数据库，还有SQL databases。

【讨论】：