Dotaz: Databázové schéma pro mnoho vícehodnotových atributů

[what]

Ahoj. Řeším, jak správně navrhnout schéma pro následující situaci. Mám nějakou osobu/uživatele. Ten má nějaké povinné klasické atributy (jméno, příjmení, ...), ale také mnoho volitelných vícehodnotových. Nejen, že jsou tyto atributy volitelné, ale mohou se často měnit (schéma), tzn. přibývat další a některé ubývat. Jak toto řešit v relační databázi (postgresql)? Jít cestou ohromné denormalizace a vše mít v jedné tabulce redundantně nebo dekompozice po atributech (sloupcích) nebo EAV antipattern? Na těchto datech se budou provádět často následující dotazy: vyhledat/filtrovat podle více atributů (sloupců), řadit vždy podle jednoho a často se měnit data. Děkuji za jakékoliv nápady.

Odpovědi

[Kit]

EAV je bez významu.

Klasické atributy jsou snad jednoznačné: Co atribut, to sloupec.

Na volitelné atributy bych pro PostgreSQL vybral doplněk hstore.

Alternativou je jsonb, do které bych s klidem dal i povinné neklíčové atributy. Výhodou proti hstore je, že se nevkládá slovník, ale strom. Není tedy problém uložit několik telefonních čísel či přechodných pobytů.

[what]

EAV je bez významu.

Proč? Minimálně má tu výhodu, že při přidávání/odstraňování atributů nebude potřeba upravovat strukturu tabulky a tím pádem jí zamykat.

Jak je to s rychlostí hstore/jsonb vs klasická dekompozice? Jak vysoká režie je spojování mnoha tabulek?

[Kit]

EAV je bez významu.

Proč? Minimálně má tu výhodu, že při přidávání/odstraňování atributů nebude potřeba upravovat strukturu tabulky a tím pádem jí zamykat.

EAV má mnohem víc nevýhod než výhod. Tam, kde je dostupný hstore/jsonb, bude EAV pouze kulhat.

hstore/jsonb jsou dynamickými strukturami. K čemu je pak dobré zamykání tabulek?

Jak je to s rychlostí hstore/jsonb vs klasická dekompozice? Jak vysoká režie je spojování mnoha tabulek?

Klasická dekompozice má výhody zejména v tom, že můžeš data lépe normalizovat a tím usnadnit vyhledávání - hstore/jsonb je svou povahou spíš na ukládání dokumentů.

Pomalost EAV se těžce projevuje už při jednotkách tisíc položek. Čím víc, tím hůř. Kromě toho tam jsou značné problémy s datovými typy.

Z toho vyplývá, že by se především měla dát přednost pevné struktuře. Pokud nestačí, můžeme využít služeb hstore/jsonb, případně jiných zajímavých konstrukcí.

[xkucf03]

EAV je úplně v pohodě, pokud potřebuješ data v první řadě ukládat a číst, ale nemáš velké nároky na vyhledávání.

A pokud si dokážeš udělat index pro efektivní vyhledávání nad hstore/jsonb, tak si ho dokážeš udělat i nad EAV. Akorát do toho EAV je líp vidět a snáz v něm udržíš pořádek (máš číselník/slovník atributů).

To jen aby nevznikaly nějaké zbytečné fámy, tabu a neopodstatněný strach z určitého nástroje. EAV má svoje smysluplné uplatnění stejně jako kterýkoli jiný návrhový vzor.

[okbob]

Dnes se EAV považuje za antipattern, takže s výše uvedeným tvrzením nesouhlasím - u EAV je nutné entitu rekonstruovat vícenásobným joinem, což zesložiťuje psaní dotazu (a snižuje čitelnost), navíc zákonitě - díky chybám v odhadech kardinality roste riziko neoptimálních prováděcích plánů - toto riziko není tak velké u databází s jednodušším plannerem, ale u chytřejších databází to může být docela problém. V Postgresu HStore/jsonb/XML prakticky ve všech ohledech překonává EAV (velikost tabulky, práce s odhady, složitost a čitelnost dotazů).

[xkucf03]

Rekonstrukce entity z EAV je jeden dotaz:

SELECT název, hodnota FROM eav_tabulka WHERE entita = ?

Tím mám všechny atributy dané entity¹ a můžu nad nimi vyhodnotit dotaz – ať už v aplikaci nebo nějakou DB funkcí – např. a1 = 10 AND a2 > 5 AND (a3 = 'x' OR a3 = 'y').

