Vlákno názorů k článku Korelované vnořené dotazy: proč nepoužívat a čím nahradit od Xerces - Ahoj, článek super. Díky. Mám dotaz k těm...
-
Xerces (neregistrovaný)Ahoj,
článek super. Díky. Mám dotaz k těm korelovaným mezisoučtům. Ten výpočet sale_price tak jak tam je uveden závisí na nějakém defaultním pořadí v jakém pracuje ten select jestli to chápu dobře. Nemělo by tam být někde raději ORDER podle toho datumu, nebo asi spíš primárního klíče. Nebo je to vlastnost PostgreSQL že VŽDY pokud není uvedeno řadí dle primárního klíče? Nevíte jak to je u ostatních databází, jestli je daný nějakou normou že vždy když napíšu SELECT * FROM tabulka vypíše záznamy ve stejném pořadí? -
Chápete to dobře. Nad tabulkou history ORDER BY chybí spíš z principu. Do audit tabulek se zapisuje pouze na konec .. proto jsou automaticky seřazené podle id (za předpokladu, že s tou tabulkou tak pracuji). Jakmile bych provedl UPDATE, tak už by to nebylo pravdivé a výpis by byl přeházený. Nicméně hodnoty budou stejné: filtr WHERE product = o.product AND id <= o.id zajistí nezávislost na pořadí zpracování vnějšího dotazu.
Podle normy je pořadí výpisu záznamů nedefinované - bez použití ORDER BY. PostgreSQL zobrazuje záznamy chronologicky - jak byly vloženy do databáze nebo jak byly modifikovány. Nejsem si jistý, snad InnoDB vypisuje záznamy podle primárního klíče, jelikož udržuje fyzicky záznamy v pořadí, které definuje primární klíč. -
Korektní zápis by byl s ORDER BY. Pokud ale vím, jak se daný RDBMS chová, a jak pracuji s tabulkou (a v tomto případě vím), tak ORDER BY představuje zbytečnou operaci SORT. Přiznávám, že to není úplně košér. Abzch měl jistotu, musel bych pro všechnu uživatele zakázat UPDATE na tabulce history.
Správné řešení je použití cluster indexu na sloupci id a ORDER BY dle id. Potom by měl ORDER BY neměl generovat další zátěž. U innodb by to mělo fungovat. U pg to ale fungovat nebude, takže je jednodušší zakázat UPDATE a pak se mohu spolehnout na pořadí záznamů (tohle je čistě pragmatický přístup). -
LENIN POWER! (neregistrovaný)databaze bezne delaji synchronized tablescany, pokud jedna transakce nacita tabulku a uz je v pulce a druha ji chce nacitat tablescanem taky, tak ta druha nezacne od zacatku, ale pripoji se k ty prvni a obe dve projedou pulku tabulky spolecne za jedny penize /diskove io/ a pak ta pozdejsi transakce vezme zacatek.
pravda netusim zda tohle umeji oss databaze nepracuji s nima. jen jsem slysel ze mysql se v poslednich verzich jiz dost zlepsilo. pry do nove verze uz planuji online backupy a rollforward.
podle mne je stejne lepsi si vzit free verzi komercni db oproti oss db, nemusite se pak ucit novou db a prepisovat aplikace kdyz budete potrebovat neco co oss databaze neumi nebo kdyz budete pak provozovat aplikaci, ktera nad oss db nejede.
Krom toho lidi co umeji komercni databaze vic berou, kdyz se podivam na platy u nas tak clovek co dela lamp nebere vic jak 2.5 litru a to jeste jen pokud je team leader, protoze tahle prace se da dobre outscorovat ruskym a indickym firmam, tak neni duvod mu platit vic. LAMP patlal je komodita. Javisti to je jina trida, tech kvalitnich je stale nedostatek. Proto taky berou nekolikanasobne vic.
Pritom J2EE neni tak tezka na nauceni, jen se to holt lidi nechteji ucit kdyz uz umi to php a mysql co se naucili nekde na stredni skole. Kdyz j2ee umi, tak se jim pak nesmi sahnout na hibernate, protoze jsou liny se ucit sql. Kdyz umi sql, tak jsou liny se naucit jak funguji zamky aby nemeli v aplikaci races. A kdyz umi i zamky, tak protestuji ze se nechteji ucit psat testcases. -
LENIN POWER! (neregistrovaný)umi taky reordering transakci? to se dela jednak (zejmena) kvuli deadlockum a jednak kvuli performance.
jde o to ze v pripade deadlocku se udela rollback, releasnou se zamky a druha transakce se komitne. pak se grabnou znovu zamky a zkusi udelat zmeny co transakce zamyslela a pokud se nedaji udelat tak se nahlasi deadlock aplikaci a transakce se definitivne zrusi.
i kdyz je to asi chyba aplikace mydlit X locky na zaznamy co nemodifikuje a pak se deadlockovat, ale dost aplikaci (ehm SAP) to rado dela. -
Tak reordering transakci to neumi. A neni to ani v ToDo a v pg konferenci jsem o tom v zivote neslysel. Nikdo ale neprovozuje nad PostgreSQL uzasny SAP. Detekovany deadlock skonci vyjimkou. Kazda slusna aplikace musi byt schopna opakovat transakci. Ciste teoreticky, kazda transakce muze skoncit vyjimkou (z nejruznejsich duvodu).
-
LENIN POWER! (neregistrovaný)Nojo SAP to je hezká ukázka mezi db teorii a praxi. Transakce jsou obecne pri tvorbe sestav hezká vec, ale kdyz databáze nema mvcc tak se holt všechny ro query jedou v uncommited read a to jeste nestaci k tomu aby se useri dostatecne netloukli o zamky. vetsinou se jeste zapina vypnuti X zamku u insert a delete radek (radky se ignoruji), snizenim X na U u updated radek.
-
smzx (neregistrovaný)Jak vas tady sleduji, musim reagovat. Pro accounty je java synonimum prusvihu. Drahy vyvoj, pomaly vyvoj, slaby vykon, ktery se musi preprat investicemi do harware. Nic podstaneho krome brandu "Java" do neprinasi. Java je neco jako americke nemovitosti. Nacpalo se do toho tolik penez, ze si nikdo nemuze dovolit rict ze je spatne, jinak se by se zhroutily akciove trhy. Jeden kolega (stary mazak) rika Java je pokus jak privest vyvoj software na zcesti, ktery se podaril. Bohuzel to nerika jako vtipny bonmot, ale jako konstatovani smutne skutecnosti.
-
Tomas (neregistrovaný)
A co tedy místo Javy? Cobol, C,objectiveC, VB, C#, Ruby, Lisp, Haskel? Zahrňte prosím do své úvahy robustnost (no malloc-free hell), čitelnost (žádné zběsilé přetížené operátory), udržovatelnost, aktuální dokumentaci a další věci potřebné pro dlouhodobou a velkou investici do software.
-
Rejpal (neregistrovaný)Tak zrovna Haskell je docela pěkný příklad... Dost dobře se poddává formální verifikaci programů, dá se v něm realizovat spousta lock-free datových struktur (STM, žádné deadlocky)... Už jsem zaznamenal, že se k němu obracejí i nějaké ty finanční instituce, snad Credit Suisse začíná převádět svůj analytický SW na Haskell. Největší průser s Javou je v tom, že její concurrency model je tak uboze primitivní, že si pak lidi myslí, že concurrency je složitá věc. No jo, ale když Java má tyhle prostředky na úrovni assembleru, tak se pak není co divit. Už i Microsoft se vrhnul na STM (http://research.microsoft.com/~tharris/papers/2005-ppopp-composable.pdf), jsem zvědavý, co jim z toho vyleze.
-
LENIN POWER! (neregistrovaný)My v Jave vyvyjime hodne a pokud muzu srovnat dobu vyvoje projektu s lidma co delaji vetsi veci v LAMPU (zakaznik vyzaduje) tak jsme mnohem rychlejsi (a tudiz levnejsi), vykon Javy je ok, vetsina dnesniho softu nedela zadnou tezkou matyku a vetsinou ceka na odpoved ze site nebo z db a pokud je treba nejaka tezsi matyka jako treba encodovani videa, tak normalka volame xvid kodek stejne jaky kdybychom to meli v C.
Kdyz pisete drahy vyvoj, pomaly vyvoj tak ve srovnani s cim? Python, Ruby, PHP, C, C++? Hardware je dneska strasne levny, kolik stoji 1GB RAM a kolik stoji quadcore procesor. Srovnejte cenu hw a cenu programatorske prace, no kolik bere j2ee programator ? Tady 6+ klacku, prumer tak 8 a porad jeste je jich nedostatek, vzdycky by nam bodli dalsi schopni lidi.
Koupit rychlejsi hw je nejlevnejsi mozne reseni ve srovnani stravit tydny nejakou uber optimalizaci pri ktery si zaprasite datovy model a aplikaci. Navic pro Javu existuji opravdu vyborne tooly od Rational SW, s tema je radost pracovat a generuji panu programatorovi prvni posledni. Asi nejslabsi casti rational baliku je ten clearcase vcs, celkova jeho koncepce je rozhodne netradicne pojata.
Je fakt ze nejsme vyvojarska firma, primarne kodime pro sebe ale pokud to obchod vyzaduje, tak v ramci dobrych obchodnich vztahu holt kodime i pro partnery. Tim myslim pro ty co s nima spolupracujeme uz na jinych projektech nebo spolupracovat chceme a tak je v nasem zajmu aby meli kvalitni soft.
Tim chci rict ze nemam sajn o tom jake IT technologie doporucuje ceska komercni vyvojarska firma svym zakaznikum, rad se necham poucit.
