为什么我们不将网站访问者（订阅者）的cookie信息保存在数据库中，而不是在用户的机器上设置一个文件。是的，我知道我可能听起来很傻，原因如下：
为每一个用户维护很小的“块”数据的数据库信息是很困难的。
当数据库服务器关闭时，检索数据可能很困难。
对于每条小信息，都将向 Web 服务器发出连续请求。
我的观点是，如果我们要将用户的数据存储在数据库中而不是客户端计算机上的文件中，我们可以通过不允许其他组织或其他站点（甚至黑客）访问用户的数据来为客户端提供安全性来自 cookie 的信息。
此外，我们可以跟踪用户的活动或行为。（我的意思是，我们实际上不知道用户在做什么（客户端活动），比如数据篡改。）
如果您觉得连续向 Web 服务器发送请求可能很困难，那么这要归功于 Ajax。这为我的立场提供了一些支持：使用 Ajax 向 Web 服务器发送请求变得如此简单。
那么，将用户的敏感信息存储在数据库中而不是在用户的机器上设置一个小文件是不是一个好主意？
具体来说，我不是在谈论会话！
您的方法绝对有效，但有一个基本问题（这可能是最初创建 cookie 的原因）：识别。
如何在不询问用户名/密码的情况下识别用户 A 和用户 B？Cookie 提供了一种简单的方法来进行这种区分。一旦用户被识别，您的积分就完全有效。
通常，敏感信息并不意味着存储在 cookie 中。此类信息最好存储在服务器端（如您所示）。
敏感信息不应该在 cookie 中，我同意你的看法。它应该存储在服务器端的某个地方，或者在服务器本身的平面文件中，或者在数据库中。
您在客户端机器上需要的是一个小 cookie，其中包含对这些敏感数据的一些晦涩难猜的引用。
恭喜！您刚刚重新发明了会话！
（如果您愿意，可以将 Web 服务器设置为将会话数据存储在数据库中，而不是存储在服务器上的平面文件中。）
确实，传统智慧是避免将 cookie 用于敏感数据，因为它们存储在客户端上，黑客可以修改它们并可能造成损害。然而，cookie 值得重新审视的一个令人信服的原因是：可扩展性。很难为任意数量的云服务器提供高性能的会话数据池：
http://aws.typepad.com/aws/2012/04/scalable-session-handling-in-php-using-amazon-dynamodb.html
这是我找到的一个链接，其中详细介绍了如何构建安全的 cookie 系统：
http://www.cse.msu.edu/~alexliu/publications/Cookie/cookie.pdf
因此，旧的可能又是新的。
通常我们使用 cookie，因为我们不一定在其中设置任何敏感数据。如果您的应用程序确实包含您不希望任何人摆弄的敏感数据，那么请务必使用您可以使用的每个服务器端和数据库工具来解决这个问题，但并非所有应用程序和实现在这些方面都需要这种级别的安全性。设置 cookie 是为了方便，仅此而已。
这已经完成了，否则我们会将用户名、地址和信用卡信息存储在 cookie 中而不是数据库中。您必须评估什么是有意义的保留在数据库中，什么是有意义的存储为 cookie。服务器性能、带宽、可扩展性——所有这些都必须牢记在心。请记住，我们在服务器端存储的越多，我们就越需要在客户端交付。
您还提到了会话 - 会话是cookie（有点）。
我在寻找一些与 cookie 与数据库参数相关的类似建议时遇到了这篇文章。
比如说，我有一些整数列表形式的用户数据，即一些带有书签的产品，每个用户最多 80 个。
在数据库中，这可以转换为 4 个表（每种数据类型 1 个），因此每个用户 20 行。
如果您每年有 100 万独立访问者，并且出于争论的原因，70% 是访客用户而不是成员，那么这可能会在一个表中添加 1400 万行，否则可能只有 600 万行。当然，您可以为来宾用户制定剔除政策，但这变得难以准确管理 - 也就是说，用户在 9 个月后没有返回以发现他/她的数据已被擦除。
硬币的另一面是访客数据存储在 cookie 中，因此存储多长时间并不重要。我很欣赏更多的工作涉及管理两种存储方法，但这是我能想到的唯一缺点。
任何人对此都有任何看法，我会很感激一些建议。