应如何设计？

Question

我正在开展项目，让用户可以选择一些科学作者和专栏作家并跟踪他们的活动。用户可以通过以下方式跟踪作者活动：

  
1. 明确选择作者然后跟踪他
或   
2. 选择频道（其他用户跟踪的作者列表）并跟踪整个频道
 以下是数据库模式的外观（仅针对此特定用例）

DB Model http://img526.imageshack.us/img526/7278/dbmodel.png
这个设计应该是O.K.如果用户通过作者单击作者进行跟踪，则插入将快速进入数据库，并且UI动画（使用Ajax通过Jquery）指示进程的成功或失败。但是，如果用户选择某个频道，情况会有所不同。这就是我提出的，当用户选择一个频道时，我从该频道中提取所有作者，然后在Users_Authors表中插入新条目。现在假设该通道包含1000个或更多用户，插入应该花费一些时间，并且动画GUI将不会如期望的那么快。那么，有人会推荐任何其他方法来改善这一点（即使我不得不改变整个设计）。
感谢

Answer 1

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

如果用户选择了100位作者的频道并且该频道发生了变化，那么这些变化是否应该流向用户？这个问题的答案将在很大程度上决定设计。

如果您想要自动流通，则在用户选择频道时不要复制作者。设计需要适应频道订阅。

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

如果您不想进行更改，则需要对频道进行版本设置或执行您正在执行的操作：将作者从频道复制到用户的订阅中。

Answer 2

您可以将频道视为元作者，即订阅频道的处理方式与订阅作者非常相似。这给您带来两个好处：1。当新作者加入频道时，该频道的所有用户都会自动订阅该作者。 2.也许用户订阅了艾萨克·牛顿。然后，她还订阅了“物理学家”频道，但后来再次取消订阅。从用户那里删除“物理学家”订阅也会删除Isaac Newton，这可能是不可取的。

Answer 3

我建议使用不同的表示法。

简而言之，您想要管理'订阅'。订阅有两种类型：“个人作者”和“频道”。

因此，您可以分别定义一个名为Subscription的基类和两个子类'Author'和'Channel'。 “频道”行应该能够与作者保持1：N的关系。

然后在前端，所有订阅将在一个恒定的时间内完成。

除了这种设计，当通道中的作者构成发生变化时，数据维护也会出现问题。

Answer 4

我的方法是让People表同时包含用户和作者，而Author表只包含作者的People键。然后作者将会有一个类似于您的链接表的成员表。