MariaDB vs Postgres vs SQL Server

[PanVP]

Pokud nejste schopen obhájit jeho výhody, tak to asi nestojí za to :-)

Safra, tak to mě jako hlavního markeťáka z Mongo asi vyhodí....moment, já s nimi nemám nic společného! Tak to mi je u zadekle 

MSSQL .. šáhli ... Nijak zvlášť to nepromýšleli.

To je pravda, ostatně MSSQL celkem slušně obslouží jak velmi malé projekty, tak i ty velmi rozsáhlé včetně HA.

MSSQL má několik výhod, pro administrátora poměrně přehlednou administraci, když se na to podíváte po roce, stejně si naklikáte to, co potřebujete. Některé jiné databáze jsou pro administrátora nepřívětivě a tak se jim dost brání.
MSSQL nabízí v kombinaci s VisualStudiem skvělé vývojové prostředí, integrace jsou tam tak dokonalé, že by to váš mozek zřejmě ani nezpracoval.
MSSQL běželo na Windows Serveru, což je i dnes naprosto zásadní argument, mnoho firem si jako první pořizuje Windows Server a pro nějaký účel i MSSQL (WSUS, docházkové systémy, evidence), takže když už nějaký tool mají, používají ho.
A mohl bych pokračovat.

NoSQL databaze jsou dobre tak leda jako doplnkove k Relacnim

Je vidět, že to hrubě podceňujete. Co vím, tak inženýři pracující na MySQL se snaží "zkopírovat MongoDB" (asi dost silné tvrzení, ale něco na tom je). Nové verze MySQL by snad měly podporovat jak SQL tak i NoSQL, resp. co vím, mluvilo se o tom. Jaký je aktuální stav, to skutečně netuším.

https://www.mysql.com/products/cluster/nosql.html

[Reklama]

[BoneFlute]

To je otázka interface - a když použijete Linq, tak ani nemusíte vědět, co je pod tím. Ale pokud nepoužijete opravdovou objektovou databázi, tak stejně bude docházet k nějakému mapování

Ta degradace databáze na storage má svoje výhody (máte méně kódu), ale i svoje nevýhody (nikdo jiný než vaše aplikace) neumí s daty pracovat - nemáte garantováno, že vám někdo externě naleje data ve správném formátu. A při exportu musíte načítat generické json - ta data mohou být relativně komplikovaná, protože mícháte víc entit do jednoho dokumentu. U relační databáze máte vstupně výstupní formát mnohem jednodušší (není rekurzivní) a garantuje vám ho databáze.

Domenove objekty ve vasi aplikaci mezi sebou maji vazby, ktere tvori graf, a ne strom. Jakym zpusobem grafove zavislosti ukladate do MongoDB? Vsude vidim jenom priklady na ukladani stromovych vazeb.

...a to je mi právě záhada, proč se více neuchytily a nerozšířily objektové databáze. Podle mě by v pohodě nahradily 90% případů, kdy je sql použita neoptimálně a de fakto zbytečně. Dnes se do této oblasti tlačí NOSQL a dokumentové databáze, ale to mapování opět bolí.

Nemohlo by to být tím, že zatímco relační algebra je jasný, matematicky propracovaný systém, kde jsou problémem spíše uživatelé, tak u objektů je problém si jen ujasnit, co je "správně objektově"?

[Miroslav Šilhavý]

@Pavel Stěhule

Ahoj,
docela rád jsem si přečetl, cos psal kolem MySQL 8. Nikdy jsem se na to nedíval (mysql / mariadb jdou skoro úplně mimo mě). Nicméně jsem zavětřil, že Oracle s tím jde dopředu - onehdy jsem chtěl trochu zlepšit práci se SQL na jednom cizím projektu, a zjistil jsem, že MySQL už má implementované lateral joiny (nevím jak dobře), MariaDB zatím ne. Takže s jistotou se ty databáze od sebe odklánějí.

