Výber z viacerých tabuliek

Jasne, chapu... Jak jsem psal uz predtim... ten dotaz na union se da lehce modifikovat pomoci SUM a vnitrnich count(). A jak jsem dale uvadel, tak cistota reseni je relativni. To jsi mozna nepochopil ty... pokud by byla realita takova, jak pises, urcite je lepsi tva varianta. Ale pokud pujde o sofistikovanejsi statistiky, tak je to nepouzitelne."(ze je vlastne uplne jedno jak se vysledku dobere)" - ma myslenka byla takova, ze neni jedno, jaka cesta se pouzije, ale z hlediska narocnosti, budouciho rozvoje, atd. by se melo vybirat to nejlepsi reseni. Pokud je na to prostor a cas.Ale uz takto na tomto travime spoustu casu. Pojdme delat neco uzitecnejsiho;-) puvodniho tazatele to stejne uz asi nezajima;-)Michal

mytrix ma pravdu, jeho reseni je lepsi a efektivnejsi. Pocitat s tim ze se jednou nejak zasadne zmeni struktura INFORMATION_SCHEMA.TABLES, je asi stejne jako dneska neprogramovat radeji nic pro Windows 7, protoze jednou stejne nekdo prijde s Windows 2050 a to co dneska naprogramuju nebude kompatibilni. Souhlasim take s nazorem ze resit to pres UNION nad spoustou tabulek je v tomhle pripade prasarna, ktera pri velkem poctu volani na databazi muze totalne pretizit DB stroj a navic bude pretezovat ramku (uvazuji zde v radu desitek a vice tabulek). Samozrejme jde udelat X reseni, coz ale nemeni nic na tom, ze pokud je reseni napsane neefektivne a spatne je to proste spatne reseni, i kdyz povede ke spravnemu vysledku. tarton Navazet se do spatnych reseni a kritizovat je, je v poradku, zvlast kdyz jsou takhle moc spatne. Ze chybi argumenty? Ne vzdy je pro databaze neznaleho prinosem ze se tu vyjmenuje spousta duvodu a technickych specifikaci. UNION zatezuje databazi a RAMku, zvlast pokud pocet tabulek narusta. Taky muzu napriklad rict ze reseni je podivat se kazde rano na tabulku v PHPAdminu, vyjet si jednotlive hodnoty, spocitat to v Excelu a ulozit to rucne do nejake tabulky a tu pak cely den pouzivat. Bude to absolutne funkcni reseni, ale absolutne nesmyslne. Tvoje reseni neni nesmyslne z hlediska automatizace a vracenych vysledku. Je ale nesmyslne z hlediska zateze DB v produkcnim provozu. Reseni pres PHP cyklus jak tu nekdo psal je take nesmysl, je to zpusob jak uvazuji programatori, kteri nevidi moc do databazi tak to obchazeji PHP kodem. Je to spatne, neefektivni a narocne na pocet volani DB. Tino88 Souhlasim s nazorem Martina, ze navrh databaze je naprosto spatne. Pokud se musi vymyslet takhle krkolomna reseni, je nejlepsi navrhnout ER model databaze jinak. Martinuv navrh je pro tenhle pripad velice prihodny. Pristup do INFORMATION_SCHEMA.TABLES se sice pouziva, ale spis pri instalaci aplikace, pluginu apod. Kdy se zjistuje podle toho jake jsou tabulky a jejich sloupce, jaka je verze systemu a podle toho probiha upgrade, instalace, odinstalace apod.

OK, diky za info co se tyka zateze, to je vcelku dobra informace. K tomu slouzi diskuze...Nesouhlasim vsak s prvnim odstavcem. Zmena struktury INFORMATION_SCHEMA.TABLES je jedna z mnoha veci, ktere se mohou zmenit. Jak jsem psal, pravdepodobnejsi je vsak zmena pozadavku od zadavatele. V tom pripade je toto reseni nepouzitelne. O to mi slo puvodne.Ostatni veci uz neni potreba komentovat.

tarton: K tomu, ze se muze zmenit INFORMATION_SCHEMA.TABLES, ano muze. Ale nikdo kdo ma trochu soudnosti nenainstaluje na produkcni server novou verzi databaze bez otestovani kompatibility. Pri prevodu z jednoho DB serveru na jiny v jine verzi se opet kompatibilita bezne testuje. Takze takovahle zmena nebude nejaky zasadni problem, bude se s tim pocitat a v ramci upgradu se aplikace muze prislusne upravit. Navic meni se sice obcas struktura ale z duvodu zpetne kompatibility se zachovava puvodni struktura, nebo se nad novou delaji view, tvarici se jako puvodni struktura, takze pak opet neni problem.

Zajimalo by me, jesli jsi ten muj clanek cetl? Ty se motas pouze kolem zmeny INFORMATION_SCHEMA.TABLES, ale jde i o jine zmeny spojene s implementaci IS.Michal

Michale, nevyuzit moznosti prave tehle konkretni tabulky, to je jako rikat ze u MS SQL nepouziju T-SQL funkce, nebo u Oracle PL/SQL, abych zustal pouze u SQL standardu (tady jeste zalezi jestli SQL-86, SQL-92 nebo SQL-99). Myslim ze prednejsi je vyuzivat naplno moznosti ktere aktualni system nabizi, nez resit ze mi ho jednou nekdo v dalsi verzi zmeni (coz se deje, ale pak jsou nastroje na upgrade a prevod kodu, nebo se to musi holt udelat rucne).Ale tohle uz je takova diskuze uplne mimo puvodni tema, tak asi nema moc smysl to dal nejak moc resit. Tvoji pointu chapu a vzdy zalezi na zvazeni pro a proti urcitych reseni a na tom se urcite shodneme :).

Ano, presne o toto jde "vzdy zalezi na zvazeni pro a proti urcitych reseni a na tom se urcite shodneme". A vim, ze je vzdy dobre naplno vyuzit potencial DB. Ale toto nejde srovnavat s TSQL procedurami. To uz se bavime o vrstveni aplikace.Jde mi o to, ze vychytavky jsou fajn vec, pokud je to rozumne. A v tomto pripade ano... Ale uz ne, kdyz pujde o sofistikovanejsi statistiky. Na tom se myslim take shodneme;-)Doufam, ze to nevypada, ze jsem nejaky beran, nebo neco podobneho...Jsem rad, ze jsem se zase dozvedel neco noveho;-)Michal