Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - Logik

Stran: 1 ... 40 41 [42] 43 44 ... 68
616
Software / Re:Jaky FS - ZFS ... poradte prosim!
« kdy: 29. 12. 2011, 17:45:39 »
Jen k těm obrazovým datům: samozřejmě i TIFF a RAW jsou komprimované, akorát bezstrátovou kompresí. Takže je nijak nezkomprimujete a pro přenos bych spíš tu kompresi vypnul, protože to jen zatíží procesor a velikost dat může i vzrůst. Samozřejmě šifrování smysl má, ale to entropii z principu nemůže snížit takže ani po zašifrování to nepůjde zkomprimovat lépe.

617
Vývoj / Re:Pomoc se strukturou databáze
« kdy: 29. 12. 2011, 17:37:19 »
- ad pojmenování:
doporučuju tabulku v jednotném čísle. Název cizího klíče <table>_id. Název primárního klíče buďto shodný s cizím klíčem, nebo jen id, obé má své výhody a nevýhody. A cíleně se vyhýbat duplicitám v jménech sloupců spíš nedoporučuju: ono to ve větší db ani nejde. Spíše je lepší si zvyknout vždy psát plně kvalifikované názvy sloupců, tzn tabulka.sloupec.

- ad GROUP BY - pokud někde musíte použít GROUP BY, kde přímo nepotřebujete agregaci, asi je dotaz špatně

- jak dělat filtry
píšeš, že všechny tabulky máš M:N. Tak to je skvělé, stačí Ti jeden mustr, kterej půjde aplikovat všude. Představ si teď filtr jako blackbox , kterej Ti hodí všechny možný čísla písniček. Takovej filtr poskládáš snadno, třeba u autora:

