列舉仍然是邪惡的嗎（在 MySQL 8.0 中）？
因此，我與一位同事在使用列舉與查找表方面存在分歧。
這篇 2011 年的非常古老的文章和 MyQL5.5仍然被那些不喜歡列舉的人一次又一次地引用。
但是我們在不是那麼大的數據庫上使用 MySQL8.0，比如 50 到 60 個表，有 30 個列舉列。
一些表有幾百萬行，大多數都低於 500K 行。
幾乎所有列舉的值都少於 10 個，並且只有極少數在其生命中發生了變化（一次），總是在可能值的末尾添加一個新值。
而且我們從來沒有“遭受”過文章提到的任何缺點，比如將元數據儲存在旁邊，從其他表中引用相同的值等等……
儘管文章在第 2 點說了什麼，但今天，在列表末尾添加一個值並不會更新整個表，但刪除一個值總是會更新（或至少讀取）所有行。
我確實知道有兩個學派，我了解兩者的優點和缺點。
但是，今天在 MySQL8 上，是否有任何實際/事實/技術原因，所以從現有列**的列舉切換並證明應用程序和數據庫中的所有工作都需要這樣做？
感謝您的閱讀和您的回答。
MySQL 5.5 和 8.0 之間沒有任何改變，使得 ENUM 比以前更加邪惡。
我認為稱其為“邪惡”是誇張的。程式語言特性並不邪惡。但它可能會被不了解其缺點的開發人員*濫用。*然後他們遇到了麻煩。
如果您擁有的 ENUM 列對您來說執行良好，並且您目前的項目沒有受到不利影響，那麼沒有理由切換它們。
在設計新表格時，牢記利弊是一件好事。在一個表中使用 ENUM 可能工作正常，而在同一項目的另一個表中使用它會與其中一個問題發生衝突。這取決於如何使用每個表。
我在我的書SQL Antipatterns Volume 1: Avoiding the Pitfalls of Database Programming的一章中寫了更多關於 ENUM 的內容。
不幸的是，我是那些看到鮮血就畏縮的人之一，呃…… ENUMs。我在 10.5 年前引用了同一篇文章：使用 ENUM 與整數類型的優點和缺點？
我與 ENUM 的唯一主要問題是為 ENUM 類型聲明的值的順序。如果您不斷添加新值，請不要更改值的順序。繼續追加新值。如果你重新排列值的順序，現在邪惡就出現了。價值觀的背景可能會非常迅速地向南發展。
您可以通過將數據類型更改為 VARCHAR、自行更改值，然後將數據類型更改回 ENUM 來緩解此類問題。這樣，由 ENUM 表示的值的上下文將保持穩定。我已經看到一兩個客戶在 5.7 中這樣做沒有問題，所以我真的不明白為什麼 8.0 會有任何問題。