Trädvy Permalänk
Medlem
Plats
Kungsholmen
Registrerad
Nov 2002

DB: Enum vs. tabell?

I detta typiska fall:

(pseudokod)

table1 { ... foregin_column_id fkey #references table2 } table2 { foregin_column_id pkey value vchar }

finns det då någon nackdel att istället använda enum om det är ett begränsat antal värden:

table1 { ... value enum('foo', bar', 'etc') }

Frågan är väl egentligen hur MySQL hanterar enum internt? Förutsätter att den lagrar pekare till värderna men var lagras dess vchar-värden? Är inte denna fetch-operation i sådana fall lika dyr som en join?

Lee Adama is a bitch!

Trädvy Permalänk
Testpilot
Plats
Norrköping
Registrerad
Sep 2002

Det står förklarat i manualen hur enum lagras: http://dev.mysql.com/doc/refman/5.0/en/enum.html
Det lagras som heltal, där det första av dina värden är 1, den andra är 2 osv. Ogiltiga värden är 0.

Här har du en bra jämförelse mellan att lagra som enum, varchar eller heltal med join: http://www.mysqlperformanceblog.com/2008/01/24/enum-fields-vs...

Vad jag läst mig fram till är enum bäst om man bara har få värden och som inte kommer ändras, exempelvis yes/no för att avgöra om ett meddelande är läst.

Kolla gärna in min RGB-LED-ljusstake i galleriet
[Gigabyte GA-Z97MX-Gaming 5][Intel Core i5 4690K][Corsair XMS3 8GB][Gigabyte GeForce GTX 970 G1 Gaming]

Trädvy Permalänk
Medlem
Plats
Kungsholmen
Registrerad
Nov 2002
Citat:

Ursprungligen inskrivet av hunden
Det står förklarat i manualen hur enum lagras: http://dev.mysql.com/doc/refman/5.0/en/enum.html
Det lagras som heltal, där det första av dina värden är 1, den andra är 2 osv. Ogiltiga värden är 0.

Här har du en bra jämförelse mellan att lagra som enum, varchar eller heltal med join: http://www.mysqlperformanceblog.com/2008/01/24/enum-fields-vs...

Vad jag läst mig fram till är enum bäst om man bara har få värden och som inte kommer ändras, exempelvis yes/no för att avgöra om ett meddelande är läst.

Jag förstår att det lagras som en "nyckel", undrade snarast var dess korrelerade värde lagras. Tror mig dock ha läste mig till att dessa lagras i minnet, varför det rimligare är snabbare än en (LEFT) JOIN.

(eftersom ENUM tar minst 1 byte i utrymme och en viss minnesmängd i anspråk för sin interna tabell samt kräver åtminstone en extra minnesläsning, är det nog i just fallet yes/no, false/true, etc bättre att istället använda BIT(1).)

Lee Adama is a bitch!

Trädvy Permalänk
Medlem
Plats
Stockholm
Registrerad
Jan 2004

Den sparas i tabelldefinationen och inte i tabelldatan. Det är olika filer (i MyISAM). Sen måste ju tabelldefinationen finnas i minnet vilket fall som helst och det tar inte speciellt mycket minne (vi snackar bytes).

Lite intressant läsning om BIT och MySQL.
http://www.xaprb.com/blog/2006/04/11/bit-values-in-mysql/

Trädvy Permalänk
Medlem
Plats
Kungsholmen
Registrerad
Nov 2002
Citat:

Ursprungligen inskrivet av iXam
Den sparas i tabelldefinationen och inte i tabelldatan. Det är olika filer (i MyISAM). Sen måste ju tabelldefinationen finnas i minnet vilket fall som helst och det tar inte speciellt mycket minne (vi snackar bytes).

Lite intressant läsning om BIT och MySQL.
http://www.xaprb.com/blog/2006/04/11/bit-values-in-mysql/

Kool, nu förstår jag iaf hur ENUM funkar.

Det måste ju fortfarande vara viss overhead för att map:a siffran till värdet el vice versa, även om det vanligen säkert är försumbart.

Ska erkänna att jag enbart använder BIT för bitmaskar o.d. (även om man ofta kan nyttja SET istället, om inte annat för att det är enklare för någon annan att ta över projektet då), för typiska bool-värden brukar jag alltid använda en unsigned tinyint - mest av gammal vana antar jag.

Lee Adama is a bitch!