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

včera 20:22 | Nová verze

Před měsícem byla vydána Fedora 27 ve dvou edicích: Workstation pro desktopové a Atomic pro cloudové nasazení. Fedora Server byl "vzhledem k náročnosti přechodu na modularitu" vydán pouze v betaverzi. Finální verze byla naplánována na leden 2018. Plán byl zrušen. Fedora 27 Server byl vydán již dnes. Jedná se ale o "klasický" server. Modularita se odkládá.

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

Lukáš Růžička v článku Kuchařka naší Růži aneb vaříme rychlou polévku z Beameru na MojeFedora.cz ukazuje "jak si rychle vytvořit prezentaci v LaTeXu, aniž bychom se přitom pouštěli do jeho bezedných hlubin".

Ladislav Hagara | Komentářů: 12
včera 07:22 | Komunita

Od 26. do 29. října proběhla v Bochumi European Coreboot Conference 2017 (ECC'17). Na programu této konference vývojářů a uživatelů corebootu, tj. svobodné náhrady proprietárních BIOSů, byla řada zajímavých přednášek. Jejich videozáznamy jsou postupně uvolňovány na YouTube.

Ladislav Hagara | Komentářů: 0
11.12. 19:22 | Nová verze

Ondřej Filip, výkonný ředitel sdružení CZ.NIC, oznámil vydání verze 2.0.0 open source routovacího démona BIRD (Wikipedie). Přehled novinek v diskusním listu a v aktualizované dokumentaci.

Ladislav Hagara | Komentářů: 0
11.12. 09:22 | Pozvánky

V Praze dnes probíhá Konference e-infrastruktury CESNET. Na programu je řada zajímavých přednášek. Sledovat je lze i online na stránce konference.

Ladislav Hagara | Komentářů: 2
9.12. 20:11 | Nová verze

Byl vydán Debian 9.3, tj. třetí opravná verze Debianu 9 s kódovým názvem Stretch a Debian 8.10, tj. desátá opravná verze Debianu 8 s kódovým názvem Jessie. Řešeny jsou především bezpečnostní problémy, ale také několik vážných chyb. Instalační média Debianu 9 a Debianu 8 lze samozřejmě nadále k instalaci používat. Po instalaci stačí systém aktualizovat.

Ladislav Hagara | Komentářů: 2
9.12. 00:44 | Nová verze

Po 6 měsících vývoje od vydání verze 0.13.0 byla vydána verze 0.14.0 správce balíčků GNU Guix a na něm postavené systémové distribuce GuixSD (Guix System Distribution). Na vývoji se podílelo 88 vývojářů. Přibylo 1 211 nových balíčků. Jejich aktuální počet je 6 668. Aktualizována byla také dokumentace.

Ladislav Hagara | Komentářů: 4
8.12. 21:33 | Nová verze

Po půl roce vývoje od vydání verze 5.9 byla vydána nová stabilní verze 5.10 toolkitu Qt. Přehled novinek na wiki stránce. Současně byla vydána nová verze 4.5.0 integrovaného vývojového prostředí (IDE) Qt Creator nebo verze 1.10 nástroje pro překlad a sestavení programů ze zdrojových kódů Qbs.

Ladislav Hagara | Komentářů: 0
7.12. 11:11 | Komunita

Naprostá většina příjmů Mozilly pochází od výchozích webových vyhledávačů ve Firefoxu. Do konce listopadu 2014 měla Mozilla globální smlouvu se společností Google. Následně bylo místo jedné globální smlouvy uzavřeno několik smluv s konkrétními vyhledávači pro jednotlivé země. V USA byla podepsána pětiletá smlouva s vyhledávačem Yahoo. Dle příspěvku na blogu Mozilly podala společnost Yahoo na Mozillu žalobu ohledně porušení této

… více »
Ladislav Hagara | Komentářů: 0
7.12. 05:55 | Zajímavý článek

V Londýně probíhá konference věnovaná počítačové bezpečnosti Black Hat Europe 2017. Průběžně jsou zveřejňovány prezentace. Videozáznamy budou na YouTube zveřejněny o několik měsíců. Zveřejněna byla například prezentace (pdf) k přednášce "Jak se nabourat do vypnutého počítače, a nebo jak v Intel Management Engine spustit vlastní nepodepsaný kód". Dle oznámení na Twitteru, aktualizace vydaná společností Intel nevylučuje možnost útoku.

Ladislav Hagara | Komentářů: 5
Jak se vás potenciálně dotkne trend odstraňování analogového audio konektoru typu 3,5mm jack z „chytrých telefonů“?
 (8%)
 (1%)
 (1%)
 (1%)
 (75%)
 (14%)
Celkem 963 hlasů
 Komentářů: 45, poslední 1.12. 19:00
    Rozcestník

    Dotaz: Výpočet hodnoty řazení u EAV modelu

    4.6.2011 02:13 jaws
    Výpočet hodnoty řazení u EAV modelu
    Přečteno: 514×
    Dobrý den, zkouším EAV modelování dat v mysql a řeším problém řazení dat.
    zjednodušeně:
    
    tabulka atributy (id, typ, nazev, id_hodnota)
    tabulka hodnota_int (id, hodnota)
    tabulka hodnota_varchar (id, hodnota)
    
    
    pokud bych to spojil, mohu dostat následující data:
    
    +-----------+------------------+--------------------+
    |  nazev    |   hodnota_int    |   hodnota_varchar  |
    +-----------+------------------+--------------------+
    | atribut1  |  233             | NULL               |
    | atribut4  | 2332             | NULL               |
    | atribut1  | NULL             | textova            |
    +-----------+------------------+--------------------+
    
    
    Je jasné, že pokud budu chtít řadit podle atributu atribut1, tak mám smůlu, protože je jednou typu int a jednou varchar. Řešení je ukládat si do tabulky atributy váhy jednotlivých hodnot řazení (přidat nový sloupec sort). Už jsem to v jednom schématu viděl, otázka je, jak tu hodnotu počítat? Není nějaký normalizovaný postup, pokud budu řadit najednou varchar, datetime, int a decimal?

    Odpovědi

    4.6.2011 09:05 Dejv | skóre: 37 | blog: Jak ten blog nazvat ... ? | Ostrava
    Rozbalit Rozbalit vše Re: Výpočet hodnoty řazení u EAV modelu

    Ahoj

    V teorii databazi se moc nevyznam, ale kdyz muze atribut byt jednou cislo a jindy retezec, tak je IMHO nekde neco spatne.

    A pokud ne, tak co neco takoveho:

    case atributy.typ
       when int      then convert(varchar...)
       when datetime then convert (varchar...)
       .
       .
       .
    
    Teda jestli to mysql umi :-)

    Dejv

    Pevne verim, ze zkusenejsi uzivatele me s mymi napady usmerni a poslou tam, kam tyto napady patri...
    4.6.2011 13:26 jaws
    Rozbalit Rozbalit vše Re: Výpočet hodnoty řazení u EAV modelu
    Myslím, že mysql tohle umí, ale cokoliv konvertovat v rámci dotazu je hodně pomalé, proto ta předpočítaná hodnota.
    4.6.2011 14:40 Dejv | skóre: 37 | blog: Jak ten blog nazvat ... ? | Ostrava
    Rozbalit Rozbalit vše Re: Výpočet hodnoty řazení u EAV modelu
    No tak pokud trvas na predpocitanem sloupci (IMHO lepsi by bylo zamerit se na to, aby atribut mel pokazde stejny typ hodnoty, ale neznam detaily a predpokladam, ze vis, co delas :-) ), tak vysledek toho case ... convert ukladat do toho sloupce. A razeni budes mit podle retezce. Taky to neni zrovna ukazka rychlosti, ale asi rychlejsi, nez convert
    Pevne verim, ze zkusenejsi uzivatele me s mymi napady usmerni a poslou tam, kam tyto napady patri...
    5.6.2011 00:47 jaws
    Rozbalit Rozbalit vše Re: Výpočet hodnoty řazení u EAV modelu
    No ono to právě není tak jednoduché. Takto bude třeba 096 větší než 94 atd. Proto ten nový sloupec sort, tam by se měla počítat hodnota, která to nějak "srovná".
    5.6.2011 16:46 Dejv | skóre: 37 | blog: Jak ten blog nazvat ... ? | Ostrava
    Rozbalit Rozbalit vše Re: Výpočet hodnoty řazení u EAV modelu

    bude třeba 096 větší než 94
    Nebude :-) 0 < 9 :-) Ale ja vim, cos chtel rict. Ano, ta metoda neni dokonala a mozna ani dobra. Ale jak jsem rekl hned v prvnim prispevku, v teorii se nevyznam, takze jedine, co jeste muzu, tak zopakovat, co uz jsem rikal:
    kdyz muze atribut byt jednou cislo a jindy retezec, tak je IMHO nekde neco spatne
    ale neznam detaily a predpokladam, ze vis, co delas

    Pevne verim, ze zkusenejsi uzivatele me s mymi napady usmerni a poslou tam, kam tyto napady patri...
    5.6.2011 16:52 kuka
    Rozbalit Rozbalit vše Re: Výpočet hodnoty řazení u EAV modelu
    Prilis jsem to nepochopil, v cem by ten postup mel byt normalizovany? Zadne obecne vhodne usporadani cisel a retezcu neexistuje, sam musis vedet, co do toho cekas a k cemu to ma slouzit.
    6.6.2011 22:51 jaws
    Rozbalit Rozbalit vše Re: Výpočet hodnoty řazení u EAV modelu
    Nečekám od toho nic, jen zkouším EAV modeling. Nicméně co je pro databázi vhodnější - velká řídká tabulka nebo spojování několika menších tabulek?
    +-----------+------------------+--------------------+
    |  nazev    |   hodnota_int    |   hodnota_varchar  |
    +-----------+------------------+--------------------+
    | atribut1  |  233             | NULL               |
    | atribut4  | 2332             | NULL               |
    | atribut1  | NULL             | textova            |
    +-----------+------------------+--------------------+
    
    
    
    nebo
    
    
    
    +-----------+------------------+
    |  nazev    |   hodnota_int    |
    +-----------+------------------+
    | atribut1  |  233             |
    | atribut4  | 2332             |
    +-----------+------------------+
    
    a 
    
    +-----------+--------------------+
    |  nazev    |   hodnota_varchar  |
    +-----------+--------------------+
    | atribut1  | textova            |
    +-----------+--------------------+
    
    které potom při dotazu spojuji?
    
    
    Pokud budu chtít použít nějaké vícenásobné where condition, tak stejně budu muset spojovat tabulku "samu do sebe", ale u řídké mi odpadne spojování na další vrstvě. Mě osobně připadá výhodnější ta řídká tabulka, ale zaráží mě, že jsem takové řešení u žádného EAV modelu neviděl. Nebo se ta data získávají přes UNION těch tabulek (tzn. mám pak sloupec s kombinací datových typů)?
    6.6.2011 23:20 kuka
    Rozbalit Rozbalit vše Re: Výpočet hodnoty řazení u EAV modelu
    Neda se rict, co je vhodnejsi "pro databazi". Podstatne je, jake se nad tim budou delat dotazy, jak casto, jake tam budou objemy dat atd. Velmi zjednodusene receno joiny byvaji vhodnejsi pro dotazy pres indexy, kdy se cte nekolik zaznamu, naopak nemusi byt vhodne pro dotazy pres velke mnoziny dat, napriklad v datovych skladech. Doporucuji ke zvazeni spolecnou reprezentaci hodnot (coz je typicky sloupec typu retezec) a rozliseni typu priznakovym sloupcem, to je jednoduchy a prehledny model, ktery pro radu pouziti staci.
    6.6.2011 23:35 jaws
    Rozbalit Rozbalit vše Re: Výpočet hodnoty řazení u EAV modelu
    Také jsem takové řešení viděl. Připadá mi ale, že bude dost pomalé pro nějaké operace nad daty. Např. budu chtít odečíst datumy, spočítat počty vteřin apod. což znamená, že musím textový sloupec nejprve konvertovat na příslušný typ.
    7.6.2011 01:24 jaws
    Rozbalit Rozbalit vše Re: Výpočet hodnoty řazení u EAV modelu
    Trochu jsem to promyslel a asi použiji model s tím společným hodnotovým typem. Podle mě by se na to hodil buď mysql typ text nebo blob (nepodléhají max. délce řádku). Neboť blob je čistě binární, nemohla by být případná konečná aplikace snadno přenositelná/nahraditelná, protože bych neznal znakovou sadu textů, proto bych zvolil text s nějakým indexem na prvních N znacích. Do toho pole mohu ukládat čísla s počátečními nulami, řetězce, datumy (měl by jít řadit i datum, pokud ho uložím ve standardním formátu od největší hodnoty k nejmenší tj RRRR-MM-DD). Dokonce tam mohu uložit i případný binární "objekt" jako base64 řetězec. Přijde mi lepší vytvářet base64 do text datového pole nežli nemít přesně definovanou znakovou sadu pro texty v blobu. Má tento můj návrh nějaký háček?
    7.6.2011 10:25 kuka
    Rozbalit Rozbalit vše Re: Výpočet hodnoty řazení u EAV modelu
    Pouzit BLOB jako "spolecny" typ je nesmysl. To slouceni ma smysl pro "podobne" hodnoty atributu, tedy napr. datum, cislo, kratsi retezec - pokud tam mas dlouhe texty nebo dokonce binarni objekty, tak by se mely ulozit jinak/jinam. Jaky by melo smysl prevadet treba obrazek do base64 a zpet, kdyz ho muzes ulozit rovnou jako obrazek? Razeni binarnich objektu v base64 rovnez postrada smysl.
    7.6.2011 10:11 kuka
    Rozbalit Rozbalit vše Re: Výpočet hodnoty řazení u EAV modelu
    Ziskani radku z tabulky je o nekolik radu nakladnejsi nez nejaky prevod retezec->cislo, tim bych se v tomto pripade opravdu nezabyval. Uskali muze predstavovat spis navrzeni indexu apod.
    7.6.2011 10:45 l0gik | skóre: 22
    Rozbalit Rozbalit vše Re: Výpočet hodnoty řazení u EAV modelu
    Získání jednoho řádku ano. U tisíce řádků, kde bude mít mysql nacachovanej dotaz už bych si tak jistej nebyl. Takže záleží na používání aplikace.

    V každym případě se mi zdá, že pokud bude jeden sloupec, do kterýho se to bude normalizovat dle datovýho typu, tak musí bejt někde napsaný, jak se kterej atribut normalizuje. V tu chvíli není problém mít tři tabulky a při čtení i zápisu se podle toho "někde napsaný" rozhodovat, odkud číst či zapisovat.
    Josef Kufner avatar 9.6.2011 21:46 Josef Kufner | skóre: 67
    Rozbalit Rozbalit vše Re: Výpočet hodnoty řazení u EAV modelu
    Doporučuu se EAV vyhnout. Párkrát už jsem to dělal a cokoliv s tím dělat je neskutečně pracné a komplikované.

    Pokud potřebuješ uživateli umožnit přidávat políčka, tak prostě udělej alter a přidej sloupec. Tedy ať ta aplikace vyrábí tabulky dle potřeby. Z pohledu relační algebry je to trošku hnusné řešení, ale prakticky je to velmi jednoduché a pohodlné.

    Ve stručnosti takto: V jedné tabulce budeš mít popisy všech vytvářených tabulek. Co řádek, to sloupec nějaké tabulky. Budou tam oprávnění, formátování, typ, komu to patří a tak...

    Ty vytvářené tabulky budou mít vždy nějaký prefix, aby to bylo odlišené od ostatních tabulek a budou mít vždy nějaké základní sloupečky – ID s primárním klíčem, mtime, ctime, owner a tak podobně. Ostatní sloupečky pak bude vyrábět uživatel podle svých potřeb. Samozřejmě pomocí nějakého připraveného rozhraní a bude mít k dispozici jen pár připravených alterů, kam aplikace jen doplní název tabulky a sloupečku.

    Tu tabulky s popisy sloupečků ani nepotřebuješ, protože vše podstatné si ukládá databáze sama (prostě si necháš popsat strukturu té které tabulky). Na něco by se dalo znásilnit políčko pro komentáře, ale to je tak na uložení si logického typu sloupce (na odlišení e-mailu a jména, i když obojí bude varchar).

    Vyhledávání v datech bude mnohem rychlejší, bude jednoduché to indexovat, generování selectů bude hračka...
    Hello world ! Segmentation fault (core dumped)
    10.6.2011 00:42 jaws
    Rozbalit Rozbalit vše Re: Výpočet hodnoty řazení u EAV modelu
    Také mi to připadá bez eav jednodušší, nevýhodou je ale redundance dat. EAV jsem zvolil z toho důvodu, že u každého uživatele velice kolísá počet atributů, proto při standardním návrhu by byla tabulka, ve které by bylo hodně sloupců vlastně NULL. A protože některé atributy se mohou opakovat, vznikla by v tabulce redundance (což nijak zásadně nevadí) nebo bych to musel rozložit (čímž by vznikla větší zátěž při spojování). O kolik je EAV v praxi pomalejší než standardní "plochý" návrh?
    10.6.2011 10:12 kuka
    Rozbalit Rozbalit vše Re: Výpočet hodnoty řazení u EAV modelu
    To je nesmyslná otázka. O jakou jde praxi? Lze porovnat dva konkrétní modely, zda v jednom bude určitý typ dotazů výkonnější, obecně se ale pochopitelně vyjádřit nedá.

    V některých případech je EAV jistě pomalejší, proto se také obvykle dělají sloupce pro atributy v tabulkách a ne místo toho jedna obří tabulka, ve které by byla celá databáze. Pro jiná použití je naopka EAV vhodné především pro svoji pružnost z hlediska modifikace množiny atributů a vhodnou reprezenatci řídkých výskytů atributů. Někdo radil řešit to přidáváním sloupců do tabulek - to je ovšem v enterprise řešeních obvykle nepřípustné, takové operace např. nejsou součástí transakcí apod. Samozřejmě jestliže se atributy přidávají jednou ročně na centrální úrovni, tak proč ne, vždy to závisí na charakteru řešeného problému.
    10.6.2011 14:57 jaws
    Rozbalit Rozbalit vše Re: Výpočet hodnoty řazení u EAV modelu
    Atributy se budou přidávat cca 1 za 3 roky, jinak se jedná o víceméně statické schéma. Jediná věc co mi vadí na standardním řešení je to zasahování do schématu db (i když se to dá realizovat jen přidáváním tabulek a spojováním).
    10.6.2011 15:33 kuka
    Rozbalit Rozbalit vše Re: Výpočet hodnoty řazení u EAV modelu
    To samozrejme vadit muze a byva to silny argument pro pouziti EAV. Napr. trivialni dotaz na vsechny atributy bude ale v EAV asi vzdy pomalejsi. Otazka je kolik tam bude dat, jake maji vlastnosti a zda jsou nektere atributy vyznamnejsi. Napriklad pokud by nektere atributy byly dimenzemi, ktere maji vsechny nebo vetsina entit, a pres ktere se filtruje skoro vzdy, tak pri reprezentaci ve sloupcich lze pouzivat specificke indexacni strategie (treba bitmapove indexy) pro ruzne kategorie dotazu a vykon bude jiste lepsi. Napriklad v e-shopu je z hlediska filtrace dat jiste dulezitejsi datum objednavky nez vzkaz obchodnkovi apod. Takove atributy bych se snazil reprezentovat primo v tabulce, coz nevylucuje pouziti EAV (a jeho vyhod) pro jine atributy. Pomoci view lze i na takovy "hybridni" model poskytovat pohledy ve stylu "cisteho" EAV modelu, pokud jsou potreba napriklad pro jiz hotove zobrazovaci frameworky.
    10.6.2011 16:41 l0gik | skóre: 22
    Rozbalit Rozbalit vše Re: Výpočet hodnoty řazení u EAV modelu
    Pokud se to děje takhle zřídka, tak bych se nebál zásahu do struktury db a na EAV like schémata bych se vykašlal. Vyjmenovávání sloupců při insertu je snad samozřejmostí a jinak nevím, čemu by to mělo vadit.
    Josef Kufner avatar 10.6.2011 18:33 Josef Kufner | skóre: 67
    Rozbalit Rozbalit vše Re: Výpočet hodnoty řazení u EAV modelu
    Toho zásahu do struktury se neboj. Jen přesně definuj co a kde se může měnit, ať to je pod kontrolou.
    Hello world ! Segmentation fault (core dumped)
    10.6.2011 08:54 aa
    Rozbalit Rozbalit vše Re: Výpočet hodnoty řazení u EAV modelu
    Vyhledávání v datech bude mnohem rychlejší
    Pro řídké tabulky bych si tím nebyl tak jistý. Tam bych volil spíš sloupec s XML.

    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.