Trabl je, jaks psal, práce s MySQL se obyčejně pojí u programátora s neznalostí relační práce, takže nevím, jestli to v praxi moc pomůže. Ten, kdo relační databáze aspoň trochu umí, tak se MySQL vyhýbá obloukem. I ta nejasnost, jaké záměry Oracle s MySQL má, je trochu nepříjemná.

Pro NoSQL nenašel žádné rozumné použití. Jak se zde psalo, ten, kdo umí relační databáze, pro něj to moc velký přínos není. Nicméně, ani mysql, ani nosql nezatracuju. Docela chápu, že v dnešní době je potřeba hrnout projekty a není možné sehnat znalé pracovníky. Při zaměření na projekt, bývá zajímavější ho rychleji vypálit a nežádat si velké odborníky na všechny oblasti. Průšvih nastává, když se projekt stane úspěšným - pak se rychle naleznou slepé uličky, na přepis není čas a peníze, takže se to (často marně) dohání železem a různými nesystematickými urychlováky.

No, taková je doba.

[Pavel Stěhule]

@Pavel Stěhule

Ahoj,
docela rád jsem si přečetl, cos psal kolem MySQL 8. Nikdy jsem se na to nedíval (mysql / mariadb jdou skoro úplně mimo mě). Nicméně jsem zavětřil, že Oracle s tím jde dopředu - onehdy jsem chtěl trochu zlepšit práci se SQL na jednom cizím projektu, a zjistil jsem, že MySQL už má implementované lateral joiny (nevím jak dobře), MariaDB zatím ne. Takže s jistotou se ty databáze od sebe odklánějí.

Trabl je, jaks psal, práce s MySQL se obyčejně pojí u programátora s neznalostí relační práce, takže nevím, jestli to v praxi moc pomůže. Ten, kdo relační databáze aspoň trochu umí, tak se MySQL vyhýbá obloukem. I ta nejasnost, jaké záměry Oracle s MySQL má, je trochu nepříjemná.

Pro NoSQL nenašel žádné rozumné použití. Jak se zde psalo, ten, kdo umí relační databáze, pro něj to moc velký přínos není. Nicméně, ani mysql, ani nosql nezatracuju. Docela chápu, že v dnešní době je potřeba hrnout projekty a není možné sehnat znalé pracovníky. Při zaměření na projekt, bývá zajímavější ho rychleji vypálit a nežádat si velké odborníky na všechny oblasti. Průšvih nastává, když se projekt stane úspěšným - pak se rychle naleznou slepé uličky, na přepis není čas a peníze, takže se to (často marně) dohání železem a různými nesystematickými urychlováky.

No, taková je doba.

Můžeme si poplakávat po rameni, že vývojářům chybí znalosti, anebo je to můžeme zkusit naučit. SQL a relační databáze vymýšleli chytří lidé, a měli ještě dost času, aby to mohli vymyslet důkladně a důsledně (a od té doby uteklo 40 let, takže byl čas na to aby uzrálo). Ale bylo vymyšlené pro policajty, a pro agenty FBI, pro obyčejné lidi. A navíc dneska po 40 letech nemusíme řešit stejná omezení jako tehdy - kdy na nejlepších univerzitních počítačích byl 1MB paměti a 1GB disk byl sen.

To je jediná cesta. Všechny ostatní cesty vedli k tomu, co máme teď. Problém je, že v téhle době většina lidi (včetně mne), používá různé technologie bez dostatečných znalostí (někdy ty informace nejsou, někdy nejsou uspořádané, ...) ale dost často je to jen z toho důvodů, že si neumíme uspořádat práci nebo život, a udělat si čas, abychom dřív než něco začnem dělat, se naučili ovládat ty technologie, které jsou potřeba. A tím, že napřed děláme, a pak se učíme, tak je fůra věcí špatně - věci jsou špatně navržené, špatně realizované, lidi mají horší produktivitu a jsou vyčerpaní, a flegmatičtí, všichni si zvykli, že každý rozumí všemu (nějak - málo). Je rozdíl dělat něco a rozumět tomu, co dělám, nebo dělat něco a netušit která bije.

[Miroslav Šilhavý]

