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 01:00 | Nová verze

Byla vydána verze 1.27 programovacího jazyka Rust (Wikipedie). Z novinek je nutno zmínit podporu SIMD (Single Instruction Multiple Data). Podrobnosti v poznámkách k vydání. Vyzkoušet Rust lze například na stránce Rust by Example.

Ladislav Hagara | Komentářů: 0
včera 16:22 | IT novinky

CEO Intelu Brian Krzanich rezignoval (tisková zpráva). Oficiálním důvodem je "vztah na pracovišti". S okamžitou platností se dočasným CEO stal Robert Swan.

Ladislav Hagara | Komentářů: 20
včera 14:11 | Komunita

Konsorcium Linux Foundation ve spolupráci s kariérním portálem Dice.com zveřejnilo 2018 Open Source Jobs Report. Poptávka po odbornících na open source neustále roste.

Ladislav Hagara | Komentářů: 1
včera 12:44 | Zajímavý článek

Na stránkách linuxové distribuce Ubuntu Studio byla publikována příručka Ubuntu Studio Audio Handbook věnována vytváření, nahrávaní a úpravě zvuků a hudby nejenom v Ubuntu Studiu. Jedná se o živý dokument editovatelný na jejich wiki.

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

Společnost Red Hat koupila na konci ledna společnost CoreOS stojící mimo jiné za odlehčenou linuxovou distribucí optimalizovanou pro běh kontejnerů Container Linux. Matthew Miller, vedoucí projektu Fedora, představil v článku na Fedora Magazine nový podprojekt Fedory s názvem Fedora CoreOS. Fedora CoreOS má být to nejlepší z Container Linuxu a Fedora Atomic Hostu. Podrobnosti v často kladených otázkách (FAQ) a v diskusním fóru.

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

Po více než devíti měsících vývoje od vydání verze 11.0 byla vydána verze 12.0 zvukového serveru PulseAudio. Přehled novinek v poznámkách k vydání.

Ladislav Hagara | Komentářů: 10
20.6. 20:00 | Upozornění

Výbor pro právní záležitosti Evropského parlamentu (JURI) dnes přijal své stanovisko ke kontroverzní novele směrnice, která v EU upravuje autorské právo v online prostředí (Pro: 14, Proti: 9, Zdrželo se: 2). Další kolo legislativního procesu proběhne na začátku července.

Ladislav Hagara | Komentářů: 30
19.6. 19:55 | Zajímavý článek

Byly zveřejněny (pdf) podrobnosti o kritické bezpečnostní chybě CVE-2017-12542 v HPE iLO 4 (Integrated Lights-Out), tj. v proprietárním řešení společnosti Hewlett Packard Enterprise pro vzdálenou správu jejich serverů. Bezpečnostní chyba zneužitelná k obejití autentizace a k vzdálenému spuštění libovolného kódu byla opravena již v květnu loňského roku ve verzi 2.53.

Ladislav Hagara | Komentářů: 19
19.6. 17:55 | Zajímavý projekt

CSIRT.CZ informuje o CTF (Capture the Flag) platformě ZSIS CTF s úlohami pro procvičování praktických dovedností z oblasti kybernetické bezpečnosti a upozorňuje na soutěž Google Capture the Flag 2018, kde je možné vyhrát zajímavé ceny.

Ladislav Hagara | Komentářů: 0
19.6. 17:00 | Komunita

Byly zveřejněny prezentace a videozáznamy přednášek z prvního československého setkání síťových operátorů CSNOG konaného 11. a 12. června v Brně a semináře IPv6 2018 uskutečněného 6. června v Praze.

Ladislav Hagara | Komentářů: 0
Jak čtete delší texty z webových stránek?
 (77%)
 (23%)
 (4%)
 (7%)
 (3%)
 (11%)
