MariaDB vs Postgres vs SQL Server

[Miroslav Šilhavý]

V reálu je databáze součástí celého řešení a troufnu si tvrdit, že aplikační část bývá podstatně složitější než úkoly prováděné databází. Budu-li honit maximální výkon s minimálními požadavky na HW, budu muset optimalizovat umístěním hodně logiky a výpočtů do stored procedures. Pokud to nemusím hrotit, budu se maximálně snažit udržet aplikační logiku v jednotném prostředí, nad kterým má plnou kontrolu IDE vývojářů (debugování, trasování, snadný refaktoring). Ano, třetí strana bude muset přistupovat přes aplikační API, ale to se obvykle stejně vytváří i z řady jiných důvodů. Pro mě je DB konzistentní storage, ideálně hodně rychlý pro složité joiny, ale aplikační logiku (tedy právě třeba ty zmiňované výpočty) chci držet ve zdrojáku aplikace, pokud mi to požadavky na výkon dovolí.

Volba míry abstrakce na každé úrovni se liší od projektu, o tom žádná. Přenést logiku aplikace do procedur na SQL serveru možné je, ale nebývá výhodné ji tam přenášet moc.

Spousta systémů ale funguje tak, že kromě hlavní aplikace, přistupuje k datům ještě další horda menších systémů. Některé feedují data, jiné je dolují. Ta část logiky, která je společná pro všechny tyto cesty, se právě může hodit přenést do databáze. Nemusí to být rovnou procedury, k tomu slouží pohledy a pravidla. Pokud např. záznamy nemažete, ale pouze příznakem zneplatňujete, nabízí se rovnou vytvořit view, které poskytuje pouze platné záznamy, a logiku toho, co je platný a co zneplatněný záznam pak nemusíte opisovat do mnoha (sub)systémů znovu a znovu. To ušetří starosti, umožní patřičný vhled do operací (kvůli rozhodnutí o indexech) apod.

Stejně tak se hodí, pokud lze definovat co pro celý systém znamenají "konzistentní data", aby to databáze hlídala. Něco jde řešit prostě přes constraints, něco ale vyžaduje složitější logiku napříč vícero tabulkami. Tam pak pomohou trigger procedury. Typickým příkladem z praxe je počítání DPH na dokladech. Systémy to často hlídají v UI, ve formulářové logice. Na úrovni databáze není hlídaná konzistence položek, sazeb DPH, výpočtů, zaokrouhlení - ačkoliv to jsou pravidla určená předpisy. Pak se stává, že sice hlavní aplikace přes UI pohlídá, aby data byla správně, ale jiný (sub)systém, který např. importuje data z jiného vzdáleného systému už tyto kontroly neprovede, nebo je provede podle trochu odlišných pravidel. Pak máte v databázi guláš - otevřete importovaný doklad v UI, a při uložení se Vám změní hodnoty, protože UI si je hlídá samo. Pak se programují různé ohejbáky, aby UI nezasahovalo do importovaných dat, tedy někdy provádělo kontrolu a jindy ne, ... a přitom by stačilo, aby nekonzistentní data v DB vůbec nesměla existovat.

Takové - zmíněné - triggery samozřejmě taky hned odhalí slabá místa. Např. časté lockování přístupů. Jenže to není chyba, to je přínos. Ty samé locky, nebo kontroly, by pravděpodobně musela vykonávat i aplikace - a pokud je nedělá, je to indicie, že ve zpracování existuje díra (která se v praxi může projevit jen jednou za uherský rok - ale o to hůř se pak hledá).

Když se to takto nedělá, tak sice programátoři ušetří spoustu přemýšlení a řešení a času, ale v případě problémů to spadne na admina. Ten obvykle zase nemá přehled o aplikační logice a záměru, takže má velmi omezené možnosti to vyřešit, nebo navrhnout řešení.

[Reklama]

[PanVP]

A programátoři jsou v pohodě - mají zdrojáky na jednom místě.

