标签: document-oriented-db

我听过很多关于无架构(通常是分布式)数据库系统的讨论,比如MongoDB,CouchDB,SimpleDB等......

虽然我可以理解它们可能在某些方面很有价值,但在我的大多数应用程序中,我都试图持久化具有特定类型字段的对象,而我只是在关系模型中自动思考.我一直在考虑具有唯一整数id的行,null/not null字段,SQL数据类型和用于查找集的select查询.

虽然我被这些新系统的分布式特性和简单的JSON/RESTful接口所吸引,但我不明白松散类型的键/值哈希将如何帮助我进行开发.为什么松散类型的无架构系统能够保持干净的数据集？例如,我怎样才能找到日期介于x和y之间的所有项目？是否有任何加入的概念？

我知道很多系统都有自己的差异和优势,但我想知道范式的差异.我想这是一个开放式的问题,但也许社区的答案以及他们亲眼看到这些系统优势的方式将有助于启发我和其他人关于何时我想要使用这些(当然更髋关节)系统而不是传统的RDBMS.

最近我和MongoDB一直在合作,我不得不说我非常喜欢它.然而,它是一个完全不同类型的数据库然后我被使用.我注意到它对于某些类型的数据肯定更好,但是对于高度规范化的数据库,它可能不是最佳选择.

然而,在我看来,它可以完全取代你可能拥有的任何关系数据库,并且在大多数情况下表现更好,这令人难以置信.这让我想问几个问题:

1. 面向文档的数据库是否正在开发为下一代数据库,并且基本上完全取代了关系数据库？
2. 是否可能更好地使用面向文档的数据库和关系数据库,以获得更适合其中一种的各种数据？
3. 如果面向文档的数据库不是要替换关系数据库,那么有没有人有一个数据库结构的例子,在关系数据库中绝对会更好(反之亦然)？

在工作中,我们最近使用CouchDB(面向文档的数据库)开始了一个项目.我一直很难学习所有关系数据库知识.

我想知道你们有些人克服了这个障碍？你是如何停止关系思考并开始在文档上思考的(我为弥补这个词而道歉).

有什么建议？有帮助的提示？

编辑:如果它有任何区别,我们使用Ruby&CouchPotato连接到数据库.

编辑2:SO正在骚扰我接受答案.我认为,我选择的是帮助我学习最多的那个.但是,我想,没有真正的"正确"答案.

我想为我的带有NoSQL数据库的node.js应用程序实现分类结构(地理术语).我有一个与MySQL类似的分类结构,但现在是时候向前推进并学习新东西,所以我决定尝试不同的方法并使用NoSQL(面向文档)来测试我的测试应用程序.分类结构很简单 - 有五个不同的级别:国家(即英国)→地区(英格兰)→县(默西塞德郡)→城市/城镇/村庄(利物浦)→城市的一部分(Toxteth).

显而易见的选择是使用树木结构,但魔鬼在细节 - 历史上一些城市和城镇属于其他县.这个想法是用那些术语来标记出生在某些城市或城镇的人,然后用地理标记过滤它们,所以我必须尊重利物浦或曼彻斯特(以及其他人)在某些人出生时属于兰开夏郡的事实. .否则,任何用户使用我的地理过滤器获得的结果都将是错误的.

例如:约翰·多伊于1957年出生于布莱克本(兰开夏郡).保罗·布朗1960年出生于利物浦(兰开夏郡,现为默西塞德郡).Georgia Doe(nee Jones)5年后出生在威勒尔(柴郡,现在的默西塞德郡).他们的儿子林戈于1982年出生于利物浦(默西塞德郡).

约翰是兰开斯特出生的,保罗是兰开斯特和梅西大学,格鲁吉亚同时来自柴郡和默西塞德郡,林戈来自默西塞德郡.所以当我按县搜索时,应该对它们进行相应的分类.但是,随着国家现代结构的简单一对多结构,他们永远不会被过滤掉.

如何使用NoSQL(首先是面向文档的)解决方案来实现集合的复杂性？我用Google搜索并对堆栈进行了一些研究*但仍然不知道下一步该做什么.在我看来,有几种可能的解决方法:

1. 使用类似SQL的数据结构:

   {
       {'name': 'United Kingdom', 'unique_id': 1},
       {'name': 'England', 'unique_id': 2, 'parents': [1]},
       {'name': 'Merseyside', 'unique_id': 3, 'parents': [2]},
       {'name': 'Lancashire', 'unique_id': 4, 'parents': [2]},
       {'name': 'Liverpool', 'unique_id': 5, 'parents': [3, 4]},
   }
   

   Run Code Online (Sandbox Code Playgroud)

