abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
eParkomat, startup z ČR, postoupil mezi finalisty evropského akcelerátoru ChallengeUp!
Robot na pivo mu otevřel dveře k opravdovému byznysu
Internet věcí: Propojený svět? Už se to blíží...
dnes 06:00 | Komunita

Na YouTube byl publikován Blender Institute Reel 2016, ani ne dvouminutový sestřih z filmů, které vznikly za posledních 10 let díky Blender Institutu. V institutu aktuálně pracují na novém filmu Agent 327. Dění kolem filmu lze sledovat na Blender Cloudu. Videoukázka Agenta 327 z června letošního roku na YouTube.

Ladislav Hagara | Komentářů: 0
dnes 01:02 | Zajímavý článek

Minulý týden byly vydány verze 1.2.3 a 1.1.7 webového poštovního klienta Roundcube. V oznámení o vydání bylo zmíněno řešení bezpečnostního problému nalezeného společností RIPS a souvisejícího s voláním funkce mail() v PHP. Tento týden byly zveřejněny podrobnosti. Útočník mohl pomocí speciálně připraveného emailu spustit na serveru libovolný příkaz. Stejně, jak je popsáno v článku Exploit PHP’s mail() to get remote code execution z roku 2014.

Ladislav Hagara | Komentářů: 0
včera 16:00 | Nová verze

Byla vydána verze 0.98 svobodného nelineárního video editoru Pitivi. Z novinek lze zmínit například přizpůsobitelné klávesové zkratky. Videoukázka práce s nejnovější verzí Pitivi na YouTube.

Ladislav Hagara | Komentářů: 1
včera 15:00 | Zajímavý software

Stop motion je technika animace, při níž je reálný objekt mezi jednotlivými snímky ručně upravován a posouván o malé úseky, tak aby po spojení vyvolala animace dojem spojitosti. Jaký software lze pro stop motion použít na Linuxu? Článek na OMG! Ubuntu! představuje Heron Animation. Ten bohužel podporuje pouze webové kamery. Podpora digitálních zrcadlovek je začleněna například v programu qStopMotion.

Ladislav Hagara | Komentářů: 3
7.12. 21:21 | Nová verze Ladislav Hagara | Komentářů: 0
7.12. 11:44 | Zajímavý projekt

Na Indiegogo byla spuštěna kampaň na podporu herní mini konzole a multimediálního centra RetroEngine Sigma od Doyodo. Předobjednat ji lze již od 49 dolarů. Požadovaná částka 20 000 dolarů byla překonána již 6 krát. Majitelé mini konzole si budou moci zahrát hry pro Atari VCS 2600, Sega Genesis nebo NES. Předinstalováno bude multimediální centrum Kodi.

Ladislav Hagara | Komentářů: 2
7.12. 00:10 | Nová verze

Byla vydána verze 4.7 redakčního systému WordPress. Kódové označením Vaughan bylo vybráno na počest americké jazzové zpěvačky Sarah "Sassy" Vaughan. Z novinek lze zmínit například novou výchozí šablonu Twenty Seventeen, náhledy pdf souborů nebo WordPress REST API.

Ladislav Hagara | Komentářů: 10
6.12. 12:00 | Zajímavý projekt

Projekt Termbox umožňuje vyzkoušet si linuxové distribuce Ubuntu, Debian, Fedora, CentOS a Arch Linux ve webovém prohlížeči. Řešení je postaveno na projektu HyperContainer. Podrobnosti v často kladených dotazech (FAQ). Zdrojové kódy jsou k dispozici na GitHubu [reddit].

Ladislav Hagara | Komentářů: 27
6.12. 11:00 | Bezpečnostní upozornění

Byly zveřejněny informace o bezpečnostní chybě CVE-2016-8655 v Linuxu zneužitelné k lokální eskalaci práv. Chyba se dostala do linuxového jádra v srpnu 2011. V upstreamu byla opravena minulý týden [Hacker News].

Ladislav Hagara | Komentářů: 2
5.12. 22:00 | Komunita

Přibližně před měsícem bylo oznámeno, že linuxová distribuce SUSE Linux Enterprise Server (SLES) běží nově také Raspberry Pi 3 (dokumentace). Obraz verze 12 SP2 pro Raspberry Pi 3 je ke stažení zdarma. Pro registrované jsou po dobu jednoho roku zdarma také aktualizace. Dnes bylo oznámeno, že pro Raspberry Pi 3 je k dispozici také nové openSUSE Leap 42.2 (zprávička). K dispozici je hned několik obrazů.

Ladislav Hagara | Komentářů: 6
Kolik máte dat ve svém domovském adresáři na svém primárním osobním počítači?
 (32%)
 (24%)
 (29%)
 (8%)
 (5%)
 (3%)
Celkem 799 hlasů
 Komentářů: 50, poslední 29.11. 15:50
Rozcestník
Reklama

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

6.9.2015 01:22 what
Databázové schéma pro mnoho vícehodnotových atributů
Přečteno: 1417×
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

6.9.2015 02:01 Kit | skóre: 37 | Brno
Rozbalit Rozbalit vše Re: Jak správně navrhnout databázové schéma pro mnoho vícehodnotových atributů?
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ů.
Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
6.9.2015 14:06 what
Rozbalit Rozbalit vše Re: Jak správně navrhnout databázové schéma pro mnoho vícehodnotových atributů?
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?