A kdy bys je chtěl jako mít? Na čtyřech místech?
Zdrojáky mají být IMHO na JEDINÉM místě, jen takový projekt se dá nějakou dobu spravovat.
Jak se to rozjede, začnou se patchovat různé kusy odděleně, vznikne z toho samovolně pochybný bastl.
Naopak, když se projekt předává, MUSÍ BÝT KONZISTENTNÍ!

Programátoři jdou za lepším, nebo přechází na jiné projekty.
Jak je kus zdrojáku tady a kus tam, tak se projekt předat dá, ale převzít se nedá.
Takový projekt se přebírá stylem "Hmmm, je to zprasené, dělejte si s tím co chcete, ale ať se v tom hrabe hňup, co bezhlavě poslouchá. Nejsem blbej." ...hňup se nejprve radoval, že byl pochválen ...ale pak bručel a plakal, jaký že bordel dostal na hrb...jak trpí...nakonec byl odejit, protože dvakrát poškodil data Což bylo jasné od začátku, protože se to rozjelo.

Doplním, že vtipné jsou optimalizace databáze, které se neprovádí nad zdrojem / ve spolupráci s vývojem, ale nad hotovou databází u zákazníka. A jak to dokáže zčubčit data, až se tam nahraje update, který s ničím takovým nepočítá - to je teprve sranda. V tom úplně nejlepším případě aktualizace selže! V horším případě se aktualizaci povede někomu odblokovat nebo dokončit a děj se vůle boží. Člověk se snaží psát blbuvzdorně, ale bůh pořád vymýšlí důkladnější blbce :-D

Tohle zní jako Sci-Fi, kdo by to dělal? Bohužel takových ichtylů je hromada a je to časté u zahraničního software - často OpenSource, kdy "dodělávané" moduly przní tabulky a až přijde čas aktualizace, tak to celé lehne Nejčastější to je u e-shopů, kdy custom moduly píše často naprostý šílenec, který nepoužívá jen výrobcem připravené API, ale cvičí s tím jako prase.

[Logik]

A kdy bys je chtěl jako mít? Na čtyřech místech?

Jsou dvě možnosti. Buďto to nemá vliv na kvalitu aplikace. Pak ať ji mají programátoři kde chtějí.Anebo to má vliv, který popisoval Pavel. Pak je Tvoje výtka podobná, jako kdyby zedník říkal: a to jako po mne chceš, abych dával to okno do vodováhy? Jak si programátor zajistí konzistenci DB a zdrojových kódů je na něm. Ale nemá tím "otravovat zákazníka".
Samozřejmě, logika v DB je pro programátora (obzvlášť toho, co s tím neumí pracovat) problém a prodražuje to vývoj, zesložiťuje deploy atd. atd.... Takže se prodává spousta programů "bez voken ve vodováze" a na spoustě míst - spoustě zákazníků - to stačí. Na tom není nic špatného.

Jen prostě je třeba vědět, že to není jediný správný model baráku, a že někde je ta vodováha prostě potřeba, a pak se programátor nemůže vymlouvat na svoji "lenost". Jo, může a má si to nechat zaplatit (ale zas, má to umět, pak se to neprodraží tolik).

====
A ad k denormalizaci: správný postřeh IMHO je to, že denormalizace jsou často defakto materializované pohledy. A IMHO to i osvětluje, jak se k potřebě denormalizace (která někdy nastane) postavit.

[Pavel Stěhule]

Doplním, že vtipné jsou optimalizace databáze, které se neprovádí nad zdrojem / ve spolupráci s vývojem, ale nad hotovou databází u zákazníka. A jak to dokáže zčubčit data, až se tam nahraje update, který s ničím takovým nepočítá - to je teprve sranda. V tom úplně nejlepším případě aktualizace selže! V horším případě se aktualizaci povede někomu odblokovat nebo dokončit a děj se vůle boží. Člověk se snaží psát blbuvzdorně, ale bůh pořád vymýšlí důkladnější blbce :-D

A kdybyste používali relační databázi s constrainty definovanými na straně databáze, tak se vám nemůže nic rozjet.

[Standa Blábol]

