在 RavenDB 中对如何在应用程序中进行数据建模没有任何要求,我们可以使用任何形式进行建模,RavenDB 只关心如何构建数据,这就是我们后续几篇文章要讲解的内容。...嵌入文档 文档模型和实体关系模型是不一样的,一般来说在实体关系模型中每个实体都有一个对应的表,但是在文档模型中则不是这样,我们一般会像下面代码这样将所有紧密相关的信息存储在一个地方。...在这种情况下,仅为订单标头创建文档大概率是有意义的,但是如果使用投影也是可以的(这些内容将在后面的文章讲解),这样就省去了拆分数据的需要,在 RavenDB 中构建一对一关系的典型方法是利用文档 ID...另一种情况是,如果需要对文档进行并发活动,由于文档是 RavenDB 中的并发单位,因此需要对文档进行建模,以便它们具有更改的单一原因。...一种方法是始终使用修补(后续文章讲解)来更新文档,但是处理这种要求的更好方法是创建一个专用文档,该文档将保存有关跟踪此订单的用户的所有详细信息。
那么在这篇文章中我将带领大家来具体的学习 如何在 RavenDB Studio 中实现增删改查。...这将打开编辑器,其中包含了基于 Categories 表格式的空文档,我们在空文档中填写完一些属性值后,点击 Save 按钮即可保存数据,数据保存成功后 RavenDB 会为新文档分配一个 ID。...虽然说 RavenDB Studio 在增加一个新文档时,会基于现有文档来生成,但是因为在 RavenDB 中没有类似于 schema 的东西,所以我们可以随意增加和删除属性来修改文档结构,这个功能使数据模型在演变和处理复杂数据的时候更加容易...二、更新 如果我们需要修改某个表的结构的时候,我们可以进行批量修改,批量修改后,表中所有数据的结构都随之改变。...三、删除 如果要删除 RavenDB 中指定的文档,只选择该文档并点击 Delete 按钮即可。
在 RavenDB 中,使用文档或附件 ID对文档或附件的所有操作(增、删、改)始终是一致的,并且它们是在事务中运行的。对文档集的批量操作则是由由多个单独的事务组成,而不是由一个庞大的事务去执行。...默认情况下,当我们将文档保存到 RavenDB 中并且数据以持久的方式保存在一个节点上时,就确认文档已经保存成功。当然,为了提高数据的安全性,还可以要求文档在多个节点上持久时才确认文档已经保存。...之所以权衡需要多少索引,是因为事务必须在文档每次更改时更新所有相关索引。这也就说明索引的更新就位于更新数据的主要途径中,这就解释了为什么错误的索引能严重地降低性能。...RavenDB 中的索引的更新在某种程度上可能会落后于它们所反映的文档,但是一般来说文档更新和索引更新之间的时间差通常以微秒为单位进行度量。...当然,如果你需要在操作完文档后让 RavenDB 等待索引更新完成也是可以的,但是在实际开发中这个功能并不是优先选择的。
在本专题中我们首先将 RavenDB 视为一个简单的键/值存储。只需将数据存储进去并通过键访问数据即可。同时我们还学习了使用过期功能来存储与时间相关的数据。...从键/值存储的简单模型开始,我们开始考虑真实的文档模型,学习了如何构建嵌入值来存储本质上是文档一部分的数据,还研学习了如何对关系和集合、多对一和多对多关联进行建模。...然后,我们介绍了更高级的建模技术,例如如何处理引用和配置数据,以及如何处理时态信息和分层结构。 接下来,我们讨论了建模时必须考虑的一些约束,例如如何处理文档的增长以及RavenDB中文档的良好大小。...然后我们学习了如何处理带有附件的二进制数据,以及使用修订功能进行审计和更改跟踪,并且了解了我们可以在 RavenDB 中如何让文档数据过期。简要介绍了索引和查询时的引用处理。...我们介绍的最后一个主题是 ACID模式 VS BASE模式。在RavenDB中文档以某种方式存储和访问,而我们默认使用查询以获得更高的性能并有更多的优化机会。
如键值存储鼻祖BigTable以及文档数据库CouchDB。...而相关的云存储解决方案提供了在传统关系数据库之外的选择,包括Windows Azure Table(键值类型)以及基于Hadoop的Amazon EC2。...随着大量不同类型数据持续增长,未来非结构化数据存储将成为关键技术。 RavenDB是针对Windows/.NET平台而设计的文档数据库。RavenDB的出现将.NET应用与非关系数据库连接到一起。...数据以Shcema-less方式存储,并直接通过HTTP、RESTful API或更方便的.NET客户端API连接。.NET客户端API使用LINQ操作RavenDB数据库文档存储。...(李智/编译) 原文链接:techrepublic.com 将 RavenDB 嵌入 ASP.NET MVC 3 应用程序中 RavenDB在传统C/S应用下的一点实践 RavenDB 2.5带来动态聚合和查询流
我们在开始讲解如何在 RavenDB 中建模之前,先来看看注意事项,这些内容与我们将要辨析的模型有着直接的关系。 这里需要注意的第一点是 不要在不同应用之间建立共享数据库。...很多设计者会建立共享数据库,用以在不同的应用之间共享相同的数据,虽然这样做能减少数据存储量,以及实现多应用使用相同数据的目的,但是在 RavenDB 中并不推崇这样的做法。...另一个要注意的是 某些情况下应该数据冗余存储,比如在 Order 文档中存在 Address 文档的链接,但是如果 Address 中的配送地址变了,那么 Order 文档中的历史订单的配送地址也会跟着改变...,例如在 Order 文档中存储配送地址的详细信息。...以上几小段的内容总结下来就是建模文档的核心原则: 独立,一个文档应该独立于其他任何文档而存在,如果某个文档脱离了其他文档而不具备存在的条件,那么这个文档就不是独立的,例如 Order 文档中存在 Address
RavenDB 非常适合键/值存储,为了确保快速存取数据库,RavenDB 在设计的时候降低了存储和加载文档的成本,这是 RavenDB 和其他数据库相比最大的有点。...在默认情况下,RavenDB 不会对存储以及加载文档增加额的外成本,因此可以使用所有访问模型中最简单的快速数据库。一般来说键/值建模的复杂性在于生成适当的键以及可以对其执行哪些操作。...在使用 RavenDB 作为键/值存储的情况下,下面所列的内容是很有用的: 可以独立于使用的集合生成文档标识符; 通过提供要加载的 ID,可以在单个调用中完成加载文档; RavenDB 为文档提供自动过期功能...如果在 RavenDB 中存储购物车数据,也可以从其中提取数据。可以查看正在购买的最受欢迎的商品,或者对库存进行预测,或者提供有用商品销量预测等功能。...在典型的键/值存储中(比如 Redis ),必须手动跟踪这类事情。但在,RavenDB 中允许我们非常轻松地查询和聚合数据。
RavenDB 是一个 JSON数据库,但并非所有数据都可以使用JSON来存储,例如订单中的发票PDF、QQ/微信头像等,对于这种类型的数据它既是文档的一部分又是和文档分开的,因此 RavenDB 会将这类数据作为附件存储...附件是可以附加到文档的二进制数据,附件始终位于文档中,除了存储二进制数据外,还会存储一个附件名称。虽然附件和文档分别位于不同的卫视,但是都保存在同一个存储中,并且附件和文档可以一起处理。...这也就是说附件可以和具有相同语义的文档一起参与相同的事务 TIP:附件没有大小限制,并且一个文档可以有多个附件 二进制数据则是 RavenDB 为我们提供的一个非常用的功能,也是我们建模非常重要的一项...在建模时考虑哪些外部数据与文档密切相关,应作为附件存储。这样做的最简单的心理模型是考虑电子邮件中的附件,假设文档是电子邮件内容,附件就像电子邮件中的附件一样。...通常,此类附件会提供有关相关主题的附加信息,这是 RavenDB 中附件的一个很好的用例。
在 RavenDB 对文档的大小限制是有硬性规定的,不超过2GB,不要觉得着2GB不够用,RavenDB会对 JSON 文档进行压缩处理,因此如果你存储的数据大小在 2GB的话,经过 RavenDB 压缩后所占的空间会非常非常的小...虽然说 RavenDB 对存储大型文档来说有着天生的优势,但是我们也要考虑一下成本问题,首先我们通过网络读取文档时可能出现传输速度很慢的情况(文档很大),即使我们读取到了文档,因为 RavenDB 的文档都是经过压缩的...以下是开发人员在实际开发中总价的方法:只要以千字节为单位衡量文档大小是有意义的,就可以了。RavenDB 在遇到过大的文档时会在 Studio 中生成警告,但对系统的行为和性能没有任何影响。...对于这种情况我们要考虑这些大量的数据是否必须存储在文档中,是否可以独立成一个外部文档,我们可以使用 RavenDB 提供的附件功能,将这些超大的数据/文件作为附件附加到文档中。...例如在订单系统中,不可能在页面上展示所有的订单,我们会根据年或月来拆分订单(比如某东的订单页面),这样我们就得到了如下文档: 文档 说明 order/zhangsan 用户zhangsan全部订单简略信息
我们可以在文档中存储任何数据内容,比如在订单文档中我们会存储订单状态、订单物品数量、订单金额等等内容。...Metadata 默认存储什么 Metadata 的存储格式和文档本身一样也是 Json,RavenDB 使用 Metadata 存储有关跟踪文档的几个重要信息: 集合名称,存储在 @collection...中,通过这个属性何以确定数据文档存储在哪个集合中,如果该值未设置,数据文档将存储在 @empty 集合中; 文档最后修改日期,存储在 @last-modified 属性中,存储格式时 UTC; 客户端类型...Python客户端 自定义 Metadata 属性命名规范 除了使用 RavenDB 内置的 Metadata 属性外我们还可以自定义 Metadata 属性,比如我们要记录订单文档最后的修改人是谁...TIP:当我们在 RavenDB 文档中看到以 @ 开头的 Metadata 属性时,就说明这个属性是 RavenDB 保留给自己用的,因此我们在扩展 Metadata 属性时不能使用与之一样的属性名,
在 RavenDB 中存储文档时,我们可以指定文档的过期时间,RavenDB 会定期删除所有过期的文档。这个功能虽然很小,但是我们可以利用这个可以实现类似“30分钟有效的验证码”的功能。...这里需要主义的是如果你指定了过期时间,则在该时间过后,文档可能依然存在,这是因为 RavenDB 还没有开始清理过期的文档,默认情况下,RavenDB 将每分钟清除过期的文档。...因此,文档的生存时间可能比预期的要长一些,但并不是很严重。 TIP:我将在后续的专题中具体讲解这个功能。
"ToDoTasks/1-A", "ToDoTasks/2-A", "ToDoTasks/3-A" ); 在上面的代码中,将生成一个包含所有三个文档的字典,这三个文档是通过一次查询检索出来的...如果在 RavenDB 中没有找到指定的文档,那么字典中文档的 ID 值为 null。...Include() 在项目中我们大部分情况是在处理具有关联关系的文档,那么在 RavenDB 中我们该怎么处理呢?那么,着这一小节里我们来看看如何处理多文档。...我前面的文章中也提到过 SaveChanges 方法会把前面所有的新增、修改、删除的内容一次性全部提交的 RavenDB 中,因此我们可以把第一个 SaveChanges 方法删掉。...那么,现在我们知道了该如何保存多个文档了,下面我们就来看看如何将相关连的文档查询出来。 在 RavenDB 中其实是没有咱们常说的外键关系的,对另一个文档的引用只是一个字符串的属性。
一、安装 目前 RavenDB 的安装分为两种,一种是在 Docker 中安装,另一种是在桌面安装,其中桌面安装又分为 Windows 和 Linux 安装,我们分别来看一下。...1.1 在 Docker 中安装 RavenDB最简单的安装方式就是在 Docker 中安装,使用如下命令 Docker 将获取最 RavenDB 的最新版本,并启动新容器来托管它。...二、First DB 已经有了 RavenDB ,现在我们还需要创建数据库,这样才能进行数据的CURD操作。在本篇剩余内容中我将带领大家创建一个实例数据库。...2.3 查看数据 单击在 Documents 菜单下的 Orders ,会展示 Order 表中所有的内容,我们任意点击一个订单,可以看到数据是以 JSON 的形式存储的。...在 RavenDB 里,我们可以将任意复杂的数据存储为一个单元。这就表明我们不需要拆分对象,整个对象就可以存储在单个文档中,这就是 RavenDB 中的基本建模方法基于根的聚合。
我们存在数据库里的数据会随着时间的变化而变化,如果要随时追踪数据的变化是一项极具挑战的任务,但是RavenDB 为我们提供了修订功能来解决这一问题。...DBA 可以配置 RavenDB 用来追踪文档的修订,每次文档修改时都会创建一个不可变的修订版本,这样我们就可以通过使用这些修订版本来追踪文档发生的所有变化。...但是在实际开发中我们一般不会要求追踪所有文档的变化,这时我们就可以指定 RavenDB 仅跟踪特定的集合,甚至可以跟踪最近的几个修订版本。...当然修订也可以用于删除,所以我们可以根据修订版本来回复被删除的文档。 TIP:我们可以在每个文档级别上拥有所有更改的副本。 修订虽然告诉我们发生了什么变化,但审计会告诉我们谁干了什么。...RavenDB 支持使用客户端侦听器进行审计,无论文档发生什么更改,都可以为文档提供额外的上下文。 本节内容我将在后续专题详细讲解,这里知识一个入门。
在关系型数据库中表一般情况下都会存在主键,这个主键在所在表中是唯一的不可重复的,同样在 RavenDB 中也存在这样的主键,它被成为文档标识符或文档ID。...二、嵌套文档 ID 嵌套文档 ID 是语义文档 ID 的一个特例,比如在一个大型电商系统中,每个 User 都有可能存在多个订单,那么如果我们将每个 User 的所有订单都放在 User 文档中显然是不合理的...在 RavenDB 中我们可以使用hilo,在我们第一次需要生成 ID 时,向服务器请求保留文档 ID 范围,这时服务器将会确保所提供的范围只对一个客户端使用,然后我们的客户端就可以在给定的范围内安全的生成文档...比如我们要在 RavenDB Studio中创建一个订单数据,这时我们在 ID 中输入 order/ 然后单击 Save , RavenDB 就会为我们自动生成一个类似于下图的文档 ID。...六、总结 我们已经讨论了很多生成文档标识符的选项,每个选项都有自己的行为和成本,各种方法之间也存在性能差异。 RavenDB 通过将文档 ID 存储在 B+Tree 中来跟踪它们。
我们可以将所有的省市列表以 K/V 的形式放入一个文档中,如下代码: { "BJ":"北京", "HN":"河南", "HAN":"海南", "HUN":"湖南",..."SH":"上海" } 上面这种对 Reference data 建模的方式有如下几个有点: 数据易于处理,可以一次性将所有内容加载出来,减少 RavenDB 的处理次数; 融入了 RavenDB...TIP:Reference data 会使一个单一的文档,因此我们可以使用 RavenDB 做更多的任务,这些将在后续内容中讲解。...我们来看一下常见的层次结构的类型: 简单层次结构:这种结构可以轻而易举的放在单个文档中,比如一篇文章所对应的评论,这些评论我们可以放在这篇文章的文档中,便利一篇文章评论的开销是非常小的; 分离层次结构:...在 RavenDB 中对时态数据进行建模的方法是 完全接受其文档性质 ,因为在大多数时态域中,文档和视图随时间变化的概念非常重要。
、字典以及树等这种复杂类型的数据结构。...关系型数据库有一套标准化的内容(比如说数据完整性),标准化有助于减少数据重复,常见的情况是在线商城中的订单模块,配送地址的 ID 作为外键存储在订单表中,这样使得我们不用在多个订单中修改配送地址。...在 RavenDB 这种非关系型文档数据库中并不能完全解决这个问题,但是对于大多数业务系统来说 RavenDB 存储数据的模型还是比较合适的。...在 RavenDB 中每个文档都是一个聚合,它是面向文档的建模技术,为解决类似于订单和地址这种问题提供了很好的解决方案。 Q:什么是聚合?...A:聚合可以被看做单个单元的域对象集群,订单和订单的内容就是聚合。 在这个专题中,我们将学习如何拜托关系型思维模式以及如何为 RavenDB 建模。
我们修改或者删除文档后,同样也需要调用SaveChanges 方法来更新 RavenDB,而且利用 Query 查询出来的文档在会话中也只有一个实例,不管你查询了多少次。...我们将在第三部分中详细说明原因并介绍有关索引的详细信息,但现在您可以看到大多数查询都适合您。 Store() Store 方法是会将实体与会话关联在一起。只有在我们要创建一个新文档的时候才会这么去做。...RavenDB 中,并且对于新增来说,RavenDB 会为新实体提供一个 ID。...那么就可以调用 Store 方法来将实体和会话绑定在一起,并且它的 ID 不是空的,RavenDB 认为它以存在于库中,因此将会以更新的形式存入库中。...SaveChanges() SaveChanges 方法的作用是检查所有删除和更改的会话状态,然后将这些作为一个事务发送到服务器,因此这就保证了不会因为中途产生异常而部分保存失败。
Document Store Document Store 是客户端 API 的主要入口点,它包括了包含所有客户端配置,包括序列化配置、故障转移行为、缓存选项等内容。...约定 RavenDB 默认已经做了一些列的约定,这些约定既包含怎么保存内容,也包含如何序列化实体成文文档。...比如说 RavenDB 默认使用 Id 作为文档内容的 ID ,但是我们并不希望这么做,我们希望使用实体名称加Id的形式来产生ID,那么我们可以这样定义: documentStore.Conventions.FindIdentityProperty...一般来说我们的开发环境是如果用在线上的话是不安全,我们需要以安全的模式在线上环境中运行 RavenDB ,这时我们可以使用 RavenDB 支持的 x509 客户端证书来进行身份验证。...如果在禁用身份验证的情况下配置非本地 URL,那么 RavenDB 会显示错误页面,解释情况并提供有关如何解决问题的说明。
我们在 VS 中创建一个名为 Rvn 的控制台应用程序。项目新建成功后,我们需要在项目中安装 RavenDB 的包。在 NuGet b包管理其中查找 RavenDB.Client 包并安装它。...,代码操作 RavenDB 的流程其实和操作关系型数据库的流程一样: 打开会话; 创建新的 ToDoTask 实体对象; 将实体对象传入会话中; 执行保存操作; 释放会话。...然后将任务存储在会话中并调用 SaveChanges 方法将会话中的所有更改保存到 RavenDB 中。...CURD 就去执行一次 SaveChange 方法,大部分情况我们会将同一个会话中的所有操作执行完后采取执行 SaveChange 方法,在这里我们不需要担心如果在中途出先异常,数据只保存了部分的问题,...因为 RavenDB 的文档会话实现了 Unit of Work 和 Identity Map 设计模式,因此对于任意复杂程度的内容我们不需要手动跟踪对象的更改以及决定要保存对象的哪些内容,这样就减少了网络请求
领取专属 10元无门槛券
手把手带您无忧上云