您描述的两种解决方案都有一些限制.
>您指出,在密钥中包含所有者ID并不能解决共享数据的问题.但是,如果添加另一个键/值对,包含与此用户共享的内容的ID(键:userId:shared,value:[id1,id2,id3 …]),则此解决方案可能是可接受的.
>当且仅当您的应用程序需要进行查询以检索有权访问特定内容的用户列表时,您的第二个提议(其中包括被授予对给定内容的访问权限的用户列表)是可以的.如果您需要列出给定用户可以访问的所有内容,此设计将导致您的性能不佳,因为K / V存储将必须扫描所有记录 – 这种类型的数据库引擎通常不允许您创建优化此类请求的索引.
从更一般的角度来看,对于NoSQL数据库,尤其是Key / Value存储,必须根据应用程序的请求来定义模型.它可能会导致您复制一些信息.应用程序负责维护数据的一致性.
例如,如果您需要获取给定用户的所有内容,无论该用户是内容的所有者还是与他共享这些内容,我建议您为该用户创建一个密钥,其中包含内容ID列表正如我已经说过的那样.但是,如果您的应用还需要获取允许访问给定内容的用户列表,则应在此内容的字段中添加其ID.这将导致类似于:
key:contentID,value:{…,[userId1,userID2 …]}
当您删除对用户的给定内容的访问权限时,您的应用程序(而不是数据存储区)必须从内容值中删除userId,并从该用户的内容列表中删除contentId.
此设计可能意味着您的应用程序发出多个请求:例如,一个用于获取允许访问给定内容的用户ID列表,以及一个或多个用于获取这些用户配置文件的用户ID.然而,这不应该是一个问题,因为K / V商店通常具有非常高的性能.