问题描述
EF链接的SQLSERVER循环用户列表,对每个用户添加一条新消息到消息数据表这样实现是否正确,是否有更好的实现方式,或者如何提高EF的效率
解决方案
解决方案二：
真正的消息push，跟数据库无关。数据库只是后备记录统计工具，例如当进程重启时也许可以查询得知发了多少消息、哪些推送成功了、哪些还没有推送成功。但是推送技术本身，跟数据库无关。如果你纠结于EF，一方面你绕到了无关的概念上去消磨时光然后将来才绕回真正的push通讯技术，另一方面也让稍微大一点的系统的push操作慢了至少20倍。
解决方案三：
对于初学者，满脑子只有“增删改查”的时候，作为一种“娃娃式的”小玩意儿，你可以以“一方写记录到数据库，然后另一方轮询查询数据库并且删除数据”的方式来假装去模拟这种通讯。然后你要记住，1、2年以后，你要学真正的通讯技术那几行代码，而不要绕道数据库去浪费系统时间。
解决方案四：
引用1楼sp1234的回复:
真正的消息push，跟数据库无关。数据库只是后备记录统计工具，例如当进程重启时也许可以查询得知发了多少消息、哪些推送成功了、哪些还没有推送成功。但是推送技术本身，跟数据库无关。如果你纠结于EF，一方面你绕到了无关的概念上去消磨时光然后将来才绕回真正的push通讯技术，另一方面也让稍微大一点的系统的push操作慢了至少20倍。
推送消息到用户手机用的是极光推送,没啥问题.关键是点击这个消息后进入到app的消息中心,这个时候必须要有一条数据吧?不然已读未读状态也无从修改.
解决方案五：
对于所有用户都有效的消息，一般做法不是专门弄一张表，然后查询时用户来笛卡尔关联查询，但阅读记录表是单独每个用户的也就是说，通知消息只有一条，但推送记录会有N条
解决方案六：
引用4楼starfd的回复:
对于所有用户都有效的消息，一般做法不是专门弄一张表，然后查询时用户来笛卡尔关联查询，但阅读记录表是单独每个用户的也就是说，通知消息只有一条，但推送记录会有N条
如果不考虑已读未读这样是很好的,之前也是这么做的,但是如何标记一个用户已读呢?还是需要一个用户一条记录呀
解决方案七：
消息本体可以用单独的表存放，每条消息存放一条即可，另外根据你的功能可以建立消息读取记录表和消息删除记录表等，当用户读取或删除消息时，插入相映的关联字段即可。
解决方案八：
引用6楼BitCoffee的回复:
消息本体可以用单独的表存放，每条消息存放一条即可，另外根据你的功能可以建立消息读取记录表和消息删除记录表等，当用户读取或删除消息时，插入相映的关联字段即可。
恩,目前的设计差不多就是这样的,但是数据库中的记录条数依然是每个用户一条(假设全部已读)