A kdy bys je chtěl jako mít? Na čtyřech místech?

Jsou dvě možnosti. Buďto to nemá vliv na kvalitu aplikace. Pak ať ji mají programátoři kde chtějí.Anebo to má vliv, který popisoval Pavel. Pak je Tvoje výtka podobná, jako kdyby zedník říkal: a to jako po mne chceš, abych dával to okno do vodováhy? Jak si programátor zajistí konzistenci DB a zdrojových kódů je na něm. Ale nemá tím "otravovat zákazníka".
Samozřejmě, logika v DB je pro programátora (obzvlášť toho, co s tím neumí pracovat) problém a prodražuje to vývoj, zesložiťuje deploy atd. atd.... Takže se prodává spousta programů "bez voken ve vodováze" a na spoustě míst - spoustě zákazníků - to stačí. Na tom není nic špatného.

Jen prostě je třeba vědět, že to není jediný správný model baráku, a že někde je ta vodováha prostě potřeba, a pak se programátor nemůže vymlouvat na svoji "lenost". Jo, může a má si to nechat zaplatit (ale zas, má to umět, pak se to neprodraží tolik).

====
A ad k denormalizaci: správný postřeh IMHO je to, že denormalizace jsou často defakto materializované pohledy. A IMHO to i osvětluje, jak se k potřebě denormalizace (která někdy nastane) postavit.

Zdrojak ma byt na jednom miste ...  v GITu, vcetne PLSQL porcedur.
A kam se to rozstrka je vec DevOpsu

Osobne pouzivam pristup, kdy je DB backend pevne definovan a constraintovan a NENI MOZNO vlozit nekonzistentni data.
Pak si nad tim udelam sadu PLSQL procedurek, ktere slouzi jako data manipulation API. Jsou delane jako atomicke operace, cele projde/cele rollbackne.
A business kod v aplikacnim serveru je krasne citelny a jednoduchy, abstrahovany od technikalii. Prakticky se v nem stridaji selecty dat a executy atomickych procedur.
Vybec nemusim resit nejake transakce a locky na aplikacni urovni, luxusni debugging a izolace chyby.
Apliakac ma pravo na SELECT a EXECUTE obajene do kratockych Service metod, nema jak rozprasit data.

A kdyz potrebuju REST API, nacpu ve Springu na ty servisni metody @Restful anotaci a hotovo.

Je ale potreba opravdu udelat navrh, ne so po hlave vrhnout do sracek a rikat tomu SCRUM.
Taky se to nehodi pro nestrukturovana data, to ka skonci prijoinovanou keypair tabulkou s datovym hnojem.

Jinak samy pozitiva a socialni jistoty.
Vysledek je udrzovatelny, prehledny, snadno predatelny.

[Reklama]

[Ondrej Nemecek]

Jak jsem se poprvé dozvěděl o MongoDB? Bylo to asi v roce 2016 a vedoucí projektu řekl "Na blbnutí s SQL nemáme čas!" Zákazník očekával rozběhnutí projektu prakticky hned. Než jsem si to osahal, myslel jsem si, že se zbláznil. Ale vývoj produktu - oproti jiným projektům - doslova uháněl. A to se zadání v průběhu projektu měnilo, jak se zákazník vyspal. S NoSQL se člověk nesoustředí na "vyšpekulování krutopřísného Joinu", ale hloubá nad svým objektem, aby lumpík dělal, co dělat má.

Představa, že Vám něco zázračně ušetří práci, je podle mě mylná. IMHO v dlouhodobějším horizontu pracnost+nákladovost srovnatelných technologií konvertuje k podobné hodnotě. Co ušetříte v denormalizaci, objeví se časem v nárocích na aplikační kód, výkon hardware nebo údržbu. Což zde bylo už opakovaně řečeno. Jinak nic proti nadšení z NoSQL, ale každé nadšení časem vyprchá a sedne si a člověk pozná limity.

Jinak Pavla Stěhule považuju za odborníka se značným rozhledem a zkušenostmi a přijde mi nesmysl obírat ho o čas nějakou neplodnou polemikou...