Ano, znamená to, že musím projít všechna data, full table scan, ale kde nemusím? Když napíšu totéž jako XPath dotaz, jak si s tím PostgreSQL poradí? Budou fungovat indexy nebo budu muset projít všechny ty XML dokumenty a nad každým vyhodnotit daný XPath? Indexy pro konkrétní XPath dotazy si můžu připravit předem – ale co když předem nevím, jaké dotazy budou uživatelé klást? A jak je to se složenými dotazy (AND/OR)? Když budu mít AND/OR operátory uvnitř XPath dotazu, dokáže PostgreSQL využít jednotlivé indexy pro dílčí dotazy, které jsem si teoreticky mohl připravit předem? Minimálně bych musel udělat tolik indexů, kolik mám atributů (tisíce nebo víc), ne?

U toho EAV si dokážu představit rozdělení dotazu na dvě fáze: 1) vybrat z dotazu určité podmínky a na základě nich udělat hrubý výběr, vytáhnout si z DB podmnožinu dat; při tom se využijí indexy 2) iterovat přes tuto podmnožinu a vyhodnotit celý dotaz.

_{[1] BTW: původně jsem psal: „EAV je úplně v pohodě, pokud potřebuješ data v první řadě ukládat a číst, ale nemáš velké nároky na vyhledávání.“ – na zobrazení entity mi to stačí a není s tím žádný problém}

[okbob]

Tím ale nedostanu 1 řádek, ale n řádků - a jakákoliv manipulace s těmito daty vyjma poslání dat na klienta je dost ojeb. Entitou myslím v relační databázi jeden záznam.

V Postgresu jsou pro HStore a jsonb přepravené speciální indexy optimalizované na dotazy typu klíč/hodnota - takže určitě není nutné indexovat každý klíč vlastním indexem - jakkoliv je to možné skreze funkcionální indexy.

[xkucf03]

Tím ale nedostanu 1 řádek, ale n řádků - a jakákoliv manipulace s těmito daty vyjma poslání dat na klienta je dost ojeb. Entitou myslím v relační databázi jeden záznam.

Dostat z toho entitu v podobě jednoho řádku je nereálné/nepraktické, protože by tam byly tisíce sloupečků, většina prázdných a jiné by obsahovaly více hodnot (asi pole).

V Postgresu jsou pro HStore a jsonb přepravené speciální indexy optimalizované na dotazy typu klíč/hodnota

Je tohle tedy doporučený způsob pro uložení atributů výrobků? Dají se nad tím psát rozumně dotazy, o kterých píšu v #4. Pokud by šlo použít jen PostgreSQL a nebylo by potřeba do toho tahat další databázový systém, tak by to bylo ideální.

[okbob]

Hstore nebo lépe jsonb (nástupce Hstore) jsou určitě pro tento způsob doporučené. S kombinací indexů (klasických+funkcionální) by se asi většina dotazů dala provést efektivně.

[okbob]

+ extenze JsQuery http://pgxn.org/dist/jsquery/1.0.0/

[xkucf03]

Dejme tomu, že to XML bude vypadat takhle:

<produkt>
    <barva>červená</barva>
    <rozměrX>10</rozměrX>
    <rozměrY>20</rozměrY>
    <rozměrZ>30</rozměrZ>
    <hmotnost>500</hmotnost>
    <rozhraní>VGA</rozhraní>
    <rozhraní>HDMI</rozhraní>
    <rozhraní>DP</rozhraní>
</produkt>

A udělám si indexy pro jednotlivé atributy:

xpath('/produkt/barva/text()', atributy)
xpath('/produkt/rozměrX/text()', atributy)
xpath('/produkt/rozměrY/text()', atributy)
xpath('/produkt/rozměrZ/text()', atributy)
xpath('/produkt/hmotnost/text()', atributy)
xpath('/produkt/rozhraní/text()', atributy)

A pak bych ten dotaz mohl postavit tak, že AND a OR nebudou uvnitř XPathu, ale budou v SQL.

Funkce xpath() ale vrací pole a já nechci testovat přesnou shodu pole=pole, ale budu mít spíš dotaz ve stylu: pole obsahuje hodnoty A a B, pole neobsahuje hodnotu X, pole obsahuje hodnoty C nebo D. Takže do hry vstupují ještě funkce pro práci s poli – jejichž výsledky ale naindexované už nemám (protože předem nevím, na jaké hodnoty se uživatelé budou ptát a jaké AND a OR podmínky si sestaví).