Celkem 237 hlasů
 Komentářů: 39, poslední včera 17:44
    Rozcestník

    Dotaz: Textové soubory do relační databáze - struktura db

    10.1.2011 16:03 4rasic
    Textové soubory do relační databáze - struktura db
    Přečteno: 535×
    Dobrý den. Mám několik desítek textových souborů, které obsahují až statisíce řádků. Jejich struktura je zhruba následující:
    soubor0:
    jednoznackyidentifikator | boolhodnota | stringhodnota | ...
    
    souborN:
    jednoznackyidentifikator | nejakadalsihodnota | zaseneco | ...
    
    ...
    
    Potřebuju data z těchto souborů dostat do DB. Můj plán je následující: pro každý soubor vytvářet automaticky tabulku, jejíž název bude sha1 hash názvu souboru (kvůli rozlišování písmen, nepovoleným znakům aj.), v každé tabulce bude jednoznackyidentifikator PK. Někde stranou si budu v aplikaci udržovat seznam názvů souborů, které chci procházet (nemusím chtít všechny). Takový je můj plán. V nespočetně mnoha článcích jsem se ale dočetl, že není dobré měnit strukturu databáze (vytvářet tabulky) dynamicky a dost se od toho odrazuje. Tzn. že by byla lepší jedna tabulka, ve které by byla data ze všech souborů? Není to blbost?

    Odpovědi

    okbob avatar 10.1.2011 16:19 okbob | skóre: 30 | blog: systemakuv_blog | Benešov
    Rozbalit Rozbalit vše Re: Textové soubory do relační databáze - struktura db
    Ono hodně záleží, co s těmi daty chcete dělat a jak je chcete zpracovávat? Jestli je nejakým způsobem významné, z kterého souboru data pochází? Jestli chcete provádět jednorázovou operaci nebo zda-li s daty chcete pracovat trvale? A také záleží, co vlastně tato data znamenají.

    Jinak 100 tis nebo mil, přip. 10 mil řádků v jedné tabulce není problém.
    10.1.2011 16:38 4rasic
    Rozbalit Rozbalit vše Re: Textové soubory do relační databáze - struktura db
    Chci třeba zobrazit "naráz"(nějak filtrovaná) všechna data z 4 souborů - řádky spojené pomocí jednoznackyidentifikator. Na to se právě perfektně hodí mít více tabulek a nad nima hodit inner join. Myslím, že toto samé se dá provést i pokud by to bylo v jedné tabulce (jen postup získání dat je složitější).
    okbob avatar 10.1.2011 19:13 okbob | skóre: 30 | blog: systemakuv_blog | Benešov
    Rozbalit Rozbalit vše Re: Textové soubory do relační databáze - struktura db
    Pokud ta data ze souborů jsou skutečně natolik jiná, že byste je chtěl spíš JOINovat než UNIONovat :), tak pak asi má smysl je nechat v samostatných tabulkách.
    11.1.2011 00:35 4rasic
    Rozbalit Rozbalit vše Re: Textové soubory do relační databáze - struktura db
    Tuhle odpověď jsem tak uplně nepochopil, ale mám asi 2 možnosti realizace:
    1/ vícero tabulkami
    
    soubor0:
    identifikator | sloupec1 | sloupec2
    -----------------------------------
    fasd8fSDd6    | 0        | retezec
    
    
    soubor1:
    identifikator | sloupec1 | sloupec2
    -----------------------------------
    fasd8fSDd6    | false    | -51
    
    
    ... a pak join using identifikator ... moznost where, order ...
    
    
    2/ jednou tabulkou
    
    soubor  | identifikator | sloupec  | hodnota_bool | hodnota_varchar | hodnota_int
    ---------------------------------------------------------------------------------
    soubor0 | fasd8fSDd6    | sloupec1 | NULL         | NULL            | 0
    soubor0 | fasd8fSDd6    | sloupec2 | NULL         | retezec         | NULL
    soubor1 | fasd8fSDd6    | sloupec1 | false        | NULL            | NULL
    soubor1 | fasd8fSDd6    | sloupec2 | NULL         | NULL            | -51
    
    tady nevim, jaky dotaz pouzit?
    
    Nemůžu se zbavit dojmu, že za 2/ je takové čistější, ale asi také o dost pomalejší (??).
    okbob avatar 11.1.2011 06:34 okbob | skóre: 30 | blog: systemakuv_blog | Benešov
    Rozbalit Rozbalit vše Re: Textové soubory do relační databáze - struktura db
    Takhle od stolu se nedá říci, které řešení je výhodnější - vyzkoušejte si rychlost nejčastějších dotazů a pohodlí sestavovaní dotazů. Vaše druhá varianta je analogií materializace. Což někdy je výhodné, a někdy ne. Záleží na přístupu. Pokud bych měl hodně souborů tak bych inklinoval spíš k jedné nebo dvoum tabulkám. S málem souborů můžete mít tabulky per soubor.
    11.1.2011 08:15 4rasic
    Rozbalit Rozbalit vše Re: Textové soubory do relační databáze - struktura db
    No těch "spolusouvisejících" souborů bude okolo 10. Maximálně tak 100. On asi také není zanedbatelný čas pro samotné spojování několika statisíce řádkových tabulek že? V té dvojce maximálně spojím tabulky 2 (pokud to budu mít v 3NF). U té 2/ varianty jsou ale zase "nevyužité sloupce" (NULL). Kolik času navíc zabere procházení takových sloupců, pokud bych podle nich chtěl třeba hledat? V těch záznamech se také bude často hledat pomocí LIKE '%neco%'.
    okbob avatar 11.1.2011 12:50 okbob | skóre: 30 | blog: systemakuv_blog | Benešov
    Rozbalit Rozbalit vše Re: Textové soubory do relační databáze - struktura db
    to spojeni tabulek je pomerne zanedbatelne relativne ku cteni dat z disku. Zjednodusene - db dotazy jsou tim pomalejsi cim vic ctete data, ktera vas v tu chvili nezajimaji. NULL znamena +/- 1 bit - zalezi na db a typu. To ze budete vyhledavat skrz LIKE znamena, ze se Vam nebudou chytat indexy. Coz by vedlo na oddelene tabulky. Zase, pri deseti tabulkach je to ok, ale pri 100 tabulkach se budete proklinat, az budete psat dotazy. Ja bych zkusil nahnacat do jedne, dvou tabulek, vygeneroval si testovaci data, a pak si vyzkousel, jak dlouho trvaji dotazy.
    11.1.2011 16:05 4rasic
    Rozbalit Rozbalit vše Re: Textové soubory do relační databáze - struktura db
    Tak já přímo dotazy psát nebudu, to si naprogramuju a bude se to generovat automaticky, takže je mi jedno jestli ten dotaz bude mít 10M. Teď jsem si jen tak letmo zkusil v mysql (pak asi použiju firebird nebo postgres, ale to je teď jedno) vygenerovat 450000 řádkovou tabulku + 70000 řádkovou tabulku. Pokud hledám jen v té větší tabulce, zabere to při použití like 0.0684s, po spojení left joinem (uvědomil jsem si, že inner join je blbost, protože budu chtít vidět "všechna" data - v závislosti na konkrétní tabulce) nad oběma 0.0849s. Pokud zdvojnásobím počty řádků v tabulkách, tak časy jsou pak několikanásobně větší. Tzn. že pokud spojím 3 2sloupcové tabulky s počtem řádků 1 000 000 left joinem, budu mít maximálně 1 000 000 řádků po spojení. V případě 1 tabulky jich bude 3 * 2 * 1 000 000 a to pak bude trvat hoodně dlouho než se to projde. Mimochodem kdybych měl 1 tabulku - jakým způsobem bych v ní hledal? Jak by vypadal pro jednotabulkovou variantu tento dotaz?:
    select identifikator from soubor1 where (sloupec1 = 'neco' AND sloupec2 = 'necojine') OR sloupec2 = 'necojine2' order by sloupec1, sloupec2 desc limit 300 offset 2;
    
    To je jeden z typických dotazů nad daty a teď si neumím představit variantu pro jedno(dvou)tabulkové řešení. Asi tam budou nějaké vnořené dotazy a nějaký union, ale sql tak dobře neznám.
    11.1.2011 19:48 jk
    Rozbalit Rozbalit vše Re: Textové soubory do relační databáze - struktura db
    tak u toho prikladu bych vam radil, at na to nejdete s sqlite.

    Zrovna su hraju v sqlite s jednou tabulkou, ktera ma 3 miliony radku jakmile reknu order by pole1,pole2 desc, tak trva dotaz 4 minuty, vzestupne 4 vteriny. A to mam slozeny index na tech polich pole1, pole2.

    Kdyz pouziji pouze order by pole1 desc, tak to jde take okamzite.
    11.1.2011 20:43 jekub
    Rozbalit Rozbalit vše Re: Textové soubory do relační databáze - struktura db
    a udelat index pole1, pole2 desc nepomuze?

    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.