这应该如何设计?

你需要问自己的一件事是:

如果用户选择一个拥有100个作者的频道,而该频道发生了更改,那么这些更改是否应传递给用户?这个问题的答案将在很大程度上决定设计。

如果需要自动流通,那么在用户选择通道时不要复制作者。设计需要容纳一个频道订阅。

在OO术语中,用户有零个或多个订阅,这是作者或频道的父类。一个渠道与作者有一对多的关系。实体表示基本相同。您只需要订阅两个实体的父级。

如果您不想通过更改流,您需要对通道进行版本或执行您正在执行的操作:将作者从通道复制到用户的订阅中。

您可以将频道视为元作者,即订阅频道的操作与订阅作者的操作非常类似。这给了你两个好处:1。当新作者加入频道时,该频道的所有用户都会自动订阅该作者。2。可能用户订阅了Isaac Newton。然后她也订阅了“物理学家”频道,但后来又取消了订阅。从用户那里删除“物理学家”订阅也会删除艾萨克牛顿,这可能是不需要的。

我建议换一种说法。

简而言之,您希望管理“订阅”。订阅有两种类型:“个人作者”和“频道”。

因此,您可以分别定义一个名为subscription的基类和两个子类author和channel。“channel”行应该能够与作者保持1:N的关系。

然后在前端,所有订阅都将在固定时间内完成。

此外,当信道中的组成作者发生变化时,该设计还将涉及数据维护问题。

我的方法是让People表同时包含用户和作者,而author表只包含authors的People键。然后,作者将创建一个成员表,该表类似于链接表。