RavenDB文档建模--琐碎的注意事项--缓存查询属性

缓存查询属性是我们在实际开发中会遇到的，什么是缓存查询属性呢？举个例子来说，在电子商城的订单系统中每个账户都有自己的订单数据，有时用户需要查看自己截止到目前所订单的数量，那么这个账户的订单数量可以被视为 查询属性，因为从众多的订单中统计出某个账户的订单数量是一件会消耗很多资源的命令，因此会将这个订单数量存储在缓存中（例如存储在RavenDB中），在后续查询中我们不需要再次从数据库中查询，只需要在缓存冲查询即可，这就叫做 缓存查询属性。 缓存查询属性的行为开起来很常见也很有意义，但是着是一个不良的行为。为什么这么说呢？首先在大部分领域中这种类似的属性并不是客户必须有的部分（可有可无），也不是客户文档必须包含的部分，其次，为了保证这个属性会在相关内容变更（例如订单删除和新增）时也跟着更改，我们就需要在相关内容发生变化时也去改变它的内容，等于说我们要对数据库多进行N次的操作，然后将更新的数据在存入缓存中，这样就会增大失败的概率，接着，我在进行开发设计前还需要考虑哪些操作会改变查询属性，如果是比较简单的项目还好，那如果是大型项目呢？里面的操作错综复杂，如何保证覆盖所有的操作？ 缓存查询属性这个问题其实是一个业务和成本方面的问题，在大多数情况下我们只是想在页面中展示这个值，并且要从关系型数据库中查询出这个值的话可能会很昂贵，因此很多人会将这个值直接放在缓存中。在 RavenDB 中我们可以使用 MapReduce 聚合操作来处理，我们根本就不需要缓存这种属性，也减少了成本，MapReduce的使用因为是一个很大的模块，因此我将放在后面专门开始一个专题来讲解。在解决完缓存查询属性的问题后，下一步我们该考虑如何处理并发的问题和并发问题对建模的影响，这个问题我将放在下一篇文章讲解。