我應該標準化我的字元串數組，還是只保留一個簡單的字元串？
我正在做一個涉及《萬智牌：聚會》遊戲中的卡片的項目。為了有任何用處，我必須將有關每張卡片的基本資訊載入到我的數據庫中，但是某些欄位可能包含文本數組，即它們可能包含多個值。
例如，一張卡片可以被分類為“綠色”和“藍色”。或者它可以指定幾種不同的生物類型，等等。
我的第一個想法是將值簡單地儲存為字元串，然後使用 LIKE 關鍵字進行搜尋。結合 NOT 關鍵字，應該可以搜尋任何所需的單片語合，也可以排除某些單詞。
但是，LIKE 會（相對）慢，因為它不能使用索引並且必須依賴文本模式匹配，並且可能還有其他缺點。通過規範化，我可以通過為每個關鍵字分配一個整數鍵來提高速度，然後創建一個將每張卡與相關鍵連接起來的表（請參閱EBrowns 答案以獲得更清晰的描述）。
但是對於規範化的表，我必須處理連接（不僅在 SQL 部分中，程式碼複雜性嚴重增加）、事務（更新所有相關表或回滾所有內容），還可能由於連接而降低性能（請參閱是否規範化） .
AFAIK 大約有 20000-25000 張不同的魔法卡存在（並且每年都會發布更多）。每張卡有一行，標準化數據是否值得整體標準化，還是收益不值得成本？為什麼/為什麼不？你一般如何決定這個問題？
**編輯：**我目前正在使用 MySQL 數據庫，但我也希望得到適用於任何其他非商業/開源數據庫的答案。誰知道——我可能會在某個時候切換到不同的數據庫。
答案不應僅提供技術解決方案，而應解釋為什麼它會/可能是最佳/足夠好的性能以最少的工作量的正確解決方案。
您可能需要考慮以下幾點：
- 數據的維護。
如果數據要經常更改，那麼將數據標準化會更容易和更快，因此您只需在一個地方更改它並自動更新它的所有用法。相反，如果數據幾乎沒有變化，那麼這不是考慮因素。 2. 全文搜尋。
這應該比
like '%string%'搜尋更快，並且根據您的數據庫和可用的內容，可能會決定您儲存數據的格式。此外，在表中重複儲存文本很明顯會增加數據庫的大小。這可能會影響性能或花費更多成本來確保伺服器上有足夠的磁碟空間和/或可用記憶體。
維基百科有一篇關於基礎知識的文章。這不是我非常熟悉的領域，只是一位同事正在研究這個，並且在進行其他搜尋時需要權衡數據的組織方式。其他連結 - MSDN、MySQL和PostgreSQL
好吧，您可以按照您之前所說的方式進行攻擊，或者您可以走另一條路。
通常，在這種情況下，我會創建三個表。
表 1 - 卡片：這將包含基本卡片資訊。
表 2 - 類型：這將是每個可能的類型的一個記錄（即綠色的一個記錄，藍色的一個記錄，生物 A 的一個記錄，生物 B 的一個記錄，等等。）
表 3 - CardTypes：這將有兩列，一是卡片的外鍵，一是類型的外鍵。兩者的組合將是主鍵。
這種方法的優點是您不必儲存大量純文字，就好像一張卡片有多個屬性，它們在 Types 中都是一對一的，然後與每個屬性的關係就會消失在卡片類型中。這也意味著如果兩張卡是藍色的，那麼只有一個類型儲存為藍色，並且兩個（小，請注意）條目在 CardTypes 中。
失敗是明顯的成本。您的程序必須知道這三個表。
優勢完全取決於您查詢表的頻率。如果您經常查詢特定屬性，那麼 CardTypes 上的索引將顯著提高性能，因為該索引將包含指向具有該屬性的卡片的必要指針。
最後，這一切都取決於您將執行的頻率/多少查詢。如果您正在執行大量數據，則最好承擔創建兩個表然後將它們與第三個錶鍊接的程式成本。