Jaké je tedy lepší řešení? A vadí něčemu velký počet indexů? (kromě toho, že zabírají místo na disku)

[okbob]

Takhle by to šlo také, ale není to ta nejlepší varianta - vyhledávání v XML není v Postgresu nijak zvlášť optimalizované a člověk se musí spolehnout pouze na funkcionální indexy.

Pokud budu mít atribut, podle kterého často vyhledávám, a který dobře filtruje, pak by to měl být relační atribut a nemá co dělat v nerelačním balastu. Hledání v nerelačním balastu je zatím omezené na rovnost/nerovnost - a případně kombinace bitmap heap scanu, index scanu a následného filtrování. V plánu je integrace http://www.pgcon.org/2014/schedule/attachments/318_pgcon-2014-vodka.pdf , která ledacos změní (ale univerzální nerelační engine typu ElasticSearch z PG nebude).

Jestli vadí větší počet indexů? To záleží na kontextu - v každém případě každý index zpomaluje insert/update - zabírá místo v paměti (nebo se musí číst z disku (a navíc skrz random IO), zapisuje se víc dat do transakčního logu - pokud máte dost ramky, tak pak nemáte problém, ale když nemáte, tak ve výsledku můžete mít přetížené IO, nižší hit ratio u cache, ..

[xkucf03]

Zrovna jsem chtěl položit podobnou otázku

Přemýšlel jsem nad datovým modelem pro atributy produktů v obchodě. Dejme tomu, že chci udělat něco jako eBay (ale lepší samozřejmě).

Požadavky:

• Máme slovník atributů – barva, rozměry, počet USB portů, jejich rychlosti, maximální rychlost, počet pokojů atd. klasika.
• Atributů budou stovky až tisíce, možná i víc a budou přibývat.
• Atribut může mít víc hodnot, např. rozhraní = {VGA, HDMI, DVI}.
• Nemáme pevně dané skupiny atributů (např. grafické karty mají atributy g1 až g10, reproduktory mají atributy r1 až r5); jakýkoli výrobek může mít nastaven jakýkoli atribut – to už záleží na tom, kdo zadává data, systém ale použití neomezuje.
• Atributy mohou mít různé datové typy (celé číslo, desetinné číslo, boolean, datum, výčtový typ…).
• Produkt může mít víc variant, které se mohou v některých atributech lišit zatímco jiné zase dědí.
• Kromě atributů tam budou hierarchie a budeme chtít prohledávat určitý podstrom – např. „oddělení: počítačové komponenty / grafické karty“ nebo „země výrobce: Asie / Čína“ i tyhle stromové dotazy můžou být spojené AND a OR operátory – např. „grafická karta AND (Čína OR Korea)“.
• Je potřeba mít dotazovací jazyk, který umožňuje psát složité dotazy typu: „rozměry jsou menší než X,Y,Z AND počet USB portů > 2 AND rozhraní = (VGA AND (HDMI OR DP)) AND operační systém NOT MS Windows“ + to umístění v podstromu (podstromech).
• Celé to musí být dostatečně rychlé a škálovatelné.

Tohle je takový ideál, možná nedosažitelný, ke kterému se dá jen přiblížit…

Mám rád relační databáze, na většinu úloh je to ideální nástroj a relační databáze tam určitě bude¹, takže je celkem přirozené to zkusit navrhnout nad ní. Taky je dobré minimalizovat počet použitých technologií. Na druhou stranu ve výsledku to dopadne spíš tak, že budou databáze dvě: relační na většinu dat + nějaká jiná pro atributy a hierarchie + možná ještě něco dalšího pro fulltext.

Co mě zatím napadlo:

• EAV – jakkoli se nedoporučuje, úplně bych ho nezavrhoval. Zpočátku bude dat málo a mohlo by to v pohodě fungovat. S rostoucím objemem dat se přejde na jinou technologii/model. Je totiž naivní si myslet, že na začátku člověk vybere vhodný nástroj, který mu vydrží navěky – hodně věcí se ukáže až v průběhu reálného používání a sebelepší analýza je nedokáže předem odhalit. Třeba se ukáže, že klíčové je něco jiného, než vyhledávání podle atributů a nemá cenu na něj plýtvat čas (třeba nebude chtít nikdo ty atributy zadávat nebo podle nich vyhledávat a bylo by to celé zbytečná práce).
• EAV jako primární zdroj dat + jeho denormalizovaná kopie pro lepší vyhledávání – nějaký index, materializovaný pohled, nebo dynamicky vytvořené a naplněné tabulky. To by mohlo celkem fungovat, ale tuším tam problém s prohledáváním vícenásobných atributů – buď to budou pole a tam nevím, jak to bude s rychlostí a indexy, nebo to bude více záznamů v tabulce a tam se budou hůř psát AND dotazy (OR v pohodě).
• Dynamicky generovaná tabulka, která bude obsahovat sloupec pro každý atribut – těch ale můžou být tisíce nebo i víc – jak si s tím poradí třeba PostgreSQL? Jaká bude efektivita uložení takových dat? (většina sloupečků bude prázdná – řídká data)
• Dynamicky generované tabulky – pro každý atribut jedna – opět jich můžou být tisíce nebo víc. V obou předchozích případech bude zase problém s prohledáváním vícenásobných atributů.
• XML sloupec obsahující atributy + nějaký index nad ním
• RDF databáze a jazyk SPARQL – tohle vypadá celkem slibně. Máte s tím někdo zkušenost jako s databází pro produktové atributy? Jak dobře se píší složitější dotazy? Jak je to s výkonem? Např. Apache Jena, 4store nebo MonetDB.
• Sloupcové databáze, Druid.io, Apache Cassandra, Hadoop, Neo4j…

P.S. zatím to jsou spíš teoretické úvahy a diskuse na nedělní odpoledne

_{[1] fakt nechci vést účetnictví nebo údaje o klientech v nějaké bezschémové/noSQL databázi a mít tam bordel a při psaní každého dotazu si rvát vlasy}

[EtDirloth]

Ked pozeram ten tvoj vycet poziadaviek, napada ma Anchor Modeling. Je to asi jedina metoda navrhu, o ktorej som pocul, ze by v tomto mohla konkurovat noSQL, resp. dokumentovym databazam (hstore a jsonb nevynimajuc).

[xkucf03]

Dík, to vypadá zajímavě, musím si to prostudovat…

[Josef Kufner]

Na toto bych šel cestou několika tabulek. Sestavil bych si typovou hierarchii, která by popisovala ukládané objekty. Například v e-shopu se to udělá celkem snadno. Tím vyplynou skupiny parametrů, které se typicky vyskytují spolu. Každé takové skupině bych dal jednu tabulku se sloupcem pro každý parametr ve skupině. Žádná dědičnost v databázi, ta by byla jen na papíře pro identifikaci skupin. Skupiny by byly jinak už placaté – parametr by byl identifikován názvem skupiny a názvem parametru ve skupině.

Každý objekt by byl uložen spolu se sadou základních parametrů v centrální tabulce a vazbami 1:1 by se přidávaly tabulky skupin parametrů. Tím pádem nebude příliš mnoho ani prázdných sloupců, ani tabulek.

Číselníky bych obcházel přes ENUM, pokud by to šlo. Pokud ne, tak bych se snažil alespoň číselníky sdílet mezi parametry, například u kabelu je konektor na začátku i na konci a oba jsou ze stejného číselníku. Nabízí se otázka, zda mít jeden velký číselník, nebo hodně malých.

Pokud by měl mít parametr více hodnot, pak bych využil SET nebo bitmapy a číselníky. Málokdy bude potřeba, aby parametr nabýval hodnot z množiny větší než těch 64 prvků na které stačí BIGINT. Pokud to nebude stačit, M:N a tedy další tabulce se nevyhneme.

Určitě je však potřeba mít nad tímhle monstrem postavený bytelný framework, který to zvládne automaticky řešit a hlídat. Udržovat to jakkoliv ručně by byl slušný horor.

Pro malé databáze a relativně jednoduché modely se však hodí je serializovat do JSONu a nechat v jednom sloupečku (ať už pomocí nástrojů databáze nebo na úrovni aplikace). Šetří to čas na počátku vývoje a konverze na robustnější řešení je docela snadná.

Důležité v obou případech je, aby platilo, že jedna entita má někde jeden řádek. A že parametry mají sloupečky. Jakmile se tohle poruší, je horor s tím pracovat.

[Kit]

Tohle jsem udělal ve své aplikaci a byl jsem mile překvapen (i když jsem to očekával) nárůstem výkonu. Je to vlastně využití vazby 1:1, o které se toho mnoho neví a je (často zbytečně) zatracována. V takové databázi se však velmi dobře hledá, často nejsou potřebné ani indexy. Například pokud mám ve skladu 100k položek, ale jen 250 z nich jsou kabelové koncovky, mohu si dovolit prohledat tabulku s parametry kabelových koncovek klidně i sekvenčně s pomocí LIKE. Hlavní tabulka pak potřebuje index pouze na id, ta se k výsledku hledání jen připojí. Dokonce i sekvenční prohledávání hlavní tabulky podle názvu je rychlejší, pokud se k ní připojí tabulka s parametry těch kabelových koncovek.

Číselníky jsou poněkud problematické, pokud se má tentýž číselník vyskytovat ve více tabulkách. Podle mne je lepší mít hodně malých číselníků.

SET se skvěle hodí na ukládání booleovských hodnot - fajfky ve formulářích. Nedá se podle nich rozumně indexovat, což je diskvalifikuje z indexovaného vyhledávání. Záleží na konkrétním use case, zda použít SET nebo M:N.

Ruční údržba není nijak zvlášť náročná, pokud se držíš zavedených pravidel a nevymýšlíš blbosti. SQL dotazy jsou poměrně jednoduché a snadno se slepují. Trocha práce navíc při návrhu se vyplatí. Pokud je potřebné přidat další atributy pro další typ zboží, přidá se tabulka.

[Josef Kufner]

Ruční údržba není nijak zvlášť náročná, pokud se držíš zavedených pravidel a nevymýšlíš blbosti. SQL dotazy jsou poměrně jednoduché a snadno se slepují. Trocha práce navíc při návrhu se vyplatí. Pokud je potřebné přidat další atributy pro další typ zboží, přidá se tabulka.

Právě proto, že to je celkem jednoduché, ale musí se držet pravidla, se vyplatí udělat tu zapouzdřující vrstvu nad tím. Šikovný query builder, trocha konfigurace, pěkné API a je na roky vystaráno.

[xkucf03]

To ale musím předem vědět, jaké skupiny atributů patří k jakým skupinám výrobků, ne?

[Kit]

Dá se to udělat i tak, že v každé pomocné tabulce je kromě cizího klíče jen jeden atribut. Taková pomocná tabulka má tedy jen 2 sloupce. Pokud něco hledám, provedu JOIN s tabulkou(-ami) s požadovaným typem atributu a za WHERE dám podmínky pro jeho hodnotu.

[xkucf03]

Tzn. ta možnost

Dynamicky generované tabulky – pro každý atribut jedna – opět jich můžou být tisíce nebo víc. V obou předchozích případech bude zase problém s prohledáváním vícenásobných atributů.

co jsem psal výš, ne? A vícenásobné atributy filtrovat pomocí HAVING count(*).

[Kit]

K čemu ten HAVING, když nám stačí WHERE?

[xkucf03]

Protože ten atribut může obsahovat víc hodnot. Buď je dáš do pole nebo z toho uděláš víc záznamů. Co se dá líp indexovat?

[Kit]

Atribut přece nemůže obsahovat víc hodnot, bylo by to porušením 1NF.

V daném případě většinou indexy nepotřebuješ - pouze pokud počet záznamů v pomocné tabulce překročí únosnou mez, např. 1000. V e-shopech tuto hodnotu pro jednu vlastnost většinou nepřekročíš.

Mám takové tušení, že mě zase tlačíš do EAV. Tak takhle ne. Jedna hodnota -> jeden atribut. Pokud potřebuješ vך×d, tak můžeš mít pomocnou tabulku "rozmer" se čtyřmi sloupci - cizím klíčem, výškou, šířkou a délkou.

[xkucf03]

A co když chci atribut popisující např. rozhraní? Jeden výrobek má VGA+HDMI+DVI a druhý má VGA+DP a třetí HDMI+DP a zákazník chce vyhledat výrobky s rozhraním VGA and (HDMI or DVI or DP), tak to najdu jak?

Jedna možnost je pole nebo bitová maska (tzn. uložit těch víc hodnot do jednoho sloupce) nebo mít pro každou hodnotu atributu jeden záznam v nějaké tabulce.

Pokud počet hodnot toho atributu byl malý a konečný, tak bychom mohli mít pro každou hodnotu boolovský sloupec.

[Kit]

Nejsprávnější by asi bylo mít v pomocné tabulce "rozhrani_video" sloupce vga, hdmi, dvi a dp. Hodnotou by bylo třeba číslo verze, počet rozhraní nebo null, pokud by tam toto rozhraní nebylo. Samotný typ boolean se do databáze moc nehodí - z mého pohledu je přežitkem z doby strukturovaného programování.

Mnohem lepší by bylo mít pomocné tabulky "vga", "hdmi", "dvi" a "dp" s náplní viz výše. Takový SELECT se pak dá napsat poměrně jednoduše i bez klauzulí WHERE či HAVING.

[xkucf03]

Samotný typ boolean se do databáze moc nehodí - z mého pohledu je přežitkem z doby strukturovaného programování.

Když odhlédneme od řešené úlohy: tohle bych v databázi modeloval spíš tak, že budu mít entitu výrobek, entitu rozhraní mezi nimi vazbu M:N, kde atributem té vazby může být násobnost (počet takových rozhraní) a verze by byla spíš atributem rozhraní. Ano, booleany tam potřeba nejsou, protože true/false je vyjádřeno existencí či neexistencí té vazby resp. záznamu ve vazební tabulce.

Mnohem lepší by bylo mít pomocné tabulky "vga", "hdmi", "dvi" a "dp" s náplní viz výše. Takový SELECT se pak dá napsat poměrně jednoduše i bez klauzulí WHERE či HAVING.

Problém je v tom, že atributů může být hodně a jejich hodnot ještě víc a můžou se relativně často měnit, což znamená nutnost DDL operací i v průběhu běžného používání systému. Představ si, že obchodník vyplní do formuláře detaily zboží a to vyústí ve vytváření nových tabulek a jejich plnění… to mi nepřijde jako úplně šťastné. Dalo by se to dělat asynchronně a přidat tam nějaké kontroly nebo schvalování, ale stejně mi to přijde takové zvláštní a nevím, jestli jsou na takovou dynamičnost a velké počty tabulek/sloupců databáze stavěné.

[Kit]

Představ si, že obchodník vyplní do formuláře detaily zboží a to vyústí ve vytváření nových tabulek a jejich plnění… to mi nepřijde jako úplně šťastné. Dalo by se to dělat asynchronně a přidat tam nějaké kontroly nebo schvalování, ale stejně mi to přijde takové zvláštní a nevím, jestli jsou na takovou dynamičnost a velké počty tabulek/sloupců databáze stavěné.

Databázím je tohle šumafuk, snad jen SQLite má omezení na 2^31 tabulek. Bolestivější bude spíš omezení JOINů na 64.

Na druhou stranu použití DDL za běhu obvykle ukazuje na chyby v návrhu a proto je zpravidla lepší se tomu vyhnout. Při použití vhodného prefixu názvu tabulky však ke kolizím nedojde - takovou tabulku bych obchodníkovi klidně dal na starost, pokud by aplikace generovala všechny potřebné DDL operace a byl k tomu vhodný frontend.

[Josef Kufner]

Tyto konektory jsou asi ten nejkomplikovanější případ, co může nastat. Řešení je několik, záleží dost na okolnostech. Jak už psal Kit, samostatné sloupečky s počtem konektorů jsou asi nejlepší, pokud se podle nich hodně filtruje. Ale znamená to hodně parametrů. Pokud však konektorů není moc, mohla by to být rozumná možnost.

Druhou možností je klasická M:N vazba na číselník. Není to moc pohodlné, ale je to více databázové.

[EtDirloth]

V postgrese by som ENUM urcite nepouzival na definiciu stlpcov - nanajvys na definiciu API (napr. ako typ parametru funkcie), ale aj na to by som musel mat dovod pouzit jeho specifika. Tazko sa menia, porovnavaju, sortuju, lokalizuju, mapuju na int, ... kazdemu s chutou na ENUM odporucam spravit si prototyp a trochu ho osahat.

Mam otazku: co bolo myslene tym SET a bitmapou? Z kontextu som vytusil, ze pojde o nejaky bit-field - mozno MySQL?

[Josef Kufner]

V MySQL je ENUM v podstatě jen INT převlečený za VARCHAR. Pokud mám sloupec, který obsahuje několik málo nelokalizovaných hodnot, například typ rozhranní, nebo tak něco, určitě to není nijak zlá volba. Ušetří to patlání se s číselníkem a odlehčí od jednoho joinu. Mapování na INT jde snadno přičtením nuly, opačný směr se provádí automaticky.

MySQL SET je ENUM, který může nabývat více hodnot.