Kód: [Vybrat]
(SELECT pisnicka_id FROM pisnicka_autor WHERE autor_id IN (SELECT id FROM autor WHERE jmeno = "Cimrman") 

Podmínka ve where může bejt různá, např. WHERE autor_id = 1 nebo autor_id IN (1,2,3,4), podle toho, jak autory vybíráš.
Úplně stejnou podmínku můžeš udělat pro žánry, alba, co tě napadne.
No a teď vem tendle kus dotazu jakko blackbox kdekoli potřebuješ vybrat písničky:

Citace
SELECT * FROM pisnicka WHERE id IN <blackbox>

Nebo kde potřebuješ vybrat <entitu> (např. žánr, autora, atd...) z daných <entit>, které jsou možné pro již vybrané písničky

Citace
SELECT * FROM <entita> WHERE id IN (SELECT <entita>_id FROM <entita>_<pisnicka> WHERE <pisnicka_id> IN <blackbox>

V podstatě todle jsou všechny dotazy, které budeš potřebovat.

- ad opakující autoři:
Pokud Ti ten dotaz
Kód: [Vybrat]
SELECT artist FROM artist_table WHERE artist_id IN (...subselect...)
vyhodí opakující se autory, je to čistě proto, že v té tabulce opakující autoři prostě jsou :-). Řešení tedy není expost group by, ale už při plnění tabulky se duplicit vyvarovat. Nejlépe tak, že hodíš na sloupce, které by neměli být duplicitní omezení (constraint) UNIQUE (zároveň slouží jako index) a tabulku znova naplníš. Samo Ti to zařve v okamžiku, kdy tam budeš chtít vložit druhého stejného autora a budeš moct to opravit tak, aby to místo toho použilo již toho co tam je.

-ad jak dostat autora, album atd....
No jsou dvě možnosti: buďto opravdu přidat pro každou subtabulku, nebo si ty záznamy ze subtabulek vypsat vedle, strčit do nějakýho hashpole (v pythonu asi dictionary) a tahat je v případě potřeby. První řešení se vyplatí, pokud se tahá relativně málo písniček, druhý řešení se hodí, pokud se tahá hodně písniček a počet písniček značně převyšuje počet autorů/alb atd...

Pokud jsi tam Ty joiny dal a bylo to pomalý, pak je to možná tím problémem z předchozího odstavce, popř. je také možné, že Ti někde schází indexy... anebo tam např. někde schází nějaká potřebná podmínka. Zkus sem až ten předchozí problém vyřešíš dát ten dotaz, co je pomalej, a zároveň ještě jeho EXPLAIN (spusť ten samý dotaz, ale před něj napiš EXPLAIN, tzn. EXPLAIN SELECT ...........

- Jinak Ti doporučuju na to nezanevřít - mkožná to je opravdu overkill, ale na to, abys pro příště poznal, co už je overkill a co ne bys měl ten "overkill" zvládat a to se nenaučíš líp, než tak, že to prostě napíšeš.







618
Vývoj / Re:Pomoc se strukturou databáze
« kdy: 28. 12. 2011, 17:17:53 »
- to s tim rozdílem mezi distinct a group by bych se neučil, sice to asi byla alespoň v nějaký verzi mysql pravda (dělali tam nějaký optimalizace ohledně toho), ale obecně je to čunačina - dobře napsanej optimalizátor by měl umět užít index i u distinct - a naopak optimalizátory často selhávaj i u group by.

- pokud děláte vnořenej dotaz, tak žádný distinct (a už vůbec ne group by) nepotřebujete! Umělec je přeci v tabulce umělců pouze jednou! To, že je jeho číslo ve vnořenym dotazu víckrát je irelevantní.

- s tím, že JOIN je někdy rychlejší souhlasím, ale tuším, že všechny databáze co s nima mam větší zkušenosti z hlediska výkonu (postgresql, mysql, firebird) to už zvládaj dobře. Mysql 4 s tím měla velký problémy a Firebird 1 taky, tam jsem joinoval jak divej.

- osobně bych udělal tabulku lidí a ty pak přiřazoval k albu (nebo ještě lépe písničce, ale k albu je to přijatelný zjednodušení) buď jako interprety, nebo jako autory.  tzn udělat tabulku:
 album_id, osoba_id, (autor|interpret)
popř. v jednoduššim provedení dát do písničky pole autor a interpret (ale to nedovolí dva interprety apod).

- Stejnětak žánr podle mne musíš přiřazovat k albům a ne lidem. Jinak Ti vypadne např. mezi folkrokem bethowenova devátá, protože tu hrála česká filharmonie, která taky hrála s čechomorem (viz Rok Ďábla). A takovejdle "multižánrovejch" je spousta.

- automaticky generovaný dotazy alá IN nejsou zas takovej problém: představ si každej poddotaz jako jednu podmínku ve where. Prostě místo
žánr = něco
tam je podmínka
žánr IN (něco).
A to něco postavíš stejně, jako ten celej dotaz.
Každej filtr ve vyhledávači pak přidá jednu podmínku za WHERE, pospojovanou AND. To, že to chceš mít v GUI hierarchický neznamená, že musí bejt hierarchická struktura DB ani že musíš do sebe nořit deset dotazů.

- Co se týče udržování kódu, tak samozřejmě něco jde v plochý struktuře lépe, něco hůře. Ale zrovna tydlety vnořený dotazy, když má člověk dobrou knihovnu, moc nestojí. Doporučuju si napsat nějakej objekt na postupný skládání dotazů, z pythonu např. jsem za pět sekund našel sqlpuzzle3k. Ale nevím, jak se to používá, já používám bazmek vlastní výroby, je to pár řádek

result=new SQLurey('pisnika')
a každej filtr by vracel nějakej "filtr",
result.addWhere(filtr)
a ten filtr bych třeba na všechny písničky od Evy a Vaška udělal takhle:
filtr=new SQLInQuery('id', 'SELECT pisnicka_id FROM pisnickyautori pa INNER JOIN autori a ON (pa.autor_id = autor.id) WHERE autor.jmeno = "Eva a Vašek")
až na to, že tydle písničky bych spíš nechtěl, takže bych udělal
filtr=filtr.not()
a pak bych chtěl třeba ještě jen nový písničky
result.addWhere("rok > 2009")

takovádle knihovna ušetří hodně práce a zároveň zpřehlední to automatický generování SQL - jakože většinou se generuje automaticky.






619
Software / Re:Firefox nestahuje aktuální verzi dokumentu
« kdy: 20. 12. 2011, 03:52:26 »
Prohlídni si, jakou Ti vrátí prohlížeč hlavičku (např. ve firebugu v záložce síť - jestli to opravdu stahuje, nebo ne).

Jinak to opravdu může bejt blbost firefoxu - mě teď v něm přestaly fungovat tlačítka na myši kromě dvou standardních (ani kolečko nefunguje tak, jak má) a to je každou chvíli něco takovýho.

620
Hardware / Re:Výběr vhodné tiskárny pro Ubuntu 10 a vyšší
« kdy: 19. 12. 2011, 11:58:17 »
Pokud Ti jde o tisknutí textů, tak taky rozhodně laser.
Naopak samsungy bych moc nebral, pokud alespoň trochu tiskneš, maj drahý cartrige. Kromě driverů bych vybíral podle toho, jestli na ně jde sehnat alternativní cartrige (Armor apod.), pak se dá dostat s cenou na rozumnou úroveň.

621
Vývoj / Re:Pomoc se strukturou databáze
« kdy: 18. 12. 2011, 18:46:35 »
Jo, omlouvám se za to phpkovský pole, zapoměl jsem na zadání, tak pythonovskej dictionary, ten má taky (snad) dobrou implementaci.

622
Vývoj / Re:Pomoc se strukturou databáze
« kdy: 17. 12. 2011, 23:56:58 »
Kdy chceš použít distinct/group by? IMHO ho tady vůbec potřebovat nebudeš. (Pokud chceš vypsat všechny autory od píšniček, tak přehlednější je psát
SELECT * FROM autori WHERE id IN (SELECT autor_id FROM pisnicka WHERE .... 
než to spojovat joinem a jinde mě nenapadá, kde by se to mohlo použít.
Jinak, jak říkal předřečník, GROUP BY se používá, pokud tě zajímá např. počet "stejnejch" řádek, součet nějakejch polí (např. celková délka alb jako součet délek jednotlivejch písniček GROUP BY album_id) apod.
-
Pokud na začátku chceš jednorázově vytvořit novou tabulku alb a chceš to fakt rychle, tak tady bych se vykašlal na databázi a udělal si vedle phpkovský pole s nima a kouknul se tam. Ale nejlepší je IMHO udělat defaultní rutinu na přidávání písniček, kterou budeš používat i jindy, a vykašlat se na to, že se bude pokaždý písnička hledat znova - dělá se to jen jednou. Navíc pokud si uděláš metodu na vyhledání alba, tak tam můžeš udělat cache: pak Ti stačí záznamy zpracovávat seřazené dle abla a máš to defakto bez výkonnostní ztráty.
Takovýdle věci se optimalizujou, teprv až když je to hotový a je to moc pomalý.

623
Vývoj / Re:Pomoc se strukturou databáze
« kdy: 14. 12. 2011, 20:17:48 »
Ještě upřesním, zaměř se na kapitoly
- První tabulka
- Vytváření relací
- Select I (jestli nevíš nic o selektu), ale tady přeskoč spojování tabulek
- Select III (tady je to spojování tabulek pořádně).

624
Vývoj / Re:Pomoc se strukturou databáze
« kdy: 14. 12. 2011, 20:15:03 »
Hmm, dobrej SQL tutoriál je těžký, většinou stojej za houby: buďto moc teorie, nebo blbiny.
zkus třeba todle:
http://www.sallyx.org/sally/psql/
ale vybírej si z toho, co potřebuješ (např. ignoruj úpravy již existujících tabulek). Pokud to bude moc, tak se ozvy, pokusím se najít něco jednoduššího, co by mělo cenu...


625
Vývoj / Re:Pomoc se strukturou databáze
« kdy: 14. 12. 2011, 12:13:51 »
- Vzhledem k tomu, že to má být na deset tisíc písniček, tak je tam asi těžko bude vkládat věci ručně. A i kdyby, tak pokud to bude dělat často, tak tady jsou view a stored procedury, kterejma se to dá snadno nahradit. Ano, je to složitější než přímý zápis do tabulky. Rozdíl mezi těma řešeníma je ale ten: když budu chtít s normalizovanejma tabulkama realizovat "plain pohledy", je to rozumně a vcelku rychle řešitelné. Když budu chtít s plochou tabulkou realizovat ty featury, které neumožňuje, musíš to v podstatě celé přepsat.

- Ano - do ploché tabulky se lépe vkládá. Ale jak jsem ukazoval na příkladu s beatles, plochá tabulka prostě nevyhovuje vlastnostem, které jsou na řešení požadovány. Je to klasické přizpůsobení aplikace programátorovi, místo toho, co by se programátor přizpůsobil aplikaci.

- Jinak souhlasím: na "primitivní" rychlé řešení věcí, do kterých nebudu muset nikdy znova sáhnout se to řešení hodí. V případě, že se musí takové řešení udržovat, tak člověk ale brzo zjistí, že počáteční úspora času se hodně prodraží. A když si přeteč první post, tak tazatel právě do tohoto stádia došel. Zaflikovat to tím, že  jen použiju rychlejší technologii na vyhledávání mi prostě nepřijde jako dobrej nápad: ani z hlediska vývojářskýho, ani didaktickýho.

626
Vývoj / Re:Pomoc se strukturou databáze
« kdy: 14. 12. 2011, 09:02:51 »
Proč ten uraženej tón?

Jinak já netvrdím, že je to nutné bezpodmínečně vždy. Ale když to člověk dodržuje, neudělá chybu. Což je pro začátečníka obzvlášt vhodné. Porušovat pravidla se má až v okamžiku, kdy člověk dobře rozumí tomu, proč je porušil. A zrovna u umělých klíčů je opravdu jednodušší je mít všude - hodně "přitažlivých přirozených PK" ve skutečnosti jako PK rozumně použít nejde (např. rodné číslo) a umět vybrat data pro PK opravdu vhodná chce nějakou zkušenost. Tak nechápu, proč na jednu stranu tady obhajuješ plochej model, protože je začátečník a na druhou stranu ho cpeš do použití "nebezpečnýho postupu", kterej mu v nejlepším případě přinese pár bytů na disku a možná ani to ne.

A co se týče normalize: pokud by se mu to zaseklo opravdu proto, že by nebyl schopnej rozdělit jednu tabulku do tří, popř. pracovat s víc tabulkama než s jednou, tak nemá smysl, aby se učil programovat. A pokud to zvládne, tak se to aspoň naučí. Doporučovat začátečníkovi, ať "prasí", že se to kdyžtak přepíše je ten nejlepší způsob, jak z něj vychovat "programátorské prase".

Obzvlášť, jestli je to začátečník, tak to "refaktorizovat je možno kdykoli" se pro něj rovná "přepsat je to možné kdykoli" - a to už je to lepší začít psát rovnou dobře.


627
Vývoj / Re:Pomoc se strukturou databáze
« kdy: 14. 12. 2011, 00:54:44 »
Umělej primární klíč se vyplatí používat vždy, už proto, že pak člověk nemusí přemejšlet, jak se ten primární klíč v týdle tabulce jmenuje a jestli je umělej nebo ne, spousta databázovejch nástrojů a knihoven automaticky čeká, že tam je sloupec id (popř. pokud tam je, tak je používání jednodušší) atd....
Další problém dokumentuje právě ten OP - ano, je to na první pohled lepší. Ale v dobrym db násroji máš to id sterjně prolinkovaný, takže to nevadí. A až se jednou dostaneš do situace, že budeš chtít zaevidovat občanskej průkaz, od kterýho neznáš číslo (to už vůbec nemluvim, že spíš se tímdle číslem budou evidovat lidi, a ty nemusej mít OP, můžou mít dva OP atd...).

Vzhledem k tomu, že umělej PK tě nic nestojí a žádnej problém nemá (nebo se pletu? jakej? - napsání o jednoho řídku víc v SQL mi fakt problém nedělá), naprosto nevidim důvod, proč ztrácet čas přemejšlenim nad tim, jestli náhodou todle není speciální případ, kdy to problém není. Navíc, když se velmi často mění zadání za pochodu a to, co problém nebyl...

----

Ad normalizace: ano, je to jen playlist. Dá se to ošulit - a když budeš mít štěstí a zrovna tam nebude někde zakopanej pes, tak na tom i (časově) vyděláš. A právě, pokud chceš vyloučit, že tam někde nevznikne nějakej průšvih, tak je nejjednodušší cesta normalizace. Protože ta Ti to zaručuje automaticky a defakto bez práce (normalizovat umí i cvičená opice). Bez ní je riziko, že to nebude umět něco, co chceš. Namátkou když chceš přehrát všechny Beatles, tak Ti to opravdu přehrálo Beatles, včetně společné desky Beatles a Moravanky, ale už ne kapelu Beatles Revival, tak to s plochou tabulkou uděláš dosti těžko: fulltextem tydle případy nerozlišíš.
 
 


628
Vývoj / Re:Pomoc se strukturou databáze
« kdy: 13. 12. 2011, 21:21:43 »
Jo a ještě k primárnímu klíči. Z poměrně dost důvodů je vhodné, aby byl PK umělý, tzn. automaticky vygenerovaný integer. Např. kvůli velikosti dat (8b ku třeba 100b řetězci), možnosti změny záznamu (při přesunu souboru bys musel měnit PK všude, byť to jde automatizovat) atd...

629
Vývoj / Re:Pomoc se strukturou databáze
« kdy: 13. 12. 2011, 21:18:42 »
Ad výkon:  normalizací se rychlost rozhodně nesníží. Snížila by se, kdyby primárně byl  požadavek na plochá data, jenže tady naopak když se budou číst velké dávky dat, tak to právě budou data z těch "normalizovaných" tabulek. Např.
  * operace, která se po startu vždy musí provést: dej mi všechny autory (žánry, playlisty...) místo sekvenčn procházení celých 10000 záznamů a vyřazování duplicit prostě vyplivneš obsah tabulky. Dej   
  * vyhledávání dle autora: prohledám místo 10000 záznamů pár stovek záznamů s autory. Join přes pár integerů je pak levná záležitost přes klíč.
Dražší budou (a to ještě možná) operace zahrnující většinu dat, např. vyplyvni všechny písničky a u nich uveď autora. Nebo dej všechny písničky od autorů, který začínaj od Z atd.

Ad 1:n ku M:N. Jo jde to i 1:N. Obejít pomocí Šlitr+Suchý také. Pokud to děláš pro sebe, klidně u toho zůstaň. Pokud máš vážnější plány, dát tam jednu mezitabulkutakovej problém není. Naopak je to spíše jednodušší, protože nejprve zapíšeš písničku "jak je".
Navíc u něčeho (např. playlisty) to M:N stejně potřebuješ IMHO nutně, a vzhledem k tomu, že když to napíšeš chytře, tak Ti bude jedno, jestli zrovna řešíš playlist, autora nebo žánr, takže se to vlastně tím, že to uděláš M:N, zjednoduší.

Ad databáze: no já ani nevím, odkud je umím, ze školy to není. Takže tam moc neporadím. Jen doporučím obecně, neupadnout ani do jednoho extrému: tvrdá teorie (např. relační algebry) pro začátečníka není. Na druhou jen lepení dotazů bez nahlédnutí do toho, jak to db dělá taky nic moc. Takže nějaká zlatá střední cesta. Z teorie bych pro začátek končil někde u normálních forem, s tím, že normalizace je hezká teorie, ale v praxi někdy selhává: ale porušovat pravidla se mají tepr až když jim člověk rozumí.

Ad kanón na vrabce: jak se to vezme. Pokud to postavíš na textu, tak v životě nedovolíš např. vyfiltrovat pouze Beatles od Beatles revival.  Samozřejmě, napsaný to bude rychlejc a pokud chce člověk jen jednoduchý "blbátko" tak to není špatný řešení. Ale když to budeš chtít rozšířit, tak zjistíš, že to napíšeš celé znova.

630
Vývoj / Re:Pomoc se strukturou databáze
« kdy: 13. 12. 2011, 17:20:02 »
No pokud chceš todle, tak Tě to přímo na strukturu vede, ne?
Takže máš žánr, autor, album, písnička, playlist. Pro každou tu entitu si udělám tabulku.
U všech je vazba M:N na písničku.
- Vyhledávání a filtrování pak bude jednoduchej join nad těma tabulkama.
- V sloupcích se bude zobrazovat obsah patřičný tabulky.

A pro vyhledávání podle dalších kritérií (tagů písniček) bych přidal tabulku 1:N k písničkám, kam bych dával další custom tagy

Odlišný budou jen dynamický playlisty, kde místo join nad danou tabulkou budeš mít v apikaci předepsanej patřičnej filtr.


Plochou strukturu můžeš použít defakto taky, ale není to hezký a některý operace (např. vypsání autorů) znamená zbytečný projití celý tabulky, místo daleko menší tabulky seznamu autorů, a u netriviálních operací (např LIKE '%opice%') se nevyhneš sekvenčnímu scanu,  tabulky (sqllite je sice rychlá, ale zbytečně smažit procesor kvůli tomu, že to neumim napsat pořádně...).



Stran: 1 ... 40 41 [42] 43 44 ... 68