Můžeme si poplakávat po rameni, že vývojářům chybí znalosti, anebo je to můžeme zkusit naučit. SQL a relační databáze vymýšleli chytří lidé, a měli ještě dost času, aby to mohli vymyslet důkladně a důsledně (a od té doby uteklo 40 let, takže byl čas na to aby uzrálo).

Máš nápad, co s tím reálně? V rámci svých omezených schopností a možností to dělám pro své lidi - a povětšinou s úspěchem. Jsou pak pro to zapálení a využívají to rádi, automaticky, bezbolestně. Jenže mi přijde, že je to málo a poměrně drahé (užit každého nováčka extra).

[Reklama]

[Pavel Stěhule]

Můžeme si poplakávat po rameni, že vývojářům chybí znalosti, anebo je to můžeme zkusit naučit. SQL a relační databáze vymýšleli chytří lidé, a měli ještě dost času, aby to mohli vymyslet důkladně a důsledně (a od té doby uteklo 40 let, takže byl čas na to aby uzrálo).

Máš nápad, co s tím reálně? V rámci svých omezených schopností a možností to dělám pro své lidi - a povětšinou s úspěchem. Jsou pak pro to zapálení a využívají to rádi, automaticky, bezbolestně. Jenže mi přijde, že je to málo a poměrně drahé (užit každého nováčka extra).

Já si myslím, že je základ se vykašlat na nějaké čistě ekonomické kalkulace. Tenhle měsíc jsem pomohl jedné firmě - jenom indexama a identifikací špatných dotazů (špatně napsaných, zapomenutých) jsme snížili zátěž na db serveru co se týče CPU 50x. Tím se jednak odstranila nutnost implementace horizontálního škálování (čímž se dost zjednodušil provoz, a ušetřilo se za tu implementaci), druhak na stávajícím železe se zvládá provoz s velkou rezervou (praktickou pro nečekané špičky, nečekané situace). Tipoval bych, že pro tu firmu jsou to úspory v řádek stovek tisíc (od pracnosti, nákladů na železo, až po snížení rizika platby penále). Přitom jsem nedělal nic, co by se nedalo proškolit za dva tři dny - a lidi se kterými jsem pracoval nejsou nějaká ořezávátka. Ale jak by se to reálně vyčíslilo. Ve firmách potkávám lidi bez energie, projekty se oddalují protahují, nikdo se nechce pustit do některých věcí, protože tomu nerozumí, ale nahrne se to na ně. Jak tohle by se ekonomicky vyčíslilo? Je celá řada nákladů a benefitů, které nejdou ekonomicky vyčíslit, takže je potřeba se odprostit jen od ekonomického uvažování.

Potom, každý člověk ve firmě by pro to, co dělá, měl dostat adekvátní proškolení (od někoho, kdo umí školit, a kdo má požadované znalosti), a to dřív než začne cokoliv dělat (a dejme jednou jednou do roka přeškolení na novější verze případně zopakování). Může to být klidně interní člověk, pokud je v dané technologii na slušné úrovni. Normální člověk nemá čas, prostor se věnovat svojí práci a ještě si udržovat přehled a udržovat kvalifikaci. To je utopie. Dejme tomu, že mám nějakou zkušenost v databázích, a stejně nemám přehled o všech novinkách. Ale se svojí kvalifikací zvládnu odfiltrovat sračky a marketingové žvásty, kterých je 99% kolem nás. To člověk, pro kterého nějaké téma není koníček a denodenní práce (a ještě musí mít nějakou kvalifikaci) nemůže dát.

Myslím si, že se tohle dost podceňuje - ve slušnějších firmách firmy platí školení - ale kolikrát už neřeší, jestli na tu práci, kterou člověk dělá je proškolený, a neřeší, že člověk zapomíná (když se nějaká znalost dennodenně nepoužívá), neřeší, že lidé stárnou, a že se dost mění technologie. Firmy by si měli budovat týmy, kde každý by měl mít základní přehled všech technologií, se kterými se může setkat (a měli by to vysvětlovat lidi, co učí - nikoliv lidi, co dělají marketing), a minimálně pro každou technologii by měl být v týmu člověk, který aspoň ví, co neví. Samozřejmě, že je to drahé, ale jak je drahé mít v týmu lidi, co neví, co dělají. Buďto neudělají nic, anebo udělají blbost (v dobré víře). Změnou algoritmu jsem vyřešil problém (za den), na kterém jiný programátor pracoval (intenzivně) půl roku.

