这应该如何设计？

Question

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

1. 明确选择作者，然后跟踪他
或者
2. 选择一个通道（作者列表中，其他一些用户轨迹），并跟踪整个通道
下面是DB的架构看起来像（在关于这个具体的使用情况下，只有）

DB Model http://img526.imageshack.us/img526/7278/dbmodel.png
这样的设计应该是OK在用户点击作者追踪作者的情况下，插入快速进入数据库，UI动画（使用Ajax通过Jquery）指示过程的成功或失败。但是，如果用户选择一个频道，情况将会不同。以下是我想到的，当用户选择一个频道时，我将所有作者从此频道中提取出来，然后在Users_Authors表中插入新条目。现在想象一下，频道包含1000个或更多的用户，插入需要一些时间，动画GUI将不会像预期的那样快。所以，有没有人推荐任何其他方式来改善这一点（即使我必须改变整个设计）。
谢谢

Answer 1

有一件事情是这样的：

如果用户选择100位作者和渠道变革的通道，应这些变化流经给用户？这个问题的答案很大程度上决定了设计。

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

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

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

Answer 2

我会建议一个不同的表示法。

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

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

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

除此设计之外，当频道中的作者构成发生变化时，数据维护问题将会消失。

Answer 3

您可以将频道视为元作者，即订阅频道的操作与订阅作者非常相似。这给你两个好处：1.当新作者加入一个频道时，该频道的所有用户自动订阅该作者。 2.也许用户订阅了艾萨克牛顿。她然后也赞同频道“物理学家”，但后来退订了。从用户那里删除“物理学家”的订阅也会删除艾萨克牛顿，这可能是不希望的。你需要问自己

Answer 4

我的方法是将人员表与用户和作者以及作者表都只有作者的人员键。然后，作者会创建一个类似于您的链接表的会员表。