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 13:22 | Zajímavý software

Microsoft na svém blogu oznámil, že správce knihoven pro C++ Vcpkg (VC++ Packaging Tool) lze nově používat také na Linuxu a macOS. Aktuálně je pro Linux k dispozici více než 350 knihoven [reddit].

Ladislav Hagara | Komentářů: 0
dnes 12:44 | Komunita

Byly zveřejněny exploity na Nintendo Switch a platformu Tegra X1: Fusée Gelée a ShofEL2. Jejich zneužití nelze zabránit softwarovou aktualizací. Na druhou stranu exploity umožní na Nintendo Switch snadno a rychle nainstalovat Linux, viz. ukázka na YouTube. Jenom je potřeba sáhnout na hardware.

Ladislav Hagara | Komentářů: 0
dnes 00:55 | Nová verze

Byla vydána verze 2.12.0 QEMU (Wikipedie). Přispělo 204 vývojářů. Provedeno bylo více než 2 700 commitů. Přehled úprav a nových vlastností v seznamu změn. Řešeny jsou také bezpečnostní chyby Meltdown a Spectre.

Ladislav Hagara | Komentářů: 4
dnes 00:33 | Komunita

Google zveřejnil seznam 1 264 studentů přijatých do letošního Google Summer of Code. Přehled projektů, studentů, 212 organizací a mentorů je k dispozici na stránkách GSoC.

Ladislav Hagara | Komentářů: 0
včera 23:55 | Nová verze

Oracle vydal verzi 1.0 univerzálního virtuálního stroje GraalVM, který umožňuje běh programů napsaných v jazycích založených na JVM, JavaScript, LLVM bitcode a experimentálně Ruby, R a Python.

razor | Komentářů: 1
včera 01:22 | Zajímavý článek

Julia Evans pomocí svých kreslených obrázků proniká do Linuxu a informačních technologií. Vedle ucelených zinů publikuje také jednotlivé kreslené obrázky (RSS).

Ladislav Hagara | Komentářů: 5
23.4. 13:22 | Zajímavý software

Jordi Sanfeliu vydal verzi 1.0.0 svého unixového jádra Fiwix (Wikipedie) určeného také pro výuku operačních systémů. Dle článku na OSNews na něm začal pracovat již před více než dvaceti lety. Zdrojové kódy jsou k dispozici na GitHubu pod licencí MIT. Stáhnout a vyzkoušet lze živou disketu nebo CD s GNU/Fiwixem.

Ladislav Hagara | Komentářů: 5
23.4. 06:00 | Nová verze

Byla vydána nová verze 10.7 open source alternativy GitHubu, tj. softwarového nástroje s webovým rozhraním umožňujícího spolupráci na zdrojových kódech, GitLab (Wikipedie). Představení nových vlastností v příspěvku na blogu. Vývojáři GitLabu zdůrazňují Web IDE (YouTube) a SAST (Static Application Security Testing) pro Go a C/C++.

Ladislav Hagara | Komentářů: 8
22.4. 14:00 | Zajímavý článek

David Revoy, autor open source webového komiksu Pepper&Carrot nebo portrétu GNU/Linuxu, zveřejnil na svém blogu recenzi notebooku Librem 13 od společnosti Purism. Používá jej již sedm měsíců a s ním i jako umělec spokojen. Potřebu francouzské AZERTY klávesnice vyřešil přelepkami. Na displej se podíval kalibrační sondou, barvy vyladil pomocí open source softwaru DisplayCAL, v aplikaci Inkscape nastavil zvětšování na 170 % aby 1 cm v Inkscapu byl 1 cm v reálu. Webovou kameru, mikrofon, Wi-Fi a Bluetooth lze na Librem 13 hardwarově vypnout.

Ladislav Hagara | Komentářů: 7
21.4. 23:44 | Komunita

Několik posledních verzí GNOME Shellu obsahuje chybu způsobující memory leak (únik paměti). Viz například videozáznamy verzí 3.26 nebo 3.28. Nalezení chyby #64 a její opravě se věnuje Georges Basile Stavracas Neto v příspěvku na svém blogu [reddit].

Ladislav Hagara | Komentářů: 2
Používáte na serverech port knocking?
 (2%)
 (7%)
 (46%)
 (27%)
 (18%)
Celkem 371 hlasů
 Komentářů: 29, poslední 5.4. 12:25
    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.