Já sám, kromě komerčních školení, školím co to jde, a každého, kdo chce poslouchat. Ale to gró je na firmách. Které by si měli pamatovat, že odbornou práci maji dělat odborníci. A že ti na stromech nerostou. Je potřeba si je vychovávat, a držet si funkční týmy. Není to jen o penězích, je to o kultuře ve firmě, o atmosféře. Znám šikovný tým, co mně překvapuje, co dokáže dělat, a je to parta ve státním podniku. V podstatě stačí jenom myslet a používat hlavu.

[registrovany123]

Pokud někdo hodně ujíždí na SQL jazyce je Postgres asi nejlepší volba. Společně s CitusData z toho lze udělat celkem zajímavý systém.

Zmíněná SQLite je vynikající věc, testoval jsem v tom síťovou analýzu (gis extenze) a nemám žádné výhrady na to jaké to je koťátko. Limit ale je jasný - víceuživatelský přístup a tedy velmi specifické využívání. SQLite je ale dneska skoro všude kam se člověk podívá.

SQLite pouziva napr. Apple Messages (psani SMSek z laptopu). A jeste u nejakych dalsich utilitek jsem to videl. Nevyhoda je, ze do toho souboru muze zapisovat pokud vim vzdycky jen 1 proces, a potom ze v zakladu je SQLite docela osekane a chybi tam nejake elementarni veci ktere jsem povazoval za samozrejmost - uz si nepamatuju ale co to bylo. Ale da se to tam nejak doinstalovat pluginem.

[Ondrej Nemecek]

...a to je mi právě záhada, proč se více neuchytily a nerozšířily objektové databáze. Podle mě by v pohodě nahradily 90% případů, kdy je sql použita neoptimálně a de fakto zbytečně. Dnes se do této oblasti tlačí NOSQL a dokumentové databáze, ale to mapování opět bolí.

Nemohlo by to být tím, že zatímco relační algebra je jasný, matematicky propracovaný systém, kde jsou problémem spíše uživatelé, tak u objektů je problém si jen ujasnit, co je "správně objektově"?

Nemyslím, že by to byl ten problém. „Správně objektově“ je prostě to, co daný programátor napíše. Databáze mu do toho nemluví - ta má jen object graph uložit a opět načíst. Problém může být nejednotný dotazovací jazyk (stejný problém jako u  ORM) a samotný princip object graphu - poznat, co se kde změnilo a do jaké úrovně to ukládám. Udělat to plně automaticky asi není snadné (s detekcí cyklů a kolizí) a pokud musí vše řešit programátor např. implementováním nějakého předepsaného rozhraní, tak má dost práce navíc. Ale stále mi přijde, že by u malých databází by leckdy stačila in memory databáze se atomickým dumpem paměti.

Abych nebyl škarohlíd, nějaké pokusy existují, zajímá mne hlavně java a tam (nepočítaje v to zaniklou db4o) existuje např. MapDB, ZooDB, pcollections nebo asi nejprogresivnější MicroStream.

[Jan Karasek]

kdyz uz se ta diskuze rozbehla obecnejsim smerem, tak bych taky rad na neco upozornil.