6.9.2015 14:46 Kit | skóre: 37 | Brno
Rozbalit Rozbalit vše Re: Jak správně navrhnout databázové schéma pro mnoho vícehodnotových atributů?
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í.

Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
xkucf03 avatar 6.9.2015 14:58 xkucf03 | skóre: 45 | blog: xkucf03
Rozbalit Rozbalit vše EAV

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.

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Nekuřák.net
okbob avatar 6.9.2015 15:49 okbob | skóre: 30 | blog: systemakuv_blog | Benešov
Rozbalit Rozbalit vše Re: EAV
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 avatar 6.9.2015 16:18 xkucf03 | skóre: 45 | blog: xkucf03
Rozbalit Rozbalit vše Re: EAV vs. XML a XPath

Rekonstrukce entity z EAV je jeden dotaz:

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

Tím mám všechny atributy dané entity1 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

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Nekuřák.net
okbob avatar 6.9.2015 17:07 okbob | skóre: 30 | blog: systemakuv_blog | Benešov
Rozbalit Rozbalit vše Re: EAV vs. XML a XPath
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 avatar 6.9.2015 17:16 xkucf03 | skóre: 45 | blog: xkucf03
Rozbalit Rozbalit vše Re: EAV vs. XML a XPath
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í.

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Nekuřák.net
okbob avatar 6.9.2015 17:39 okbob | skóre: 30 | blog: systemakuv_blog | Benešov
Rozbalit Rozbalit vše Re: EAV vs. XML a XPath
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 avatar 6.9.2015 17:53 okbob | skóre: 30 | blog: systemakuv_blog | Benešov
Rozbalit Rozbalit vše Re: EAV vs. XML a XPath
xkucf03 avatar 6.9.2015 16:39 xkucf03 | skóre: 45 | blog: xkucf03
Rozbalit Rozbalit vše XPath indexy

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)

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Nekuřák.net
okbob avatar 6.9.2015 17:24 okbob | skóre: 30 | blog: systemakuv_blog | Benešov
Rozbalit Rozbalit vše Re: XPath indexy
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 avatar 6.9.2015 14:51 xkucf03 | skóre: 45 | blog: xkucf03
Rozbalit Rozbalit vše Datový model pro atributy produktů

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ě bude1, 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

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Nekuřák.net
6.9.2015 22:39 EtDirloth | skóre: 2
Rozbalit Rozbalit vše Re: Datový model pro atributy produktů
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 avatar 6.9.2015 23:48 xkucf03 | skóre: 45 | blog: xkucf03
Rozbalit Rozbalit vše Anchor Modeling

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

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Nekuřák.net
Josef Kufner avatar 12.9.2015 14:25 Josef Kufner | skóre: 66
Rozbalit Rozbalit vše Re: Datový model pro atributy produktů
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.
Hello world ! Segmentation fault (core dumped)
12.9.2015 15:00 Kit | skóre: 37 | Brno
Rozbalit Rozbalit vše Re: Datový model pro atributy produktů
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.
Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
Josef Kufner avatar 12.9.2015 19:41 Josef Kufner | skóre: 66
Rozbalit Rozbalit vše Re: Datový model pro atributy produktů
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.
Hello world ! Segmentation fault (core dumped)
xkucf03 avatar 12.9.2015 15:07 xkucf03 | skóre: 45 | blog: xkucf03
Rozbalit Rozbalit vše Re: Datový model pro atributy produktů

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

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Nekuřák.net
12.9.2015 15:51 Kit | skóre: 37 | Brno
Rozbalit Rozbalit vše Re: Datový model pro atributy produktů
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.
Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
xkucf03 avatar 12.9.2015 16:09 xkucf03 | skóre: 45 | blog: xkucf03
Rozbalit Rozbalit vše Re: Datový model pro atributy produktů

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(*).

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Nekuřák.net
12.9.2015 16:21 Kit | skóre: 37 | Brno
Rozbalit Rozbalit vše Re: Datový model pro atributy produktů
K čemu ten HAVING, když nám stačí WHERE?
Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
xkucf03 avatar 12.9.2015 17:26 xkucf03 | skóre: 45 | blog: xkucf03
Rozbalit Rozbalit vše Vícenásobné atributy a indexování – HAVING vs. pole

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?

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Nekuřák.net
12.9.2015 17:48 Kit | skóre: 37 | Brno
Rozbalit Rozbalit vše Re: Vícenásobné atributy a indexování – HAVING vs. pole
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.
Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
xkucf03 avatar 12.9.2015 18:00 xkucf03 | skóre: 45 | blog: xkucf03
Rozbalit Rozbalit vše Re: Vícenásobné atributy a indexování – HAVING vs. pole

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.

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Nekuřák.net
12.9.2015 19:03 Kit | skóre: 37 | Brno
Rozbalit Rozbalit vše Re: Vícenásobné atributy a indexování – HAVING vs. pole
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.
Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
xkucf03 avatar 12.9.2015 20:22 xkucf03 | skóre: 45 | blog: xkucf03
Rozbalit Rozbalit vše Re: Vícenásobné atributy a indexování – HAVING vs. pole
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é.

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Nekuřák.net
12.9.2015 22:22 Kit | skóre: 37 | Brno
Rozbalit Rozbalit vše Re: Vícenásobné atributy a indexování – HAVING vs. pole
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.
Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
Josef Kufner avatar 12.9.2015 19:48 Josef Kufner | skóre: 66
Rozbalit Rozbalit vše Re: Vícenásobné atributy a indexování – HAVING vs. pole
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é.
Hello world ! Segmentation fault (core dumped)
15.9.2015 23:06 EtDirloth | skóre: 2
Rozbalit Rozbalit vše Re: Datový model pro atributy produktů
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 avatar 16.9.2015 00:07 Josef Kufner | skóre: 66
Rozbalit Rozbalit vše Re: Datový model pro atributy produktů
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.
Hello world ! Segmentation fault (core dumped)

Založit nové vláknoNahoru

Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

ISSN 1214-1267   www.czech-server.cz
© 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.