存儲用戶搜索電子郵件警報的最佳策略是什麼？

Question

用戶可以做高級搜索（它們是許多可能的參數）：

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

我想存儲搜索參數（/search/?之後）的電子郵件警報。

我有2個possibilites：

1. 存儲在表的原始請求（query=toto&topicId=12&minimumPrice=0&maximumPrice=1000）與像ID，參數的結構。
2. 存儲在結構化的表ID的請求，查詢，topicId，minimumPrice，maximumPrice等

每個解決方案都有其優點和缺點。當然，解決方案2是更清潔的，但它真的值得（超）努力嗎？

如果您已經實施了此類解決方案並且經歷了維護，那麼最佳解決方案是什麼？

更好的解決辦法應該是最好的每個維度：

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

Answer 1

丹尼爾的解決方案很可能是最乾淨的解決方案，但我明白了關於性能的觀點。我對PHP並不是很熟悉，但是應該有一些db抽象庫來處理關係和多次插入，以便獲得最佳性能，對嗎？我只提到它，因爲可能沒有真正的性能問題。您是否有負載測試可能指出問題？

無論如何，如果它是你原來的兩個解決方案之間，我將不得不選擇第一個。有一個列名稱列表（如您的解決方案＃2）只是要求麻煩。如果添加新的參數，則必須修改表格列。還有就是「我們怎麼把指示不選擇VS空？」

因此，我不同意，解決方案2是清潔永遠存在的問題。

Answer 2

你可以有由三列的表： search_id,key,value與兩個第一個主鍵。這樣，如果您有保存的搜索的ID，則可以重新構建特定的搜索。這也使您可以使用其他搜索關鍵字進行擴展，而無需實際修改表格。

如果您願意，您還可以讓key作爲另一個包含有效搜索條件以確保完整性的表的外鍵。不管你想這樣做，取決於你的具體需求。

Answer 3

那麼這完全取決於你想要處理的數據。對於PHP部分，無論是插入還是選擇時間，您都需要處理它。

對於數量非常大的參數，您可以在數據庫管理/維護中節省一些時間，因爲您不需要更改有關數據庫方案的任何內容。

Daniel的答案是一個通用的解決方案，但是如果您考慮性能問題，最終可能會在數據庫端爲單個搜索（每個參數一個）執行太多插入操作。太多插入是性能問題的常見來源。

你知道你的資源。