2. 使用树结构和一些引用:

   {    
       {'name': 'United Kingdom', 'unique_id': 1
           {'name': 'England', 'unique_id': 2]
               {'name': 'Merseyside', 'unique_id': 3]
                   {'name': 'Liverpool', 'unique_id': 5, 'alternate_parents': [4]},
               },
               {'name': 'Lancashire', 'unique_id': 4},
           },
       },
   }
   

   Run Code Online (Sandbox Code Playgroud)

3. 使用没有引用的树结构(一对多)并手动将"alternate parent"标记添加到文档中:

   {    
       {'name': …

   Run Code Online (Sandbox Code Playgroud)

我对面向文档的数据库很感兴趣,我想和MongoDB一起玩.所以我开始了一个相当简单的项目(一个问题跟踪器),但我很难以非关系的方式思考.

我的问题:

1. 我有两个彼此相关的对象(例如issue = {code:"asdf-11", title:"asdf", reporter:{username:"qwer", role:"manager"}}- 这里我有一个与问题相关的用户).我应该创建另一个文档"user"并通过其id(如关系数据库)在"issue"文档中引用它,还是应该将所有用户的数据保留在子文档中？

2. 如果我在文档中有对象(子文档),我可以在一个查询中更新它们吗？

我正在研究一些面向文档的商店的成熟度,其中包括在生产环境中使用数据库的应用程序和网站的概述.CouchDB和MongoDB有几个列表和案例研究,包括:

• CouchDB在野外
• MongoDB生产部署

我很难找到在生产中使用RavenDB的应用程序和网站.有没有人有这方面的第一手经验,或在RavenDB上运行的(众所周知的)网站的例子？

我正在尝试使用mongo db实现博客文章存储.

我有两个域实体:

"博客帖子"和"作者"

目前我已将AuthorId属性添加到博客帖子实体.这是存储对象之间关系的正确方法吗？

我知道面向文档的NoSQL DB是KV模型的"扩展",因为它们允许您查询的不仅仅是单个查找键.但是,一旦某个东西成为"文档",我觉得它已经有了一个关系模型:

"myJson": {
    "fizz": 4,
    "buzz": "true",
    "widget" : {
        ...etc.
    }
}

对我来说,我没有看到这个JSON,json_objects带有fizz和buzz字段的表以及与第二个widgets表的外键关系之间的区别.

而"柱状"DB就像Cassandra听起来就像是直接的关系/表DB.

所以我问:面向文档和列的DB有什么不同,所以区别于它们(与RDBMS)有什么区别？在某些情况下,它们最适合解决哪些问题使它们优于关系数据库？提前致谢!

假设我有大量的异构JSON文档(即命名的键值映射)和这些文档附加到的类的层次结构(即命名集).我需要设置一个允许以下内容的数据结构:

1. JSON文档上的CRUD操作.
2. 很快就能通过ID检索JSON文档.
3. 检索所有附加到某个类的JSON文档非常快.
4. 编辑类层次结构:添加/删除类,重新排列它们.

我最初提出了将JSON文档存储在面向文档的数据库(如CouchDB或MongoDB)中并将类层次结构存储在RDF存储(如4store)中的想法.1,2并4随后想通了自然,并3通过保持附加文档ID列表中存储的每个类解决.

但后来我认为RDF存储实际上可以通过ID检索JSON文档的文档导向部分.乍一看这似乎是真的,但我仍然关心2和3.是否有一个RDF存储能够以速度面向文档的db的服务文档检索文档(节点)？它的服务速度有多快3？我听说过RDF存储缓慢,具体化问题等等.

是否有一个RDF存储也可以像ID那样随意检索对象,例如CouchDB？使用面向文档和RDF存储来存储,检索和编辑类似JSON的对象有什么区别？

使用文档oriënted数据库mongodb和Object Document Mapper(ODM)morphia

可以说我们有3个不同的类; Object,Category和Action.
这些对象都存储在集合中; 对象,类别和动作.

Category并且Action是参考Object

@Entity("objects")
public class Object {

    @Id
    @Property("id")
    private ObjectId id;

    @Reference
    private Category category;
    private Action action;
    ...
}

@Entity("categories")
public class Category {

    @Id
    public String categoryTLA;
    public String categoryName;
    ...
}

@Entity("actions")
public class Action implements BaseEntity {

    @Id
    public String action;
    public int accesLevel;
    ...
}

具有当前实现的文档存储如下:

• Mongo (服务器/位置)
  • 商店(数据库)
    • 对象(集合)
      • 对象(文件)
      • 宾语
      • 宾语
    • 类别
      • categorie
      • categorie …