永久表、临时表还是 php 会话？
我的网络应用程序提供个性化推荐。当用户开始使用它时，大约 1000 多行被插入到一个大的推荐表中，与数据库中的其他表相关联。用户投票的每个项目都会影响所有这 1000 多行。
由于推荐信息仅在会话期间有用，并且由于推荐表变得巨大，因此我们希望切换到更合适的方法。用户会话结束后就可以删除相关行。我想 PHP 会话数组或临时表更适合这种情况？
My web app offers personalized recommendations. When a user starting to use it, about 1000+ rows are being inserted to one big recommendation table, correlating with other tables in the database. Every item the user votes for affects all of those 1000+ rows.
Since the recommendation info is only useful during the session, and since the recommendation table is getting huge, we'd like to switch to a more appropiate method. There's the possibility of deleting the relevant rows as soon as the user session is over. I guess PHP session array or temp tables are better for this case?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
每个会话一个临时表会导致目录污染，因此不建议使用。
您是否考虑过实际保留数据，以便定期挖掘数据来改进建议？
One temp table per session will lead to catalog pollution, so not really recommended.
Have you considered actually keeping the data, so as periodically mine it to improve the suggestions?
第一：考虑重新设计你的数据结构，我认为这不是最优的。
将用户的推荐存储在表 user-recommenditem-score 中：我认为不需要临时表或其他任何内容。
否则，您可以开始使用会话，但您应该仔细封装代码，以便在该解决方案不再可维护时轻松更改。
First: consider redesigning your data structure, I think it is not optimal.
Store a user's recommendation in a table user-recommendeditem-score: I don't see any need for a temp table or anything else.
Otherwise, you could start using sessions, but you should encapsulate the code carefully, making it easy to change if/when this solution is no more maintainable.
我怀疑这个方法有缺陷——每个用户有 1000 多个推荐？他们看过其中有多少？如果您不知道该问题的答案 - 那么您需要花一些时间思考为什么您不知道答案。
您确定您的数据已正确标准化吗？
但暂时先把它放在一边。生成/存储的正确位置是在数据库中 - 关系数据库是明确设计的，并且在生成和维护表格数据集方面比传统编程语言更有效。
I suspect that the method is flawed - 1000+ recommendations per user? How many of them do they ever look at? If you don't know the answer to that question - then you need to spend some time thinking about why you don't know the answer.
Are you sure your data is properly normalised?
But leaving that aside for the moment. The right place to generate / store that is in the database - a relational database is explicitly designed, and a lot more efficient about generating and maintaining tabular sets of data then a conventional programming language.