[jouda2]

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.

Tak pan Stěhule je kvalifikovaný odborník, takže to že najde i závažné chyby je logické. Ale dám Vám názor z opačného konce - já nejsem ani kvalifikovaný, ani odborník, ani programátor, ani DB admin, s SQL něco dělám tak jednou dvakrát do roka max na hobby projektech (na úrovni jeden dvojitý join je naprosté maximum). Neboli kvalifikace naprostá databázová lama.
Přesto mám podobnou zkušenost - i s mojí naprostou neznalostí se mi pár věcí podobného rázu čas od času na něčí produkci podaří odhalit a poradit, jak daný dotaz upravit nebo jaký index přidat.

Za mě hlavné chyba opravdu není ve složitosti SQL databází, ale u buď intelektuální úrovně, nebo naprosté lenosti na hranici s ignorantstvím (nedokážu rozlišit, výsledek je stejný) spousty (rozhodně ne všech) programátorů. Bohužel.

[jouda2]

sakra nejde edit
Ještě doplním - to co říkáte je o to horší, že podobný argument z automobilismu by byl "tady musí být něco špatně s auty a manuální převodovkou, když je možné aby (když tam necháte jedničku) jednou byly perfektně rychlé, a jindy jely maximálně 40km/h a dělaly přitom děsný kravál" - ty rozdíly nejsou v oblasti špičkový závodník vs běžný řidič, ale na úrovni autoškoly :-(

[Logik]

Jouda: Dobře řečeno

Ondra:

IMHO v dlouhodobějším horizontu pracnost+nákladovost srovnatelných technologií konvertuje k podobné hodnotě.

Toto myslím není úplně přesně řečeno. Jsou jednoduché projekty, které se do tohoto stavu niky nedostanou a noSQL tam bude o něco rychlejší (o definici tabulek). A jsou projekty, které jsou tak složité, že když je někdo založí na jednoduchých technologiích, spláče nad vejdělkem.


Prostě to chce používat šroubovák na šroubky/vruty a kladivo na hřebíky. Problém je, že

• zatímco šroubkem sešroubuješ vše (i když Ti to někdy bude trvat dýl, než to dohromady stlouct), tak kovový auto hřebíkama prostě nestlučeš
• že existují lidi, co se snaží kladivem zatlouct šroubky, a "ze své vlastní zkušenosti" pak šíří, jak jsou ty šroubky nesmyslná technologie.
• a pak existují lidé, co sice umí používat šroubovák, ale už ne šroubovačku, a tvrdí, jak jsou ty šroubky pomalé na montáž. Holt u SQL to chce mít nějaký ekosystém (např. tam kde to je vhodné ORM frameworky), které Tě od většiny práce odstíní - což znamená, že toho oproti NoSQL musí člověk umět podstatně více, aby byl efektivní.

[Ondrej Nemecek]

Ondra:

IMHO v dlouhodobějším horizontu pracnost+nákladovost srovnatelných technologií konvertuje k podobné hodnotě.

Toto myslím není úplně přesně řečeno. Jsou jednoduché projekty, které se do tohoto stavu niky nedostanou a noSQL tam bude o něco rychlejší (o definici tabulek). A jsou projekty, které jsou tak složité, že když je někdo založí na jednoduchých technologiích, spláče nad vejdělkem.

Samozřejmě souhlas.

[BoneFlute]

že existují lidi, co se snaží kladivem zatlouct šroubky, a "ze své vlastní zkušenosti" pak šíří, jak jsou ty šroubky nesmyslná technologie.

Jako profesně bývalej truhlář musím poznamenat, že šroubky se kladivem zatloukají naprosto v pohodě ;-)

[Ondrej Nemecek]

že existují lidi, co se snaží kladivem zatlouct šroubky, a "ze své vlastní zkušenosti" pak šíří, jak jsou ty šroubky nesmyslná technologie.

Jako profesně bývalej truhlář musím poznamenat, že šroubky se kladivem zatloukají naprosto v pohodě ;-)

