這是MySQL枚舉數據類型的適當使用嗎？

Question

我最近在空餘時間開始做自由PHP + MySQL開發，以補充我從C＃/ SQL Server代碼編寫的全職工作中獲得的收入。我注意到的一個與數據庫相關的重大差異之一是MySQL有一個枚舉數據類型，而SQL Server則沒有。

當我注意到enum數據類型時，我立即決定壓扁我的數據模型，以支持使用枚舉的大表，而不是使用許多較小的表來表示離散實體和一個大的「橋」類表。

我目前正在使用的網站是用於唱片公司的。我只有一張表來存儲標籤的發行版，即「發行版」表。我通常在任何地方都使用枚舉，我通常會將外鍵用於單獨的表格 - 藝術家名稱，標籤名稱和其他幾個。用戶可以通過後端編輯這些枚舉列。我所看到的使用文本字段進行枚舉的主要優點是藝術家名稱將被重用，這將改善數據完整性。我也看到了在數據庫中擁有較少表的優勢。順便說一下，我還有一個額外的表格和一個橋接表格 - 有一個「標籤」功能可以爲特定版本添加標籤，並且由於這是一種多對多的關係，所以我覺得離散標籤表和表橋加入標籤的版本是合適的

有從未遇到之前數據庫中的數據類型ENUM，我不知道如果我作出明智地使用這項功能，或者是否有問題我沒有預見作爲這種數據架構的結果，可能會回來咬我。有經驗的MySQL'ers，你覺得怎麼樣？

Answer 1

我會說實話 - 我停下來，當我讀到...

我用枚舉我到處 通常會使用一個外鍵到 單獨的表 - 藝術家的名字，標籤 名稱和其他幾個。

如果我理解正確，那就意味着有一個所有藝術家的枚舉。但是，藝術家的列舉肯定會成爲一個變化點：將會有更多的藝術家。我真誠懷疑唱片公司從來沒有計劃增加或改變藝術家名單;）

因此，在我看來，這是一個不正確的使用枚舉。

我也不認爲適合執行ALTER TABLE是不可避免的一個相當平凡的用例。 （創建/閱讀/更新/銷燬藝術家）我沒有數字來支持這一觀點。

你必須把它看作一個什麼樣的信息是一個實體或一個實體屬性的問題：對於一個唱片公司，藝術家是實體，但媒體類型可能不是。藝術家有很多與他們有關的信息（姓名，流派，獎項，網站網址，資歷等），這表明他們是一個實體，而不是諸如發佈等其他實體的屬性。此外，藝術家創建/閱讀/更新和銷燬作爲他的系統日常使用的一部分，進一步表明他們是實體。

實體傾向於獲得他們自己的表。現在，當您查看這些版本的媒體類型時，您不得不問自己媒體類型是否有其他信息......如果它不是名稱，您有新的實體。例如，如果您的系統必須跟蹤媒體類型是否過時，現在媒體類型（名稱，已過時）有兩個屬性，它應該是一個單獨的實體。如果Medai類型只在您構建的範圍內有一個名稱，那麼它是另一個實體的屬性，並且應該只是一個列而不是一個表。那時我會考慮使用枚舉。

Answer 2

總之，這不是一個好設計。外鍵有目的。

從the documentation for the ENUM type：

枚舉可以具有最大65535個元件。

您的設計不允許您存儲超過65k個不同的藝術家姓名。

您是否考慮過添加新藝術家名稱會發生​​什麼？我假設你正在運行一個ALTER TABLE來添加新的枚舉類型？根據a similar SO question this is a very expensive operation。將其與簡單地將另一行添加到artist表的成本相對比。

如果您有多個表需要引用藝術家/藝術家的名字，會發生什麼情況？你如何在表中重用枚舉值？

此方法還有許多其他問題。我認爲簡化你的數據庫設計就像這樣，你真的會傷害（外鍵或者有多個表並不是壞事！）。

Answer 3

我不認爲你可以在像藝術家這樣的領域中使用枚舉。它就像你正在限制你的應用程序不斷增長。這將是很難保持專欄。使用ENUM不是它自己的問題。但在以下情況下會出現問題

1. 當您需要將其他選項添加到枚舉列。如果您的表格包含大量數據，那麼在添加附加選項時需要花費很長時間重新生成表格
2. 當您需要將數據庫移植到另一種技術時（枚舉在所有數據庫產品中都不可用，例如MSSQL ）