使用NoSQL保持DRY

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

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

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

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

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

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

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

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

卢克