Mnozi, kteri zde jiz desetileti ctou si jiste vsimli, ze pan Stehule a ostatni relacni evangeliste neustale hovori o tom, jak jsou relacni databaze bezvadne a jak je to vlastne jednoduche. A v dalsi vete pak poznamenaji, ze kazdy den chodi k zakaznikum a opravuji u nich ty spatne navrzene modely, doplnuji chybejici indexy a jsou zdeseni, ze obrovska vetsina uzivatelu  neni s to napsat i jednoduchy prikaz s nejakym joinem. Jak pan Stehule zde v diskuzi uvedl, pred nedavnem u zakaznika zrychlil chod rel. databaze 50x. To je zajimave, predstavte si, ze pouzivate produkt, jehoz jedna zakladni vlastnost se muze i 50 x lisit.
Ja si myslim, ze tady neco skutecne nehraje. Budto je ta technologie tak spatna, ze vetsina uzivatelu/programatoru neni schopna ty relacni databaze rozumne pouzivat a nebo je to skutecne tak jednoduche a slo by to naucit, ale ta technologie vyzaruje jakousi karmu, ktera odrazuje i ty, kteri by se to naucit chteli.
Presto je mozno na zaklade diskuze odpovedet tazateli nasledovne:
- at uz se zvoli jakakoliv jmenovana databaze, tak ten navrh a provedeni bude statisticky mizerne a vykon suboptimalni
- budto to bude statcit a pak je to OK
- nebude to stacit a je treba zavolat ty odborniky pro tu kterou databazi - u postgresql  vime ze existuji minimalne 4 lide
Tazatel tedy musi pouze zjistit, jake kontakty jsou k te ktere databazi k dispozici. Je to vlastne jednoduche.

[Miroslav Šilhavý]

To se netýká jen práce s databází. Často jsou celé aplikace psané tak, že se na nich nedá výkon škálovat.
Programátoři se neradi zajímají o takové "detaily", že server je jen stroj, má jen určitou paměť, počet jader procesoru. Nezajímá je, že nelze nastavit např.  PHP tak, aby byl povolený běh scriptu desítky sekund a zároveň, že se nezahltí FPM a nepřestane přijímat další požadavky (v lepším případě).

Programátoři by podle mě měli vědět, že existují limity technologií, jaká je náročnost algoritmu, jak se dá škálovat a jak optimalizovat (třeba v budoucnosti). Netýká se to jen SQL.

Pocit, ať to napíšu, jak to napíšu, bude to fungovat, a když ne, tak se zaplatí vyšší výkon serveru, prostě není platný. Co funguje dobře v malém a bez dat, nemusí vůbec jít škálovat do velkého. Pokud script běží 100 ms, za sekundu jich prostě neobsloužíte víc jak 10 x počet jader, a to ještě v úplně ideálním případě. Pokud chcete vyřešit i střední odezvu, tak mnohem méně.

Programátor nemusí umět spravovat server, nastavovat databázi, umět dokonale určit vhodné indexy. Ale měl by umět poznat, kde je potřeba se zeptat - správce serveru, SQL specialisty, a dalších. Problém tedy není v tom, že neumí vše, ale že ani neví o tom, že to někdo jiný umět může a dokáže poradit.

Toto nezachráníte žádnou magickou technologií, ale širším přehledem - celkově, vzděláním v oboru.

Práce s relačními databázemi má aspoň tu výhodu, že tam ten prostor pro optimalizaci obvykle nějaký zůstává a někdy i obrovský. U jiných vám nezbude, než škálovat horizontálně, což taky není žádný med, zbytek aplikace na to musí být připravený (což třeba běžná aplikace v PHP prostě není ani vzdáleně).

[Pavel Stěhule]

kdyz uz se ta diskuze rozbehla obecnejsim smerem, tak bych taky rad na neco upozornil.

