MySQL ENUM-type versus join-tabellen

• Het wijzigen van de reeks waarden in een ENUM vereist een ALTER TABLE wat een tabelherstructurering zou kunnen veroorzaken -- een ongelooflijk dure operatie (de tabelherstructurering gebeurt niet als u eenvoudig één nieuwe waarde toevoegt aan het einde van de ENUM-definitie, maar als u er een verwijdert of de volgorde wijzigt, doet het een tabel herstructureren). Terwijl het wijzigen van de reeks waarden in een opzoektabel net zo eenvoudig is als INSERT of DELETE.

• Er is geen manier om andere attributen te associëren met de waarden in een ENUM, zoals welke buiten gebruik zijn gesteld en welke in aanmerking komen om in een vervolgkeuzelijst in uw gebruikersinterface te worden geplaatst. Een opzoektabel kan echter extra kolommen voor dergelijke attributen bevatten.

• Het is erg moeilijk om een ​​ENUM op te vragen om een ​​lijst met afzonderlijke waarden te krijgen, waarbij u in feite de definitie van het gegevenstype moet opvragen van INFORMATION_SCHEMA , en het ontleden van de lijst uit de geretourneerde BLOB. Je zou kunnen proberen SELECT DISTINCT status uit uw tabel, maar die krijgt alleen statuswaarden die momenteel in gebruik zijn, wat mogelijk niet alle waarden in de ENUM zijn. Als u echter waarden in een opzoektabel bewaart, is het gemakkelijk om te zoeken, sorteren, enz.

Ik ben geen grote fan van ENUM, zoals je kunt zien. :-)

Hetzelfde geldt voor CHECK-beperkingen die een kolom eenvoudigweg vergelijken met een vaste set waarden. Hoewel MySQL sowieso geen CHECK-beperkingen ondersteunt.

Update:MySQL 8.0.16 implementeert nu CHECK beperkingen .