我正在制作一个涉及购物车的网站。有两个主要要求：
用户体验人员希望登录/身份验证是整个工作流程的最后一步。用户可以完成所有购物，并且仅在结帐时被要求登录。
购物车不应过期（即使在浏览器关闭时也不会过期），除非用户（已注册或未注册）确实结帐。
在上面的上下文中，关于维护购物车的状态，我有以下问题：
我应该使用基于文件的会话还是数据库会话？请记住，这将适用于未注册用户。我担心的是，我最终会在数据库中有很多记录。
另一种选择似乎是将购物车内容放在加密的cookie中，但cookie文件有大小限制。
在这种情况下，你会怎么做？我非常感谢您的回答。
跟踪用户。使用编码为具有 n年到期时间的 Cookie 的 GUID。
存放购物袋。您不想将袋子存放在饼干中，主要是因为它可能的大小。这就留下了将其推到介质并从介质中检索它的选项。为此，使用除数据库以外的任何东西都像是回到过去，数据库擅长存储和检索数据。
管理您的购物袋。现在，您的架构问题，首先，如果您要对数据库中的购物袋运行查询（即有多少购物袋包含项目x），您可能需要传统的关系架构。但是，这在插入方面存在开销。更新，选择（和加入）和删除袋子数据（在某些时候，您将拥有永远不会再次使用的袋子，但会占用宝贵的磁盘空间）。对于一个繁忙的站点，这是每秒相当多的Traranactions，但任何数据库都应该能够应对。如果不需要查询数据库中的购物袋，则可以将其存储为 XML。只需序列化包并将其转储到表中，PK 作为存储在用户 Cookie 中的 GUID。这将比传统架构快得多，而且如果确实需要关系架构，您将来可以随时拆解 XML。
这就是我们所做的（Xml Bag），我们拥有一百多万的客户群。
我会使用数据库管理的会话而不是文件管理的会话。确保您有一个会话时间戳，以便您最终可以终止旧会话（如果已经过了12个月，则购物者可能不会回来购买购物车中的原始商品）。
使用数据库而不是文件执行此操作将更容易最终使非常旧的信息过期。
请注意，数据库会话只有在用户计算机上绑定到的 Cookie 时才会有效。如果用户从其他浏览器返回到应用商店，他们将找不到其会话。如果两个人共用同一台计算机，他们将找到彼此的会话。希望购物车里不会有可能令人尴尬的物品......