Mnozi, kteri zde jiz desetileti ctou si jiste vsimli, ze pan Stehule a ostatni relacni evangeliste neustale hovori o tom, jak jsou relacni databaze bezvadne a jak je to vlastne jednoduche. A v dalsi vete pak poznamenaji, ze kazdy den chodi k zakaznikum a opravuji u nich ty spatne navrzene modely, doplnuji chybejici indexy a jsou zdeseni, ze obrovska vetsina uzivatelu  neni s to napsat i jednoduchy prikaz s nejakym joinem. Jak pan Stehule zde v diskuzi uvedl, pred nedavnem u zakaznika zrychlil chod rel. databaze 50x. To je zajimave, predstavte si, ze pouzivate produkt, jehoz jedna zakladni vlastnost se muze i 50 x lisit.
Ja si myslim, ze tady neco skutecne nehraje. Budto je ta technologie tak spatna, ze vetsina uzivatelu/programatoru neni schopna ty relacni databaze rozumne pouzivat a nebo je to skutecne tak jednoduche a slo by to naucit, ale ta technologie vyzaruje jakousi karmu, ktera odrazuje i ty, kteri by se to naucit chteli.
Presto je mozno na zaklade diskuze odpovedet tazateli nasledovne:
- at uz se zvoli jakakoliv jmenovana databaze, tak ten navrh a provedeni bude statisticky mizerne a vykon suboptimalni
- budto to bude statcit a pak je to OK
- nebude to stacit a je treba zavolat ty odborniky pro tu kterou databazi - u postgresql  vime ze existuji minimalne 4 lide
Tazatel tedy musi pouze zjistit, jake kontakty jsou k te ktere databazi k dispozici. Je to vlastne jednoduche.

Ty problémy by měla každá databáze - nejen SQL, ale i NoSQL. Jde jen o to, jakým způsobme přistupujete k datům - jestli sekvenčně nebo použijete index. Možná u NoSQL by bylo problémů míň, protože nepálíte výkon kontrolou referenční integrity, a ACIDem (ale pak ani nechci představit, v jakém stavu budou data).

V IT dělá každý, kdo má ruce. A většina programátorů vůbec netuší, jak databáze ale i aplikační servery mohou být rychlé. Aplikační servery z dob před 20 roky, na kterých běžely bankovní aplikace pro tisíce uživatelů měly výkon dnešních mobilů. Výkon se místo znalostí dohání silou. Je to pomalé - tak tam dáme cluster 10 serverů. Co na tom, že provoz bude 10x dražší a P.B. ví o kolik administrativně náročnější (a kolikrát stačí přidat 5 indexů - na tom snad žádná magie není). Relační databáze neškálují, jít na ně silou prostě nejde. Mongo se moc nevzpírá. Ale je blbost mít 10 serverů, když by se vám jeden flákal.

[PanVP]

A většina programátorů vůbec netuší, jak databáze ale i aplikační servery mohou být rychlé.

Ač jsem jeho názorový oponent - NoSQL databáze považuji za velký přínos a těším se, až MySQL přijde s hybridním řešením SQL i NoSQL databáze - musím se tady pana Stěhule zastat

V USA přijdete do školy na obor programátor a řeknete "chci být specialista na databáze".
Oni vám to umožní.

Poznámka pod čarou: Peníze zde nehrají roli, protože vzdělání v USA i ČR je z pohledu nákladů stejně drahé. V USA zaplatíte víc, ale tam mají také mzdy násobně vyšší. Budovy mají ve skvělém stavu a školy jsou někde mezi lunaparkem, hotelem a vědeckým sympózime.

V ČR přijdete na školu, vyberete si obor a oni do vás řežou klackem, dokud ze školy nevypadnete nebo dokud se nevlezete do krabičky navržené před deseti lety a schválené úředníky s myšlením T602. Výsledek? Na mnoha školách vás nenaučí vlastně nic, protože investujete spoustu času do naučení se toho, co jsou síta a proč vás mlátí klackem, protože to musíte umět.

V zahraničí a není to jen USA, přijdete na školu a věnujete se PŘEDEVŠÍM tomu, co je vám milé. Mnoho lidí má třeba jen tři semestry a velmi rádi na školu vzpomínají. NIKDO je nevyhodil, zaplatili si prostě tři semestry a studovali to, co je TĚŠILO. U nás jsme měli Komenského a jeho škola hrou, ale to je výsměch...

[Standa Blábol]

To se netýká jen práce s databází. Často jsou celé aplikace psané tak, že se na nich nedá výkon škálovat.
Programátoři se neradi zajímají o takové "detaily", že server je jen stroj, má jen určitou paměť, počet jader procesoru. Nezajímá je, že nelze nastavit např.  PHP tak, aby byl povolený běh scriptu desítky sekund a zároveň, že se nezahltí FPM a nepřestane přijímat další požadavky (v lepším případě).

