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

Question

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

/search/?query=toto&topic=12&minimumPrice=0&maximumPrice=1000

我想存储电子邮件提醒的搜索参数（在/search/?之后）。

我有两个可能性：

1. 将原始请求（query=toto&topicId=12&minimumPrice=0&maximumPrice=1000）存储在具有id，parameters等结构的表中。
2. 将请求存储在结构化表id，query，topicId，minimumPrice，maximumPrice等中

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

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

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

1. 刚性
2. 脆弱性
3. 粘度
4. 性能

Answer 1

您可以拥有一个由三列组成的表格：search_id，key，value，其中两列是主键。这样，如果您拥有已保存搜索的ID，则可以重建特定搜索。这也允许您使用其他搜索关键字进行扩展，而无需实际修改您的表格。

如果您愿意，还可以将key作为包含有效搜索字词的另一个表的外键，以确保完整性。您是否愿意这样做取决于您的具体需求。

Answer 2

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

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

Daniel的回答是一个通用的解决方案，但是如果你认为性能是一个问题，你可能最终会在数据库端为一次搜索做一个太多的插入（每个参数一个）。插入太多是性能问题的常见原因。

您了解自己的资源。

Answer 3

Daniel的解决方案很可能是最干净的解决方案，但我对性能有所了解。我对PHP不是很熟悉，但是应该有一些db抽象库可以处理关系和多次插入，以便获得最佳性能，对吧？我只提到它，因为可能没有真正的性能问题。您是否有指向某个问题的负载测试？

无论如何，如果它在你原来的2个解决方案之间，我将不得不选择第一个。拥有一个包含列名的表（就像您的解决方案＃2）只是在寻找麻烦。如果添加新参数，则必须修改表列。还有一个问题是“ 我们用什么来表示未选中vs左空？ ”

所以我不同意解决方案2更清洁。