NoSql参考数据 [英] NoSql Referential Data

问题描述

免责声明：通过参考数据，我不意味着参照完整性

我正在学习nosql，建模。例如，在CMS应用程序的典型关系数据库中，您可能有两个表：article和author，其中article有对作者的引用。

在nosql系统中，您可以以这种方式创建文章文档，因为它们只是伪装对象图

  {
 title：在5分钟内学习nosql，
 slug：nosql_is_easy，
 author：{firstName：Smarty
 lastName：Pants
} 
 
 {
 title： Death to RDBMS，
 slug：rdbms_sucks，
 author：{firstName：Smarty
 lastName：Pants
} 
  
 
 
 
等等... 
 
 
 
说一天Smarty Pants先生决定将其名称更改为Regular Joe，因为nosql已变得无处不在。在这种用例中，需要扫描每篇文章，并更新作者的姓名。
 
 
 
所以我的问题是，如何在nosql中建模数据以适应基本使用CMS的案例，以便性能与RDBMS 相当或更快？  mongodb ，例如，声明CMS作为用例... 
 
 
 
 编辑：
 
 
 
很少有人已经建议将数据归一化，例如：
  article 
 {
 title：Death to RDBMS，
 slug：rdbms_sucks，
 author： {id：10000001} 
} 
 
 author 
 {
 name：Big Brother，
 id：10000001
 } 
  
但是，由于nosql设计缺少连接，所以你必须使用mapreduce-以将数据集中在一起。如果这是您的建议，请评论此类操作的效果。
 
 
 
 编辑2： 
 
 
 
如果你认为nosql不是适合任何类型的数据需要参考数据的解决方案，请也解释为什么。这似乎使nosql的用例相当有限，因为任何合理的应用程序将包含关系数据。
 
 
 
 编辑3： 
 
 
  Nosql不平均非关系 
解决方案
我假设CouchDB是一个NoSQL数据库，如果你这么说。 
 
 
但实际上，我们有通用目的编程语言和领域专用语言。类似地，CouchDB是一个域专用的数据库。
 
 
 
我使用CouchDB很多，但我真的不在乎它是使用SQL还是NoSQL 。 CouchDB是有价值的（对我来说），因为API是100％的HTTP，JSON和Javascript。您可以使用浏览器从CouchDB获取HTML然后通过AJAX查询数据来构建Web应用程序。说这是不是SQL是一个低估！
 
 
 
无论如何，回到Smarty裤子和常规乔。也许他有10万份文件。如果我们只是更新他们所有，硬的方式呢？噢，这是一个相当少量的Javascript。
  $。getJSON（'/ db / _design / cms / _view / by_user ？key = Smarty + Pants'，{
 success：function（result）{
 //在结果对象中更改名称
 var docs = result.rows.map function（row）{
 row.value.firstName =Regular; 
 row.value.lastName =Joe; 
 return row.value; 
}）
 
 //存储它
 $ .post（'/ db / _bulk_docs'，{docs：docs}，function（）{
 console.log（Done！ Smarty Pants in+ docs.length +documents！）; 
}）
} 
}）
   
 
是的，这种技术会让你在计算机科学类中的F。但是，我喜欢它。我会在Firebug中写这个代码。在我的浏览器。重命名不是原子的，并且没有引用完整性。另一方面，它可能会在几秒钟内完成，没有人会关心。
 
 
 
你可能会说CouchDB在流行语和基准测试失败，敲击。
 
 
 
 PS  by_user 视图是从map-reduce构建的。在CouchDB中，map-reduce是 incremental ，这意味着它像大多数SQL索引一样执行。所有查询以短暂，可预测（对数）时间结束。
 
Disclaimer: by referential Data, i do not mean referential integrity

I am learning nosql and would like to understand how data should by modeled.  In a typical relational database for an CMS application, for example, you may have two table: article and author, where article have an reference to the author.  

In nosql system, you may create an article document this way since they are just disguised object graph
{
title: "Learn nosql in 5 minutes",
slug: "nosql_is_easy", 
author: {firstName: "Smarty"
          lastName: "Pants"
}

{
title: "Death to RDBMS",
slug: "rdbms_sucks", 
author: {firstName: "Smarty"
          lastName: "Pants"
}
and so on... 

Say one day Mr. Smarty Pants decided to change his name to Regular Joe because nosql has become ubiquitous.  In such uses case, every article would need to be scanned and the author's name updated.

So my questions is, how should the data be modeled in nosql to fit the basic uses cases for an CMS so that the performance is on par or faster than RDBMS? mongodb, for example, claims CMS as an use-case ...

Edit:

Few people have already suggesting normalizing the data like:
article 
{
title: "Death to RDBMS",
slug: "rdbms_sucks", 
author: {id: "10000001"}
}

author
{
name: "Big Brother",
id: "10000001"
}
However, since nosql, by design, lack joins, you would have to use mapreduce-like functions to bring the data together.  If this is your suggestion, please comment on the performance of such operation.

Edit 2:

If you think nosql is not suitable solution for any kind of data that requires referential data, please also explain why.  This would seem to make the use case for nosql rather limited since any reasonable application would contain relational data.

Edit 3:

Nosql doesn't mean non-relational
解决方案
I suppose CouchDB is a NoSQL database, if you say so.

But really, we have general-purpose programming languages, and domain-specific languages. Similarly, CouchDB is a domain-specific database.

I use CouchDB a lot but I really don't care whether it uses SQL or NoSQL. CouchDB is valuable (to me) because the API is 100% HTTP, JSON, and Javascript. You can build web applications with the browser fetching HTML from CouchDB and then querying for data over AJAX. To say this is "not SQL" is an understatement!

Anyway, back to Smarty Pants and Regular Joe. Maybe he has 100,000 documents. What if we just updated them all, the hard way? Well, that is a pretty small amount of Javascript.
$.getJSON('/db/_design/cms/_view/by_user?key=Smarty+Pants', {
  success: function(result) {
    // Change the name right here, in the result objects.
    var docs = result.rows.map(function(row) {
      row.value.firstName = "Regular";
      row.value.lastName = "Joe";
      return row.value;
    })

    // Store it!
    $.post('/db/_bulk_docs', {"docs":docs}, function() {
      console.log("Done! Renamed Smarty Pants in " + docs.length + " documents!");
    })
  }
})
Yes, this technique would get you an F in computer science class. However, I like it. I would write this code in Firebug. In my browser. The rename is not atomic and it has no referential integrity. On the other hand, it would probably complete in a couple of seconds and nobody would care.

You might say CouchDB fails at the buzzwords and benchmarks but aces the school of hard knocks.

P.S. The by_user view is built from map-reduce. In CouchDB, map-reduce is incremental which means it performs like most SQL indexes. All queries finish in a short, predictable (logarithmic) time.

                        
这篇关于NoSql参考数据的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！