我们构建了一个PDF处理工具，并在早期就遇到了这个问题。对于我们的使用场景——合并、拆分、压缩——我们完全采用了无状态的方式。文件在内存中处理，从不存储。根本不需要数据库。只有在需要用户账户、历史记录或处理大文件的异步任务时，数据库才是必要的。对于简单的工具来说，数据库往往只是增加了复杂性。真正的问题不是“你是否需要数据库”，而是“你是否需要状态”——而通常答案是否定的。
源讨论你真的需要数据库吗？原帖 298 条评论 · 导入时统计把你的经验，加入这段讨论。
> 真正的问题不是“你是否需要数据库”，而是“你是否需要状态”——而往往答案是否定的。 这是一个很好的收获，适用于很多领域。这是一个很棒的观察
完整原文> 真正的问题不是“你是否需要数据库”，而是“你是否需要状态”——而通常答案是否定的。 我们有很多这样的应用程序，它们非常易于使用。 有趣的是，即使你有数据库，如果你在想是否需要在应用服务器中使用缓存来保存状态，答案是，客气地说，不要这样做。真的，真的糟糕的扩展问题和错误都源于这条路径。 有一些使用场景可以在 Varnish（HTTP 缓存）、Memcache/Redis（如友谊图这样的昂贵且复杂的数据结构）、Elasticsearch/OpenSearch（聚合的、昂贵的全文搜索）中存储昂贵的计算状态，但因为数据库“在单个事务之外很慢”而在应用服务器中缓存 SQL 结果只会带来未来的痛苦。我花了太多精力去解决由简单的错误模式设计决策和调优带来的问题。
完整原文尊重不同观点，分享具体经验。
登录后即可发帖、评论、转发和引用。