Názory k článku PostgreSQL 9.5: držte si klobouky, zrychlujeme
-
Ivan (neregistrovaný)
Nevite nekdo jaky je presne problem s MERGE? Je to opravdu nejednoznacnost specifikace anebo je problem s implementaci? Snazil jsem se neco okolo tehle problematiky najit na netu a nemam v tom uplne jasno.
MERGE pouzivam vice-mene uspesne na Oracle a mam mentalni blok si predstavit proc by to nekde melo fungovat jinak. A v cem by pouzivani melo prinaset problemy. Jedine problemy na ktere jsem narazil byly chyby v implementaci (asi je to opravdu hodne obecny a slozity problem).
-
viz projektova dokumentace UPSERTu https://wiki.postgresql.org/wiki/UPSERT
-
honza (neregistrovaný)
mel bych 2 poznamky obecnejsiho razu.
pan Stehule pise vskutku dobre clanky a ten kdo si pamatuje dobu pred 20 a vice lety a tehdejsi clanky v odbornych casopisech vi, proc tomu tak je. Pan Stehule studoval na inzenyra a to jeste v dobe, kdy vysoka skola mela nejakou uroven. Banalne receno, autorovi se to pise, kdyz se mu dostalo poradneho vzdelani.
Druha, pro mne dulezitejsi poznameka se tyka technologie SQL. Fakta uvedena v clanku potvzruji dle mne urcity vyvoj, ktery je mozno pozorovat uz nekolik let. O co mi jde?
Pred 40 lety zacal vyvoj SQL a ti, kteri si tu dobu nepamatuji mohou najit na webu zaznamy rozhovoru s pracovniky projektu System R, kteri ty zaklady SQL tvorili. Z cele rady duvodu se tehdejsi databazova vedecka elita rozhodla vytvorit deklarativni dotazovaci system s nadeji, ze 'nespecialiste' budou schopni tahat data z databazi bez pomoci informatiku. Ta predstava byla takova, ze 'zamestnanec' banky si nahledne potrebna data z databaze za pomoci nejakeho jazyka, ktery mu bude vzdalene pripominat anglictinu.
Tam, kam jsme dospeli, dokumentuje prave clanek pana Stehuleho. Pred 10 lety autor jeste tvrdil, ze za 14 dni nauci SQL kazdeho. Kdyz si tak procitam ( a nejen v tomto clanku), co vsechno dnes relacni databaze 'umi', tak to nema s puvodni myslenklou - kdy si nejaky 'nakupci' vytvori sam svuj 'pohled' na ulozena data - vubec nic spolecneho. Nakonec i minimalni pocet reakci v diskuzi k takovym clankum hovori za sebe - k veci se neda nic rici, protoze je to jednoduse receno obrovsky komplikovane. Nastalo tedy naprosto neco opacneho, nez si autori novych relacnich systemu pred 40 lety predstavovali. Neexistuje nejaka siroka skupina 'beznych' uzivatelu SQL databazi, nybrz se vytvorila nova elitni skupina specialistu, kteri jsou vubec schopni si to s SQL rozdat.
Z energetickeho hlediska dokonce mohu puvodni zamery pred temi 40 lety chapat. Relativne mala skupina specialistu vytvori system, ktery bude tak nejak 'uhadovat', co si autor SQL dotazu asi predstavoval, za pomoci AI a jinych metod si to zoptimalizuje a vyplivnou se ta pozadovana data. My lide to tahle bezne delame. Par obzlast schopnych lidi vymysli a zprovozni atomovou elektrarnu a my vsichni doma potrebujeme jen otocit vypinacem - aby bylo svetlo nemusi nikdo z nas byt atomovy fyzik.
Mam ten dojem, ze v oblasti databazi se to tak nejak nepodarilo. Dnesni bezny pracovnik v nejake firme - nejaky zasobovac, nakupci si zadna data nevytahne. Potrebuje na to nejakeho specialistu, tak jak to bylo pred 40 lety. Deklarativni forma dotazu, ktery mela beznemu pracovnikovi zjednodusit praci neprinesla tedy ocekavany vysledek. Komplikuje ovsem praci toho specialisty tim, ze ten nejdriv nejaky konkretni pozadavek musi zakodovat v deklarativni forme aby to databazovy system nasledne zase rozkodoval a prelozil do tech jednotlivych read(), write() a seek() funkci ktere tahaji z harddisku ta data.
Je zajimave, ze v diskuzich k novemu systemu HANA od SAP, je slyset stale casteji nazor, ze slibovane urychleni pri zpracovani dat se dosahne teprve tehdy, kdyz uzivatele, kteri na HANA prejdou stavajici software upravi tak, ze se maximalne vyuzije novy HANA interpreter - tedy nic jineho, nez pouziti proceduralni metodiky.
-
Tuhle diskuzi už vedeme dlouho :) - stále tvrdím a jsem si jist jak málo čím, že základy SQL naučím každého během 8 hodin (pokud ten dotyčný bude mít zájem). Základ je hrozně jednoduchý - a pro běžnou práci nákupčího, nebo zásobovače stačí na 90%. Samozřejmě, že se SQL od SQL 86 do SQL 2011 hodně posunulo - ale se znalostí základů to není o moc komplikovanější - do COBOLu to má pořád daleko. S výukou SQL neprogramátorů mám ty nejlepší zkušenosti.
Trochu něco jiného je to možná u programátorů - jednak jsou občas zmatení procedurálním přístupem - ať už za databází vidí jenom soubor nebo pole, nebo jsou zmatení OOP a zkouší do relační databáze nacpat dědičnost, což pro větší data je přílišné přiohýbání nebo jen z části tuší, co všechno relační databáze dělají nebo nedělají. SQL se můžete naučit sám, relační databáze už dost těžko - kdybych se nedostal k hackování Postgresu a fakt neviděl do vnitřností databáze, tak bych o databázích věděl tak 1% a když si vzpomenu na svoje doby před Postgresem, tak většina toho, co jsem znal o databázích bylo spíš zavádějící nebo neúplné. Ve výsledku je to docela jednoduchá technologie, ale je tu tolik mýtů, představ, že minimum lidí se dostane k podstatě. Ale to není problém té technologie.
HANA je klasické relační databázi docela dost vzdálená - koncepty, které mají smysl u relačních databází u paměťových databází tu ztrácejí smysl - jsou tam úplně jiné úzká hrdla, datový model se staví jinak - běží to na jiném železe. SQL je jen jedním z více možných interface
-
Presne tak, "moderni" programatori na modernom zeleze su uplne mimo od hardwarovej reality. V svojich hipsterskych javach plodia mnohovrstvove objekty, ktore znizuju vykon. A ked s tymto objektovym pristupom pridu k databaze, skripu zubami, ze je to pomale. :P
Proceduralny pristup ma blizsie k HW a pri pristupe k vela datam neodrbes... -
Filip JirsákStříbrný podporovatelJá si naopak myslím, že se to podařilo. Akorát i ty "nespecialisty" dnes řadíme k informatikům. Podívejte se na ty spousty lidí, kteří o databázích nevědí prakticky nic, typicky používají PHP a MySQL a dávají v diskusích dotazy typu: "Slyšel jsem o tom JOINu, že je to úžasně rychlé, a taky bych si to rád vyzkoušel, můžete mi poradit?" To je přesně ten typ lidí, kteří se velice rychle naučí používat základy toho jazyka, a typicky zpracovávají tak jednoduchá data, že to databáze díky optimalizacím zvládne i přesto, že jejich způsob práce s databází je velmi neefektivní.
Jediný rozdíl je v tom, že ten "IT nespecialista" není zároveň odborníkem v té jiné oblasti. Ale to je myslím přirozené, jakmile máte někde odbornost, která má dvě hlavní složky, rozdělí se to na dvě odbornosti. Dříve byl řidič auta zároveň jeho automechanikem, dnes jsou to oddělené profese, i když profesionální řidič ví, jak auto funguje, a dokáže si něco sám opravit, a automechanik zase umí to auto řídit. Podobně máte dnes třeba programátora e-shopu, který ale musí vědět o tom, jak takový e-shop funguje, a vedle toho máte provozovatele e-shopu (který ho plní daty, vyřizuje objednávky apod.), který o e-shopu ale přemýšlí ve stylu SQL databází (i když o tom nemusí vědět) - má tam záznamy, aktualizace, transakce...
No a vedle toho jsou pak databázoví specialisté, kteří řeší třeba zpracování velkého množství dat - kteří to ale stále řeší pomocí toho SQL, a tu úlohu by ani náhodou neuměli vyřešit "přímo", jak vy píšete pomocí read(), write() a seek() funkcí.
-
Ivan (neregistrovaný)
Divil byste se kolik lidi dneska ruznych firmach(treba v bankach) dela reporting. Tihle lide vyborne zvladaji Excel a pisou v nem i makra (i kdyz styl programovani je to hrozny) no a tihle lide ovladaji SQL. Casto treba umi jen JOIN a GROUP BY je uz velka veda. Na takovych lidech casto stoji rozhodovani managementu firem. Ono je efektivnejsi si nechat udelat report od nejakeho pseudo-programatora, nez cekat az bude dokonceny nejaky SW projekt.
K tomu aby se clovek naucil SQL k tomu potrebuje trochu vule a hlavne schopnost abstraktne myslet. A pokud jde imperativni/deklarativni, tak jsem jednoznacne na strane delarativniho programovani. Dneska uz nema cenu se s optimizerem prat a neco mu nutit, stehne jako programator neznate vsechny statisticke charakteristiky dat. Treba u Oracle to trvalo pres 10 let, ale vysledek se nakonec dostavil.
-
j (neregistrovaný)
Co je to ten nespecialista?
Mozna OT, ale osobni zkusenosti. Absolvent VS ... nejen ze nezvlada, ale on ani nevi, ze se sloupec cisel v tabulce (excelu) da secist. Dela to na stolni kalkulacce.
Stejne tak mejme ERP, kde je mozna tvorit uzivatelsky sestavu prostym tahanim policek (uzivatel si vybere z pro dany doklad smysluplneho seznamu). Tedy neco nepomerne jednodussiho nez i nejprimitivnejsi SQL dotaz. Ze 150 uzivatelu to jakz takz zvlada jediny.
SQL ma tu vyhodu, ze je to pomerne slusne univerzalni rozhrani k databazim. A ponekud vyssi vykon ktereho by mozna slo dosahnout bez SQL je v drtive vetsine pripadu nepodstatny. Pricemz tam, kde postatny je, se SQL (ani jako jazyk ani jako databaze) stejne nepouziva.
ČLÁNKY DO MAILU