帮助处理垃圾邮件逻辑
我有一个博客，我决定使用 Akismet 和 reCaptcha 进行垃圾邮件过滤，我处理垃圾邮件的方式是
a) 用户应该在发表评论之前通过验证码 b) 现在，即使某些垃圾邮件绕过验证码，我也希望 Akismet 能够处理它。
为了让 akismet 处理垃圾邮件，我想到在数据库中创建两个不同的评论表，一个用于存储 Akismet 未检测到的评论，另一个用于存储 akismet（垃圾邮件）检测到的评论。这个逻辑背后的原因是我认为可能是我不想用垃圾邮件弄乱我的评论表，所以只有我想到将检测到的垃圾邮件消息存储在不同的表中。
现在的问题是，如果我使用这种方法，就会存在表的重复。相反，我可以在表中添加一个额外的列来检查和存储它是否是垃圾邮件。我可以采取任何一种方式。
采用哪一种是明智的。 ？
I have a blog, and i have decided to use Akismet and reCaptcha for spam filtering, the way i am dealing with spam is
a) the user should go through the captcha before posting a comment
b) Now even if some spam bypass captcha then i would like Akismet to handle it.
For akismet to handle the Spam, i thought of creating two different tables in database for comments, One to store the comments which is not detected by Akismet , The other is to store the Comments that is detected by akismet(Spam). the reason behind this logic is i thought may be i don't want to mess my comments table with spam so only i thought of storing the Spam detected messages in different table.
Now the problem is duplication of table will exist if i use this methodology. instead i could add an extra column in the table to check and store wether it is a spam. i could do either way.
which one will be wise to adopt. ?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
reCaptcha 本身就非常强大。
reCaptch 支持人员关于reCAPTCHA 强度的官方解答，正常运行时间和寿命：
为什么在让用户通过 reCaptcha 后还需要 Akismet ？
The reCaptcha is pretty strong itself.
The reCaptch support's official answer about reCAPTCHA strength, uptime, and longevity:
Why do you even need Akismet after letting users through reCaptcha ?
搜索两个表并不是一种有效的方法，而且在代码方面也不是更容易。只需合并表格并定期过滤数据即可。此外，Akismet 已经拥有自己的垃圾邮件数据库。维护您自己的垃圾邮件副本不会增加任何价值。维护这种情况的唯一原因可能是您预见到在某些情况下网络会断开连接，那么这是您必须求助于自己的内部数据库查找的唯一时间。
Searching two tables is not an efficient approach, nor is it any easier code-wise. Just combine the tables and filter the data regularly. Besides, Akismet already has its own spam database. No value is added by maintaining your own copy of spam. Probably the only reason for maintaining such is that you foresee network disconnects on certain occasions, then that's the only time you have to resort to your own internal database lookups.