Php 存储用户搜索电子邮件警报的最佳策略是什么？

用户可以进行高级搜索（有许多可能的参数）：

/search/？query=toto&topic=12&minimumPrice=0&maxiumprice=1000

我想存储电子邮件警报的搜索参数（在

/search/？

之后）

我有两种可能：

将原始请求（

query=toto&topicId=12&minimumPrice=0&maxiumprice=1000

）存储在具有id、parameters等结构的表中

将请求存储在结构化表id、query、topicId、minimumPrice、maxiumprice等中

每种解决方案都有其优缺点。当然，解决方案2更干净，但它真的值得（过度）努力吗

如果您已经实施了这样一个解决方案，并且经历了维护，那么最好的解决方案是什么

对于每个维度，更好的解决方案应该是最好的：

僵硬

脆弱性

粘度

演出

---

您可以有一个由三列组成的表：

search\u id

、

key

、

value

，前两列是主键。这样，如果您具有已保存搜索的ID，则可以重建特定搜索。这还允许您使用其他搜索关键字进行扩展，而无需实际修改表

---

如果愿意，还可以将

键

作为包含有效搜索词的另一个表的外键，以确保完整性。不过，您是否想这样做取决于您的具体需求。

这完全取决于您想对数据做什么。对于PHP部分，无论如何都需要在插入或选择时对其进行处理

对于非常多的参数，您可以使用数据库管理/维护上的第一个参数节省一些时间，因为您不需要更改任何有关数据库方案的内容

<>丹尼尔的答案是一个通用的解决方案，但是如果你考虑性能问题，你可能会在数据库方面做太多的插入来进行单个搜索（每个参数一个）。插入太多是性能问题的常见根源

---

你知道你的资源。

丹尼尔的解决方案可能是最干净的解决方案，但我明白你关于性能的观点。我对PHP不是很熟悉，但应该有一些db抽象库来处理关系和多个插入，以便获得最佳性能，对吗？我之所以提到它，是因为可能没有真正的性能问题。您是否有指向某个问题的负载测试

无论如何，如果它介于您原来的两个解决方案之间，我必须选择第一个。拥有一个具有列名的表（如您的解决方案#2）只是自找麻烦。如果添加新参数，则必须修改表列。还有一个永远存在的问题是“我们用什么来表示未选中与留空？”

---

所以我不同意解决方案2更干净。

谢谢你的回答。不幸的是，我有一个高负载的网站，这意味着我不能有N插入每个警报。此外，更新需要许多我负担不起的请求：(