具有大数据集权限读取时的 CQRS
我试图了解 CQRS 的读取端如何与我们正在编写的大型文档管理应用程序(视频/pdf 文件/等)配合使用。
我们想要显示用户具有编辑权限的所有文档的列表(即显示用户可以编辑的所有文档)。特定用户可以编辑的文档可能有 10,000 个。
一般来说,我读到单个“表”(平面结构)应该足以满足大多数屏幕的需要,并且通过权限,您可以为每个角色拥有一个表。
我将如何设计我的阅读模型,以允许我快速获取可以为特定用户编辑的文档?
目前,我可以看到一个表保存我的文档,另一个表保存用户,另一个表链接用户和文档之间的“编辑”角色。所以我正在做连接来获取该屏幕的数据。
另外,可能还有删除、查看等角色。
在这种情况下,这是正确的方法吗?
京东
I am trying to understand how the read side of CQRS can work with a large document management application (videos/pdf files/ etc) that we are writing.
We want to show a list of all documents which the user has edit permission on (i.e. show all the documents the user can edit).There could be 10,000s of documents that a particular user could edit.
In general I have read that the a single "table" (flat structure) should suffice for most screens and with permissions you could have a table per role.
How would I design my read model to allow me to quickly get the documents that I can edit for a specific user?
Currently I can see a table holding holding my documents, another holding the users and another table that links the "editing" role between the user and the documents. So I am doing joins to get the data for this screen.
Also, there could be roles for deleting, viewing etc.
Is this the correct way in this case?
JD
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
您可以提供一个平面表,其中包含用户 ID 以及相应的非规范化文档信息。
但是您甚至可以在读取模型存储中为每个用户动态创建一个表/列表。一旦您从基于 SQL 的读取存储切换到 NoSQL(如果还没有的话),这将变得非常容易。
特别是当用户可见或可编辑数以万计的文档时,扁平表可以带来真正的性能提升与连接相比。
You can provide a flat table that has a user id along with the respective denormalized document information.
But you could even dynamically create a table/list per user in your read model store. This becomes quite easy once you switch from a SQL-based read store to NoSQL (if you haven't already.)
Especially when there are tens of thousands of documents visible for or editable by a user, flattened tables can give a real performance boost compared to joins.
当我有一个采用过滤搜索表单(双关语不是双关语)形式的读取模型时,我使用 rhino-security 作为授权服务的基础。
我配置了系统,以便授权服务的表通过 SQL Server 的发布-订阅系统和 SQL Server 代理推送到部分显示非规范化数据的客户端 - 然后我让 Rhino.Security 将授权模型以每个用户为基础加入到读取模型中。
因为我基本上从未从读取模型写入读取模型的授权表,所以我们对授权服务的数据库和逻辑进行了很好的封装,因为授权仅通过该服务进行更改,并且它是全局唯一的并且特定于该服务(一致)。这意味着我们用于处理高级(分层实体、用户组、用户、权限、每个实体权限)授权要求的自定义 GUI 仍然可以针对此授权模型执行 CRUD,并将软实时推送到任何读取模型。
When I had a read model that took the form of a filtering-search-form (pun not intended), I used rhino-security as the foundation of an authorization service.
I configured the system so that the authorization service's tables got pushed through SQL Server's pub-sub system and SQL Server Agent, to the clients that were partially displaying the denormalized data - I then let Rhino.Security join the authorization model together into the read model, on a per-user basis.
Because I essentially never wrote to the read model's authorization tables from the read model, we got a nice encapsulation on the authorization service's database and logic, because authorization was only changed through that service, and it was globally unique and specific (consistent) to that service. This meant that our custom GUIs for handling advanced (hierarchial entities, user groups, users, permissions, per-entity-permissions) authorization requirements could still do CRUD against this authorization model and that would be pushed in soft real time to any read model.