想要实现一个类似这样的通知系统。
现在有三个模型，一个是user，一个是article，一个是event。
user关注article之后，关于article的event就会有通知发送给所有关注它的user。
现在想到三种方案：
一个是article下做一个event的数组，user则有他关注的article的数组，每次读取通知的时候就查找所有关注的article，找出上次拉取通知之后发生的event。但是这样就要纪录上次拉取event的时间，并且比较event的时间，感觉读取性能有影响，但似乎也没有更好的解决方案了，不知道这是不是常用的方案。
还有一种方案和第一个方案差不多，但是是SQL数据库的样子，就是单独建一个event的表，保存event相关的article的id，然后读取通知的时候就搜索发生在上次读取通知事件之后的，并且article的id也在user关注列表中的事件。从心理上来说我不太喜欢这个方案，因为感觉这不是NoSQL的风格
另一个方案就比较无厘头了，article保存一个关注它的user的列表，user保存一个event的列表，每次关于一个article的event发生之后，就对所有在article关注列表里的user写入一个event的id，这样user每次拉取通知的话直接populate他的event列表即可。很显然关注数多了之后写入性能会很差，但是感觉整体逻辑非常清晰
大家给个建议，说说这个一个系统怎么实现比较好
如果我没理解错的话，我会会这样做：三个模型 user, article, notification
每一篇article里面都包含了一个数组：subscripters[],任何用户关注了当前的article就会把改用户的id加入到这个subscripters里面。
每一篇article在改动之后系统都会触发notification模型，该模型会读取当前article里面的全部subscripters任何创建推送数据。然后存储到notification数据库里面并伴随一个status:"pending"。
任何用户点击了被推送的信息，该条目在notification都会被改成status:"open". 如果用户修改已读推送成为未读推送，还在改条目内改回status:"pending"
这样，任何人都可以关注任何文章一次，任何文章在变动之后都会被推送一次，任何用户都可以随时改变推送属性儿不用改变user跟article里面的任何数据。
一点儿拙见，仅供参考。
我的天，居然设计表还要考虑No不NoSQL……
我简单的说，User和Article的通知属性就不一样，在关系型数据库里好的设计是不同的通知存在不同的表里。而在MongoDB里，你完全可以实现一张表存储所有的通知，这还不够NoSQL吗？
表的设计是为需求服务的，不是为了感觉而设计的。
况且谁说NoSQL要和SQL划清界限，就不能你中有我，我中有你吗？