Question

在过去的几年里，我一直致力于在出版业中使用NoSQL数据库的项目。作为一名程序员，作为一个设计SQL数据库的人，我努力做到干。

在以文档为中心的数据库中，DRY似乎被忽略了，它甚至可能对性能和可伸缩性产生不利影响。当然，这是我的同事的信念，他们曾与一些NoSQL供应商合作过，甚至。他们应该知道。

尽管如此，我还是很难实现精神上的飞跃，因为我觉得难以接受DRY和NoSQL是不可混溶的。生活中的许多事情都是从一个方向推得太远，然后以最有效的妥协方式解决。

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

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

“打印”到每个文档中的数据只能通过编写自定义“查找替换”类似的操作来更新，这些操作必须适用于TB级。因此，这些功能增加了成本，并没有明确需要敏捷故事，也没有建立。数据变得更加不一致。

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

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

路

Answer 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：feat支持许多数据库，SQL databases。

使用NoSQL保持DRY

1 个答案: