Registrace nového uživatele     Návod     Kluby     Archív  Lopuchu     Lopuch.cz  

Diskuze na Lopuchu,
pohlazení na duchu

Lopuch.cz
Jméno:
Heslo:
Podpora LCD:
 
Klub Database (mysql,...) [ŽP: neomezená] (kategorie Programování) moderuje melkor_unlimited.
Archiv
  Nastavení klubu     Nastavení práv     Homepage     Anketa     Přítomní     Oblíbené     Lopuch     Kategorie  
autor: 
text: 
vyplnit a 
Help
 Titulek, text příspěvku  
Opište pozpátku následující text bez prostředního znaku: whradrj
[ 1008 ] <Novější  <<<Nejnovější  Nejstarší>>>  Starší>  
bredy 23.2.2010 13:20  1087
pepakno zrovna MySQL se s verzi co verzí lepší.
jinak
FROM x, y LEFT JOIN z ON ..
není to samé co
FROM x CROSS JOIN Y LEFT JOIN z ON ...

Už proto, že v prvním případe v podmínce ON nemůžeš referovat sloupec z tabulky X. To můžeš až ve WHERE klauzuli.
bredy 23.2.2010 13:18  1086
Mě napadají šílenosti typu

FROM x,y LEFT JOIN a,b ON

FROM (x,y) LEFT JOIN (a,b) ON

FROM x, (y LEFT JOIN a),b ON # ps syntaxtická chyba

FROM x, LEFT JOIN (y LEFT JOIN a), b ON ...

Nezkoušel jsem, ale vyplývá to z logiky.
pepak pepak - Pepak.net 23.2.2010 13:18  1085
Bredy: Čárka by měla být totéž co CROSS JOIN. U MySQL samozřejmě těžko říct, to si z nějakých SQL standardů těžkou hlavu nedělá, ale u normálních databází to je jen jiný zápis téže operace.
bredy 23.2.2010 13:14  1084
Jak já jsem pochopil, tak čárka je proste nakombinování dvou tabulek každý s každým, kartérský součin, nevím, jak se to označuje u JOINů, protože jich je tolik, že v tom mám zmatek. Filtrace u WHERE pak je opravdu výběr těch dvojic, které mají zůstat. JOIN je úplně jiná operace, takže asi proto to MySQL striktně rozlišuje. Tedy že čárka s WHERE možná dělá to samé, ale není to samé. Z logiky věci pak opravdu vyplývá nutnost definovat prioritu mezi čárkou a JOIN. Zápis (a,b) JOIN ... pak znamená, aplikování JOIN na karterský součin a s b, zatímco a JOIN b JOIN ... znamená sloučení a s b a s nějakoud další tabulkou. Možná to má ale vliv jen na pojmenovávání polí a jejich adresace (tedy nemohu adresovat pole v tabulce, se kterou nespolupracuju).

Ale možná to je jen věc MySQL, neznám standard z hlavy a z databází jsem měl ve škole za 3.

Z hlediska optimalizace by však mezi čárkou + WHERE a JOIN neměl asi být rozdíl, dotaz by se měl vyhodnotit stejně. Ale to záleží na databázovém stroji.
etdirloth EtDirloth 22.2.2010 22:48  1083
Bredy [1082]: hmm, teraz si ma trochu rozhodil, pretoze odjakziva som si myslel (som bol uceny), ze ciarkami oddelene referencie iba pridaju zoznam tabuliek, ktory sa nakoniec CROSS-JOINne a vo WHERE klauzule uz len vyberies riadky, ktore maju vo vysledku zostat. Ked som vsak pre svoju interpretaciu zacal hladat podklady (par hodin som stravil nad specifikaciou SQL92 a skusal som aj ine zdroje), tak som nepochodil, pretoze specka hovori o ciarke ako ekvivalente CROSS JOIN - podobne ako ty - a o smere vykonavania, alebo priorite JOINov/ciarok ani slovo. Ucili ma to este ked som zacinal na Oracle (pricom PgSQL je na tom rovnako) - JOIN dvoch tabuliek/referencii tak ako popisujem v 1080. Je to uz tiez nejaky cas, ale co si pamatam, tak MSSQL to vyzaduje takisto v spravnom poradi.

Par rokov dozadu som vsak riesil rovnaky problem ako ty (dostal som zmigrovat jednu aplikaciu medzi MySQL4->5), kde presne takyto prehodeny JOIN/ON na MySQL4 fungoval, ale na MySQL5 uz nie. Vychadza mi to proste tak, ze niekde v standarde to je uvedene - pretoze vsetci to tak implementuju - iba ja to tam neviem najst :P
bredy 21.2.2010 18:42  1082
EtDirlothJá znám tu interpretaci. Ale už jsem zvyklý, že chci-li opravdu 1:1 spojení, tak používám FROM s čárkou a podmínku WHERE, přestože JOIN je vlastně totéž (a s JOIN to taky funguje.)

Mě šlo spíš o to, že zřejmě nově mohu přes čárku a podmínku WHERE spojit dvě tabulky, které byly předtím spojené přes JOIN, ale také mohu vzít nejprve spojení přes čárku a následně aplikovat JOIN na výsledek. Ve starém MySQL bylo možné jen to druhé, proto FROM x,y je ekvalentní FROM (x,y). Nově to tedy zřejmě ekvivalentní není. 

Vem A, zleva připoj B a k tomu vem C zleva spojenou s D, 
FROM A LEFT JOIN B ON ..., C LEFT JOIN D ON...

Vem A a spoj to s C ke které nejprve zleva připoj B a D
FROM A,C LEFT JOIN B ON ... LEFT JOIN D ON ...

Vem A spojenou s C a k tomu zleva připoj B a D
FROM (A,C) LEFT JOIN B ON ... LEFT JOIN D ON ...

Ergo je to změna priority, protože nyní má čárka nižší prioritu, než JOIN.
etdirloth EtDirloth 21.2.2010 08:46  1080
Bredy [1079]: nie priorita. JOIN ti spaja dve tabulky a ON urcuje pravidla spojenia, pricom ON nema co obsahovat podmienky netykajuce sa tohto joinu. Ine podmienky patria aj semanticky do WHERE klauzuly (je imo elegantnejsie pouzit JOIN namiesto ciarky, pretoze podmienka joinu je hned pri nom a nie az vo WHERE; a to aj v pripade ze ide o CROSS).

V tvojom pripade si chcel spajat `karta` s `cis_pojistovny`, ale dotaz obsahoval `lekar` JOIN `cis_pojistovny`.
bredy 20.2.2010 19:30  1079
Aha... tedy priorita. Vypadá to na změnu v chápání dotazu.

FROM x,y lze chápat jako FROM x [JOIN ku x], y [JOIN ku y]. Podle logiky jsem zkusil to dát do závorek FROM (x,y) a ono to chodí.

FROM (x,y) [JOIN ku (x,y)]

Starý MYSQL ale FROM x,y bral jako FROM (x,y)

Díky
huh huh 20.2.2010 19:20  1078
Ja bych zkusil obratit poradi v tom  FROM:
FROM lekar, karta LEFT JOIN cis_pojistovny
bredy 20.2.2010 19:11  1077
Co je na tomhle dotazu blbě:
SELECT `RodneCislo` , `karta`.`Jmeno` , `Prijmeni` , 
`cis_pojistovny`.`Zkratka` AS `Pojistovna` , DATE_FORMAT( `Narozeni` , '%e.%c.%Y' ) AS FNarozeni, 
DATE_FORMAT( NOW( ) , '%e.%c.%Y' ) AS Dnes,  `lekar`.`Jmeno` AS `Ordinace` , `ICZ` , `ICO`
FROM `karta` , `lekar`
LEFT JOIN `cis_pojistovny` ON `karta`.`KodPojistovny` = `cis_pojistovny`.`Kod`
WHERE `karta`.`Index`='${Pacient}'

${Pacient} je vynechávka.

Háže to: Unknown column 'karta.KodPojistovny' in 'on clause'

Podotýkám, že na MySQL 4.1 to chodí, tabulky a sloupce existují. Existuje jak karta.KodPojistovny, tak cis_pojistovny.kod

Pokud vám to přijde divné, tak je to vlastně dotaz obsahující dva dotazy. Vyzvedne jeden řádek s pacientem a připojí k tomu jediný řádek z tabulky lekar, to aby se nemusely volat dva SQL dotazy, vrátí se to v jedné tabulce. Tabulky jsou nezávislé.
tvx tvx Myslet si, že svět je JEN takový, jak - ho v daný čas můžeme pochopit je hloupé. 2.2.2010 10:22  1076
KingRozjizdet novou vec a mit na to treba mesic a penize, tak si hraju, tohle je jen fixace jednoho nefunkcniho schematu na kterou mam cca tyden...
diky za inspiraci a rozsireni obzoru :)
king King Born to be king - ... 2.2.2010 00:21  1075
mnou zminovane veci ti rozhodne data neztrati spis nez treba s MySQL :) a spoustu veci je s nima o hodne jednodussi - od replikace (vsechny) az po ukladani komplikovanych datovych struktur, indexovani a dotazovani (treba Mongo je v tomhle naprosto uzasne)

navic pro vetsinu z nich mas v PHP API takze nebudes ani muset znat SQL ci nejaky jiny dotazovaci jazyk, budou na tebe mluvit PHP.

For je v tom ze vetsina dat na webu neni relacni ale je vice ci mene slozite mapovana na SQL jen proto ze lidi jsou na to zvykli.

Ale samozrejme ve finale je to o tom s cim se ti dobre dela - pokud to staci, pouzij to. (ze stejneho duvodu uplne mlcim nad tim ze chces pouzit PHP :-D)
tvx tvx Myslet si, že svět je JEN takový, jak - ho v daný čas můžeme pochopit je hloupé. 1.2.2010 20:38  1074
KingRelacni se mnou mluvi v sql a rozumime si, neuvazoval jsem puvodne o moc velikych vyletech do cizich vod :)
Tebou zminovane veci jsem jeste nepotkal ale vypadaj zajimave, me by vlastne nevadily ani obcasny ztraty dat, protoze moje data vlastne zijou jen max. 24 hodin.
king King Born to be king - ... 1.2.2010 19:14  1073
plus na fulltext nejaky fiulltext engine - lucene, sphinx nebo solr
king King Born to be king - ... 1.2.2010 19:13  1072
tvxa musi to byt relacni db?

na takovy pocet zaznamu a takovou frekvenci updatu bych skocil po redisu, nevim ale jake mas naroky na cteni, jakym zpusobem k tomu budes pristupovat a spol. musel bys asi znovu promyslet navrh te tabulky, ale garantuju ti ze zadna relacni db nebude rychlejsi.

jeste bych se podival na cassandru (column storage napsana ve facebooku) a MongoDB
[ 1008 ] <Novější  <<<Nejnovější  Nejstarší>>>  Starší>  

(c) 2001-2011 Lopuch.cz   
Kontakt