Programátoři by podle mě měli vědět, že existují limity technologií, jaká je náročnost algoritmu, jak se dá škálovat a jak optimalizovat (třeba v budoucnosti). Netýká se to jen SQL.

Pocit, ať to napíšu, jak to napíšu, bude to fungovat, a když ne, tak se zaplatí vyšší výkon serveru, prostě není platný. Co funguje dobře v malém a bez dat, nemusí vůbec jít škálovat do velkého. Pokud script běží 100 ms, za sekundu jich prostě neobsloužíte víc jak 10 x počet jader, a to ještě v úplně ideálním případě. Pokud chcete vyřešit i střední odezvu, tak mnohem méně.

Programátor nemusí umět spravovat server, nastavovat databázi, umět dokonale určit vhodné indexy. Ale měl by umět poznat, kde je potřeba se zeptat - správce serveru, SQL specialisty, a dalších. Problém tedy není v tom, že neumí vše, ale že ani neví o tom, že to někdo jiný umět může a dokáže poradit.

Toto nezachráníte žádnou magickou technologií, ale širším přehledem - celkově, vzděláním v oboru.

Práce s relačními databázemi má aspoň tu výhodu, že tam ten prostor pro optimalizaci obvykle nějaký zůstává a někdy i obrovský. U jiných vám nezbude, než škálovat horizontálně, což taky není žádný med, zbytek aplikace na to musí být připravený (což třeba běžná aplikace v PHP prostě není ani vzdáleně).

IMHO jsou dnesni IT zamestnanci cim dal blbejsi a linejsi.
Co se tyce relacnich databazi, rozhodne nejsem odbornik jako Pavel Stehule, prece mam s jejich vlastnostmi velice dobre zkusenosti.
Potrebne znalosti za rozumnou praci s RDBMS s pohledu vyvojare jsou tyto:
-umet definovat tabulku a select joinem, integritni omezeni
-chapat co je to index a jeho vliv na select a update
-chapat problem redundance x vykon ve forme 3 zakladnich NF
-chapat co je to transakce, jak se projevuje (forknuti dat), pochopit rozdil truncate/delete
-vedet co je to trigger a jak se pouziva
-vedet co je to explain plan
-chapat se existuje neco jako PL/SQL, kde si v primitivnim jazyce na urovni shellu vyrobim proceduralni kod
 - a kdyz vyse uvedene nestacilo, zeptal jsem se lidi s vetsi hlavou, to nastalo snad jenom  dvakrat.

Vyse uvedene mi staci ke stesti. Nic, co by normalni hlava s IQ nad 100 nepobrala za dve odpoledne skoleni.
V realu, kdyz jsem delal s Oraclem, sedel jsem u Toada a jak opice jsem klepal na ikonu sanitky (explain plan) a rypal do toho jak tak dlouho, az Toad prestal zvyraznovat cervene nested loopy. Pak par hintu, aby se jako vychozi tabulka pro join pouzivala ta vzdalena pres DBLink (byla o nekolik radu vetsi), vysledek funguje upokojive dodnes.

Staci povsechne povedomi a RDBMS se pouziva luxusne.


Zato dneska vidim magory, co tahaj megabajty resultsetu mezi DB a aplikacem, aby to pres ORM namapovali do beanu, pak nad tim provedli agregace, jehoz vysledkem je jeden KPI integer.
Pricemz to samy slo udelat s prstem v nose v PLSQL a z pohledu aplikace jeden primitivni "select genKPI() from dual;"
Jenze k tomu je potreba vubec vedet,  ze PLSQL existuje.
A kdyz uz vim, ze PLSQL existuje, pak treba i zjistim, ze Oracle podporuje Java stored procedury. Kde udelam s velice rychlym lokalnim pristupem k datum i takove ficurky jako je test pruchodnosti grafem s vyhledanim optimalni cesty podle vah.


