【问题标题】:Building models in NOSQL在 NOSQL 中构建模型
【发布时间】:2014-02-12 06:21:00
【问题描述】:

我们正在尝试 NOSQL 文档数据库 (ravenDB),我们正在问自己一些问题。 这是我们的模型:

public class User
{   
    public Guid Id {get;set}
    public string Name {get;set;}   
}

public class Video
{
    public Guid Id {get;set;}
    public string Nom {get;set;}    
    public DateTime PublishDate {get;set;}
    public User Publisher {get;set;}
    public Uri Adress {get;set;}
}

默认情况下,任何人都无法阅读视频。 您可以添加在一个用户或一组用户处观看视频的权限。 您可以向一个用户或一组用户推荐视频(自动添加观看视频的权限)。

考虑到以下用例,为 NOSQL 文档数据库设计模型的最佳方法是什么:

  • 用户正在发布视频,他可以选择哪些组/用户可以观看视频并将视频推荐给某些用户/组
  • 用户撤回了在某些用户/组中观看视频的权利
  • 获取用户被授权阅读的最后 N 个视频
  • 获取最近推荐给用户的 N 个视频

我们正在考虑以下事项:

  • 为每个模型(VideosReadable、VideosRecommended 和 UsersAllowedToRead、UserRecommended)添加 2 个列表,其中第一个列表包含第二个列表的所有元素
  • 为每个模型添加一个Tuple列表(ListTuple<User, bool>>List<Tuple<Video, bool>>),bool表示是否推荐。
  • 添加文档 UserVideoLink

哪一个是最简单的查询模型?还有其他更好的选择吗?

【问题讨论】:

    标签: nosql domain-driven-design ravendb


    【解决方案1】:

    这一切都归结为数量。总共有多少潜在用户?总共有多少潜在视频?有多少建议和任务?数据多久更改一次?没有一个最佳答案。

    您可能会发现,例如,如果您有很多东西,最好创建单独的文档来建模活动位,例如单独的类和文档来建模 Recommendation 和另一个来建模Assignment.

    再一次,如果一个用户只能访问少数视频,您可能会发现在每个用户中嵌入 VideoIDs 列表或 Video 对象列表更容易,这些对象可能是也可能不是完整的视频文档或只是一个小的非规范化数据。

    您必须进行试验并确定最适合您的方法。

    但是,我不会使用Tuple。他们有点乱。为此,您最好使用自己创建的课程。

    我也会避免使用像 UserVideoLink 这样的名称 - 这不太符合 DDD 的想法。更多地把它想象成你正在建模的东西,比如Recommendation

    其中一些听起来像是关系数据库的思维方式,但它在文档数据库中也占有一席之地。仅仅因为文档可以具有结构并不意味着所有内容都必须放在一个文档中。尝试首先使用 DDD 概念对您的域进行建模。然后,您标识为“聚合根”实体的所有内容及其所有子实体(通常)都属于一个文档。

    【讨论】:

      猜你喜欢
      • 2021-11-28
      • 2018-10-29
      • 2016-10-12
      • 1970-01-01
      • 2010-12-21
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多