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í
×

dnes 20:55 | Nová verze

Byla vydána verze 2017.3 dnes již průběžně aktualizované linuxové distribuce navržené pro digitální forenzní analýzu a penetrační testování Kali Linux. Aktualizovat systém lze pomocí příkazů "apt update; apt dist-upgrade; reboot". Z novinek lze zmínit 4 nové nástroje: InSpy, CherryTree, Sublist3r a OSRFramework.

Ladislav Hagara | Komentářů: 0
dnes 01:55 | Bezpečnostní upozornění

Společnost Uber potvrdila bezpečnostní incident a únik dat v roce 2016. Unikly údaje o 57 milionech cestujících (jména, emailové adresy a čísla mobilních telefonů) a 600 tisících řidičích (navíc čísla řidičských průkazů).

Ladislav Hagara | Komentářů: 1
včera 23:44 | Humor

Co vypíše příkaz man půl hodiny po půlnoci? Text "gimme gimme gimme". Jedná se o virtuální velikonoční vajíčko připomínající skupinu ABBA a její hit Gimme! Gimme! Gimme! (A Man After Midnight). Problém nastane, pokud gimme gimme gimme nabourá automatizované testování softwaru. To se pak příkaz man musí opravit [Bug 1515352] [reddit].

Ladislav Hagara | Komentářů: 10
včera 18:11 | Zajímavý článek

Mozilla.cz informuje, že Firefox na Fedoře podporuje Client Side Decorations. Firefox na Linuxu se vykresluje včetně standardního záhlaví okna, které je v případě webového prohlížeče většinou nadbytečné a ubírá drahocenné vertikální místo na obrazovce. Verze distribuovaná uživatelům Fedory však nyní obsahuje experimentální podporu pro takzvané Client Side Decorations, které umožňují vykreslování „oušek“ panelů do záhlaví okna.

Ladislav Hagara | Komentářů: 12
včera 05:00 | Bezpečnostní upozornění

Maxim Goryachy a Mark Ermolov ze společnosti Positive Technologies budou mít v prosinci na konferenci Black Hat Europe 2017 přednášku s názvem "Jak se nabourat do vypnutého počítače, a nebo jak v Intel Management Engine spustit vlastní nepodepsaný kód". O nalezeném bezpečnostním problému informovali společnost Intel. Ta bezpečnostní problém INTEL-SA-00086 v Intel Management Engine (ME), Intel Server Platform Services (SPS) a Intel

… více »
Ladislav Hagara | Komentářů: 36
včera 01:33 | Zajímavý projekt

Na Humble Bundle byla spuštěna akce Humble Book Bundle: Java. Za 1 dolar a více lze koupit 5 elektronických knih, za 8 dolarů a více 10 elektronických knih a za 15 dolarů a více 15 elektronických knih věnovaných programovacímu jazyku Java od nakladatelství O'Reilly. Peníze lze libovolně rozdělit mezi nakladatelství O'Reilly, neziskovou organizaci Code for America a Humble Bundle.

Ladislav Hagara | Komentářů: 0
včera 00:11 | Zajímavý projekt

Článek na OMG! Ubuntu! představuje rodinu písma IBM Plex. Jedná se o open source písmo (GitHub) navržené a uvolněné společností IBM (YouTube, Carbon Design System). Ukázka na Font Squirrel.

Ladislav Hagara | Komentářů: 12
20.11. 23:22 | Komunita

Na Humble Bundle lze získat počítačovou hru Brütal Legend (Wikipedie, YouTube) běžící také v Linuxu zdarma. Speciální akce končí ve středu v 19:00.

Ladislav Hagara | Komentářů: 0
20.11. 06:00 | Zajímavý článek

USA Network vysílá již třetí sérii seriálu Mr. Robot (Wikipedie, ČSFD.cz). Ryan Kazanciyan, technický konzultant seriálu, se na Medium v sérii článků Mr. Robot Disassembled věnuje jednotlivým dílům a popisuje použité nástroje a postupy.

Ladislav Hagara | Komentářů: 2
19.11. 23:55 | IT novinky

Společnost StartCom oficiálně oznámila, že jako certifikační autorita končí. Od 1. ledna 2018 přestane vydávat nové certifikáty a následující 2 roky bude poskytovat OCSP a CRL. Počátkem roku 2020 budou všechny platné certifikáty zneplatněny.

Ladislav Hagara | Komentářů: 63
Jak se vás potenciálně dotkne trend odstraňování analogového audio konektoru typu 3,5mm jack z „chytrých telefonů“?
 (9%)
 (1%)
 (1%)
 (1%)
 (75%)
 (14%)
Celkem 749 hlasů
 Komentářů: 37, poslední včera 15:21
    Rozcestník

    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: 1443×
    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: 39 | 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: 39 | 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: 46 | 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: 46 | 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: 46 | 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: 46 | 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: 46 | 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: 4
    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: 46 | 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: 67
    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: 39 | 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: 67
    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: 46 | 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: 39 | 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: 46 | 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: 39 | 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: 46 | 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: 39 | 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: 46 | 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: 39 | 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: 46 | 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: 39 | 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: 67
    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: 4
    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: 67
    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.