Hlupak se strasne nadre, to plati vzdy a ve vsech oborech.

Prave mi pristal mail s HW sizingem pro jeden system postaveny kolem Elasticu, 48 CPU cores a 100GB RAM.
Podle ceniku AWS $1000 mesicne list price.
A podle meho laickeho nahledu by ty pozadavky dala dvojice postgresu (live + historic data) s TimescaleDB extenzi. Pro kazdy 8GB RAM a 4 CPU cores.

[Miroslav Šilhavý]

IMHO jsou dnesni IT zamestnanci cim dal blbejsi a linejsi.

Eufemisticky se tomu říká "specializace" a "fokus na projekt" .

[Pavel Stěhule]

A většina programátorů vůbec netuší, jak databáze ale i aplikační servery mohou být rychlé.

Ač jsem jeho názorový oponent - NoSQL databáze považuji za velký přínos a těším se, až MySQL přijde s hybridním řešením SQL i NoSQL databáze - musím se tady pana Stěhule zastat

V USA přijdete do školy na obor programátor a řeknete "chci být specialista na databáze".
Oni vám to umožní.

Poznámka pod čarou: Peníze zde nehrají roli, protože vzdělání v USA i ČR je z pohledu nákladů stejně drahé. V USA zaplatíte víc, ale tam mají také mzdy násobně vyšší. Budovy mají ve skvělém stavu a školy jsou někde mezi lunaparkem, hotelem a vědeckým sympózime.

V ČR přijdete na školu, vyberete si obor a oni do vás řežou klackem, dokud ze školy nevypadnete nebo dokud se nevlezete do krabičky navržené před deseti lety a schválené úředníky s myšlením T602. Výsledek? Na mnoha školách vás nenaučí vlastně nic, protože investujete spoustu času do naučení se toho, co jsou síta a proč vás mlátí klackem, protože to musíte umět.

V zahraničí a není to jen USA, přijdete na školu a věnujete se PŘEDEVŠÍM tomu, co je vám milé. Mnoho lidí má třeba jen tři semestry a velmi rádi na školu vzpomínají. NIKDO je nevyhodil, zaplatili si prostě tři semestry a studovali to, co je TĚŠILO. U nás jsme měli Komenského a jeho škola hrou, ale to je výsměch...

Já žádnou školu v USA nemám - jsem stavební inženýr - ČVUT Praha, Systémové inženýrství. Měl jsem kliku na kantory, měl jsem kliku na dobu, kdy jsem tam byl. Neučili nás produkty, ale učili nás technicky (inženýrsky) myslet (a i když jsem zápasil s geologií, tak aspoň člověk ví, co je buližňík, a co křemen nebo čedič). Databáze jsem se pořádně naučil, až když jsem se dostal k vývoji Postgresu - teprve, když člověk pozná vnitřek, tak pak věci začnou dávat smysl. Dobrý programátor by měl mít i technický cit, aby odhadnul, co je možné, zvládnutelné, akceptovatelné, atd. Aby včas poznal, co je blbost, a co ne.

Každý člověk potřebuje něco jiného, a každý člověk je kolem té 20tky jinak vyspělý, řeší jiné problémy. České vysoké školy (zvlášť ty inženýrského typu jsou víc o obecném přehledu, a o technickém rozvoji než o naučení konkrétních technologií a postupů). Naopak na praxi jsou zaměřené vyšší odborné školy, což je asi to, co byste si představoval (případně firemní vysoké školy - jako je ta škola od Unicornu). Mně ČVUT vyhovoval - ve svých 20 jsem rozhodně nevěděl, co chci dělat, co budu dělat, ani co je zajímavé, a co je všechno možné. To vlastně nevím dodněška. Ale fůra lidí je postavená jinak, a je na nich aby si našli školu, která jim vyhovuje (pokud chtějí studovat). Není to nutnost - je to jen jeden ze způsobů, jak se něco naučit (u těch komplikovanějších věcí moc alternativ není - asi bych nechtěl jezdit po mostu, který navrhoval samouk :-)).