我正在使用会话将项目存储在用户愿望列表中。
心愿单存储为一个简单的唯一项目ID数组 - 普通用户将在愿望清单中存储大约40个项目，但用户可能希望在他们的愿望清单中添加多达几百个项目。
我想生成一个唯一的网址，以便他们可以稍后重新访问他们的愿望清单，或与其他可以将其作为自己列表的起点的人分享愿望清单。
我没有收集用户的任何数据，他们也没有帐户可以将他们的心愿单数据链接到。
我正在考虑的两种解决方法是：
将数据作为哈希存储在URL的末尾，作为url编码的序列化字符串或base64编码的字符串。 这似乎更可取，因为我不需要存储愿望清单，这为用户修改现有列表提供了很大的灵活性，但我怀疑如果心愿单中的项目数量增加且URL长度超出范围，这将变得不可行可行的角色计数。
OR
生成具有唯一ID的网址并将心愿单保存到数据库。我看到的问题是，每次用户希望生成URL时，都会向数据库添加一个新条目，并且由于这些条目不会绑定到任何一个用户，因此每个条目都需要生成一个新条目。用户对列表进行任何修改的时间。
还有其他更好的方法来处理这个问题，还是管理与上述方法相关的问题的方法？
答案 0 :(得分：1)
我认为从长远来看，走数据库路线将是最灵活的解决方案。只要您的数据建模得很好，每次用户进行选择时添加/删除记录都不应成为问题。 “选择”应该只创建按键引用两个事物的记录;用户，产品加上数量和价格。
那就是说，我会用类似的模型做到这一点：
愿望清单与selection_set是分开的，因为您可以将selection_set重复用于其他内容，例如购物车或订单。
完成后，您可以将public_hash存储在cookie /会话中，并为其提供链接的URL。
这会对你想到的场景有效吗？还是有其他限制？
替代解决方案：
尽管我认为数据库是一个可行的解决方案，但我可以想到几个替代方案：
压缩和编码数据
您可以使用逗号分隔的心愿单项目ID列表（或某种唯一标识符），然后使用base64_encode（gzinflate（$ list））并将其用作哈希值。然后，您可以使用gzdeflate（base64_decode（$ hash））来获取项目列表。为了避免在每次页面加载时执行此操作，您可以继续在会话中存储您的选择，并仅在列表更改时重新生成哈希。
gzdeflate + base64应该将您的哈希值保持在可重复的长度内，以便选择非常大的心愿单。您可以编写一些单元测试来查看散列/列表可以假设多长时间。
这种方法感觉就像一个完全黑客： - ）
使用Redis：
您可以设置redis服务器并在其上存储心愿单。它将具有持久性，可扩展性，快速且易于访问。