高效的评级体系
我正在为这个拥有大量用户的网站构建一个新闻评级脚本。我正在努力使该网站尽可能高效，现在我想知道跟踪投票的最有效方法是什么。当然，我不希望用户投票多次。
我的第一个想法是将它存储在我的 MySQL 数据库中，但我担心这会对我的网站速度产生负面影响，因为这个表会变得相当大。
将其存储在数据库中仍然是最好的解决方案还是有更好的解决方案。
I'm building a news rating script for this website that has a lot of users. I'm trying to make this websites as efficient as possible and now I'm wondering what would be the most efficient way to keep track of the votes. Of course I don't want users to vote more than once.
My first though was to store it in a my MySQL database, but I'm worried this would have a negative influence in my website's speed because this table would get quite big.
Would storing it in a database still be the best solution or are there any better solutions.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
如果您打算拥有 > 1,000,000 条记录，您应该确保表的结构有效（这对于您的示例来说应该不难）并且正确索引它。
Memcached 将是实现缓存的最简单方法，并且如果您的站点增长且需要更多服务器，则很容易扩展。
If you plan on having > 1,000,000 records you should make sure the table's structure is efficient (which shouldnt be hard for your example) and that you index it correctly.
Memcached would be the simplest way to implement caching and is easy to scale if your site grows and more servers are necessary.
有了正确索引的投票表，无论表有多大，您都可以保持合理的性能（当然，超过某个点，您的表将太大而无法放入缓存，但这将涉及拥有大量用户和物品）。
添加一些每用户缓存（在客户端上，在 $_SESSION 中，使用 memcached），您可以获得相当快的“无”响应时间）。
With a properly indexed vote table, you can keep reasonable performance regardless of how large your table is (of course, beyond a certain point, your tables will be too large to fit in cache, but that would involve having a very large number of users and items).
Add in some per-user caching (on the client, in $_SESSION, using memcached) and you can get a quite fast "no" response time).
既然你不能使用memcached，我会这么说。一个像样的数据库服务器（像样的硬件+像样的数据库实现）应该能够很好地处理这个问题。一个带有文章 ID 物理索引和代表投票的第二个条目的表将轻松处理几亿（是的，我编造了这个词）文章：P
基本原理：
数据库服务器维护统计信息 - 阅读：自我调整 - 并且只有热门项目（索引+行条目）保留在内存中。
寓意：
不要担心这些事情，除非它们成为一个问题——即，如果你的公司有 Facebook 的规模，我会担心。
Since you can't use memcached I would say this. A decent database server ( decent hardware + decent db implementation) should be able to handle this quite well. A single table with a physical index on article-id and a second entry representing the vote will handle a few googillion (yes I made up the word) articles easily :P
Rationale :
Database servers maintain statistics -- read: self-tuning -- and only hot items (index + row-entries) remain in-memory.
Moral:
Don't worry about such things unless they become a problem -- i.e., If your company is the size of facebook I would worry.
Memcached 将是一个非常好的方法。你需要偶尔从 memcached 进行同步（我会使用 mysql 服务器上的 cron 脚本使用拉取模型来执行此操作）。
Memcached would be a very good way to do this. you need to synchronize from memcached once in a while (I would do this using the pull model using a cron script on you mysql server).
你看到这个了吗？
http://destiney.com/php#Destiney_lated_images
此处演示：http://latedsite.com/
Did you see this?
http://destiney.com/php#Destiney_rated_images
Demo here: http://ratedsite.com/