Nás to tak učili na základce a to si nedělám srandu! Myslel jsem tehdy, že umřu - můj tatínek byl (mimo jiné) jemný mechanik a pracoval v letecké prototypové dílně - zatímco soudružka učitelka zatloukala vruty kladívkem, uf! Pak mi ještě utkvěly takové ty umělohmotné šuplery, které byly pružné, takže když člověk dorazil naměřil +- 0.5mm. Inu, totalita.

[Jan Karasek]

sakra nejde edit
Ještě doplním - to co říkáte je o to horší, že podobný argument z automobilismu by byl "tady musí být něco špatně s auty a manuální převodovkou, když je možné aby (když tam necháte jedničku) jednou byly perfektně rychlé, a jindy jely maximálně 40km/h a dělaly přitom děsný kravál" - ty rozdíly nejsou v oblasti špičkový závodník vs běžný řidič, ale na úrovni autoškoly :-(

Jsem rad, ze jste prinesl ten priklad, protoze jak rikaji v Nemecku, v kazde poradne technicke diskuzi musi byt priklad z automobiloveho prumyslu -  (to ted neni mysleno zle)

Bohuzel je to s temi priklady tak, ze se pak vetsdinou diskutuje o tom, zda je ten ktery priklad vhodny. Presto to zkusim a predkladam neco (myslim si) prihodnejsiho:

Mame cerpadlo , ktere ma cerpat do 50 metru vysky. Ale neni to ledajake cerpadlo, je to cerpadlo intergalakticke ktere cerpa jakoukoliv tekutinu za jakychkoliv podminek (jak stoji v prospektu toho cerpadla - na Sahare nebo servnim polu). Je to proste intergalakticke cerpadlo, ktere ma jen jeden hacek. Musi se to poradne nastavit. Ten, kdo to nastavuje nejlepe navstivi skolenui u znameho experta a nebo si vsechno zjisti samostudiem. Vlastne je to nastaveni toho cerpadla hracka - chce to jen chtit.

Na strojnich fakultach se v oboru hydrodynamika vyucuji jen intergalakticka 'relacni' cerpadla a o tech drivejsich se moc nemluvi. Behem vyuuky se studentum klade na srdce, ze pri pumpovani za pomoci relaacnich cerpadel je treba zohlednit tu filosofii takovych cerpadel a to jak se pumpovalo driv je treba zapomenout.

Existuje rada vyrobcu 'relacnich' cerpadel a na znamych portalech se obcas objevi otazka, zda je cerpadlo A lepsi nez B. V takovych diskuzich se pak cas od casu najdou lide, kteri upozorni, ze existuji i nadale 'nerelacni' cerpadla a ze by nebylo od veci se po takovych poohlednout.
V nasledne diskuzi si pak priznivci obou taboru vymneni dojmy typu 'u me to funguje', 'neni to vubec tezke', 's SQL se nemuzeme zdrzovat' apod.

V ramci takove diskuze priznavaji specialiste na 'relacni' cerpadla, ze v praxi nachazeji velmi casto pripady spatne nastavenych cerpadel, coz zpusobuje , ze vetsina cerpadel pumpuje nejvys do 2 metru. A zde prichazi do hry ta mocna carodejka - priroda - ktera to zaridila tak, ze 99% uzivatelu potrebuje pumpovat do tech 2 metru a proto je to sumafuk jak je to cerpadlo nastaveno. Takovym uzivatelum by stacil kybl, ale protoze vetsina 'relacnich' cerpadel je zadarmo, tak se to pouzije.

Existuji pripady, kdy je ovsem treba pumpovat do tech 50 metru. A najednou to nejde a je treba zavolat toho specialistu.  A ten zjisti, ze se zapomnelo dat sito na tom vtoku a je to vyrizene. A nebo ale take zjisti, ze se zapomnel rybnik predelit  hrazi na dve casti, ze je potreba do vody pridavat zmekcovadla (denormalizace  , ze je treba rybnich pred vypumpovanim ohrat nebo ochladit a dalsi veci, ktere by provozovatel vedel, kdyby navstivil to skoleni 'jak pumpovat s intergalaktickym relacnim cerpadlem'.

[Tomas-T]

Já vždycky trochu trpím, když vidím v nějaké databázi práci některých kolegů aplikačních vývojářů.
Databáze je plná vložených procedur, které jsou psané, jako by psali aplikaci - spousta proměnných, smyčky, kurzorové operace, user funkce, temporary tabulky do kterých postupně různě přidávají a odebírají záznamy,... aby z procedury po dlouhé době nakonec vypadl nějaký vcelku triviální výsledek.
Prostě jsou to zvyklí psát jako aplikaci a nevnímají, že rychlá a efektivní práce s daty v SQL má trochu jinou logiku.

[Pavel Stěhule]

Já vždycky trochu trpím, když vidím v nějaké databázi práci některých kolegů aplikačních vývojářů.
Databáze je plná vložených procedur, které jsou psané, jako by psali aplikaci - spousta proměnných, smyčky, kurzorové operace, user funkce, temporary tabulky do kterých postupně různě přidávají a odebírají záznamy,... aby z procedury po dlouhé době nakonec vypadl nějaký vcelku triviální výsledek.
Prostě jsou to zvyklí psát jako aplikaci a nevnímají, že rychlá a efektivní práce s daty v SQL má trochu jinou logiku.

Zní to banálně,  ale pokud chcete dělat dobře s relačními SQL databázemi, tak je potřeba znát něco o těch relačních databázích, a hlavně to SQL.

Docela dost programátorů přecházelo na SQL databáze s file databází jako FoxPro, u nás PC Fand nebo zmíněný ADABAS, a když zjistili, že jsou tam kurzory, a že se v tom dá programovat plus mínus stejně, jen ten message box tam není, tak převedly ty starší aplikace (a i sebe více méně 1:1) do SQL, a měli hotovo. Viděl jsem fakt otřesný věci v Oracle PL/SQL, zrovna tak v T-SQL. Znám i pár lidí, co ty věci napsali, a jsou to fajn lidi (a kolikrát neuvěřitelně i pracovití, a zkušení, kolikrát pokorní, skromní lidi). Problém je, že jim chybí znalostní fundament. Ti lidi si nepřečetli jedinou knížku o programování (vyjma nějakých úvodních manuálů a tutoriálů). A pak už si vystačí jenom s Googlem. Dokáží vyřešit lokální problémy, ale chybí jim znalost konceptu - a pak si nedokáží dobře zobecnit svoje zkušenosti. Google je peklo i nebe v tom, že umožní vyřešit problém, aniž by člověk musel mít znalosti.

Zrovna pro storky existuje jak pro MS velice kvalitní literatura (pro MS i v češtině), tak i pro Oracle - a to už 20-30 let.  Třeba knížky od Feuersteina jsou docela tenké a čtivé, a dají se přečíst za dvě odpoledne. Jako každá technologie, uložené procedury se nehodí na všechno, a ne každý styl programování je vhodný (jsou super na práci s daty, ale jakmile se začnou používat pro psaní UI, tak už to nefunguje). Je potřeba respektovat technologii (že se v Oracle programuje jinak než v MSQL a úplně jinak v PC FANDu nebo FoxPru, a úplně jinak s nějakým ORM), a je potřeba si o tom něco napřed načíst. V podstatě každý, kdo si přečtě dvě tři dobré knížky, tak je mezi programátorama za chvíli eso - protože skoro nikdo nečte (i mně dělá problém udržet koncentraci na nějakou knížku víc než pár dní - to by člověk potřeboval měsíc někde v klidu).

Programovat je jednoduché - a technicky zaměřený člověk na to může přijít intuitivně relativně rychle. Dobře programovat v něčem - to už intuitivní rozhodně není. Na to jsou potřeba zkušenosti, příležitost použít dostatečně dlouho nějakou technologii, mít možnost řešit problémy, řešit dostatečně komplexní úlohy. A je velký rozdíl jestli člověk začíná od nuly, nebo se opře o zkušenosti předchozích generací vývojářů.