3

我正在使用会话将项目存储在用户愿望列表中。

愿望清单存储为一个简单的唯一项目 id 数组 - 普通用户会在愿望清单中存储大约 40 个项目，但用户可能希望在他们的愿望清单中添加多达几百个项目。

我想生成一个唯一的 URL，以便他们以后可以重新访问他们的愿望清单，或者与其他可以将其用作自己的清单起点的人共享愿望清单。

我没有从用户那里收集任何数据，他们也没有账户来链接他们的愿望清单数据。

我正在考虑的两种处理方法是：

将数据存储为 URL 末尾的哈希，可以是 url 编码的序列化字符串或 base64 编码的字符串。这似乎更可取，因为我不需要存储心愿单，这为用户修改现有列表提供了很大的灵活性，但是我怀疑如果心愿单中的项目数量增加并且 URL 长度超过可操作的字符数。

或者

生成具有唯一 ID 的 url 并将愿望清单保存到数据库中。我看到的问题是每次用户希望生成 URL 时都会向数据库添加一个新条目，并且由于这些条目不会与任何一个用户绑定，因此每次都需要生成一个新条目用户对列表进行任何修改的时间。

是否有另一种更好的方法来处理这个问题，或者有一种方法来管理与上述方法相关的问题？

4

1 回答 1

1

我认为从长远来看，走数据库路线将是最灵活的解决方案。只要您的数据建模良好，每次用户进行选择时添加/删除记录不应该成为问题。“选择”应该创建不超过键引用两件事的记录；一个用户，一个产品加上数量和价格。

也就是说，我会使用类似于以下的模型：

  • 产品（id，...）
  • selection_set (id, name)
  • 选择（product_id、selection_set_id、数量、价格）
  • 愿望清单（public_hash，selection_set_id）

Wishlist 与 selection_set 是分开的，因为您可以将 selection_set 重用于其他事物，例如购物车或订单。

完成后，您可以将 public_hash 存储在 cookie/会话中，并给他们一个链接到的 url。

这适用于您想到的场景吗？还是有任何额外的限制？

替代解决方案：

尽管我认为数据库是一个可行的解决方案，但我可以想到几个替代方案：

压缩和编码数据：

您可以使用逗号分隔的愿望清单项目 ID 列表（或某种唯一标识符），然后使用 base64_encode( gzinflate( $list ) ) 并将其用作您的哈希。然后，您可以使用 gzdeflate( base64_decode( $hash ) ) 来获取您的项目列表。为了避免在每次页面加载时执行此操作，您可以继续在会话中存储您的选择，并且仅在列表更改时重新生成哈希。

gzdeflate + base64 应该将您的哈希值保持在合理的长度内，以便进行非常大的愿望清单选择。您可以编写一些单元测试来查看哈希/列表可以假设多长时间。

这种方法感觉就像一个彻底的黑客:-)

使用Redis：

您可以设置一个 redis 服务器并在其上存储愿望清单。它将是持久的、可扩展的、快速且易于访问的。

于 2012-11-25T05:51:22.450 回答