MariaDB vs Postgres vs SQL Server

[PanVP]

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.

Mám pocit, že žijete ve světě "Šťastných skřítků". 
Ano, jsou lidé, kteří mají čas se roky v něčem vrtat, cizelovat svoje znalosti, leštit své certifikace.

No a někdo má práci:
"Proboha, zákazník řve, že na projektu XY zlobí formulář v javascriptu, proboha sprav to, nebo nám vypoví smlouvu! A až to budeš mít, prosím, hned se vrhni na ten mikrokontroler, jak nám odešel Josef do důchodu, nikdo tomu nerozumí a ty jediný to dáš! A pak, hoří ten termín s projektem vodárny! Hlavně to nějak rychle sprav, nebo bude dusno."

V zemi šťastných skřítků se samozřejmě nic takového neděje.
Každý má spoustu času si svoje dotazy modelovat, vizualizovat, testovat a precizovat jako samurajský meč.

Oproti tomu v reálném světě je tlak na rychlé naprasení za každou cenu (CC+CV), hlavně aby to fungovalo a mohlo se jít na další projekt. Proto je software v takovém stavu, v jakém je. Projekty se lepí z hromady cizích knihoven a v nejlepším případě výsledek vypadá nějak takhle: https://images.app.goo.gl/tCpW74BZRCi438vx7

Příkladem země šťastných skřítků je myslím FreeBSD (nebo nějaký podobný BSD systém, už si přesně nepamatuji).
Údajně tam programátor za den napíše v průměru JEN 6 řádků kódu, zbytek dne se zabývá řešením toho, co jeho kód ovlivní a jestli je bezpečný. Před milionem let jsem to četl tady na Rootu, jestli to je pravda netuším, ale to je země šťastných skřítků.

Já oproti tomu měl někdy za den v ruce HTML, JavaScript, C#, SQL dotazy, SQL na trigry, CrystalReports.

Což připomíná život běžného Full stack developera:
https://images.app.goo.gl/33gSDZyVvxPzfcVT7

Moralizovat z vršku potravního řetězce, kdy se člověk zabydlí na teplém místečku, je jako když Babiš s Hamáčkem rozdávají svoje rady podnikatelům s prodejnami, které jsou už několik měsíců zavřené.

EDIT: Ale to není jen váš problém, vy si děláte svojí práci, běžnější to je u magorů vedoucích, kteří říkají "Měli byste svou práci dělat lépe, programovat jako bozi a teď běžte naprasit tři úplně jiné projekty a použijte k tomu šest různých technologií...a udělejte to rychle!! RYCHLE! RYCHLEEEE!"

[Reklama]

[Miroslav Šilhavý]

@PanVP

Já myslím, že si nikdo nedělá iluze, jak fungují práce na projektu. Jenže jde o to, že uspěchaná práce na začátku znamená 5x víc problémů později. Někdy se to může vyplatit, zejména když nepředpokládáte, že projekt bude moc růst. Ale každý by měl vědět, jakou cenu za to (za)platí.

Druhá věc je to, že pokud by programátor měl v sobě aspoň ty základy RDBMS, tak by ho to při práci vůbec nezdržovalo. Sice by nesypal z rukávu vycizelovaná řešení, ale aspoň by taky nedostával části kódu do slepých uliček. V budoucnu, až by se objevila potřeba optimalizovat, byly by aspoň nějaké možnosti.

Problém je, že hordy programátorů nemají ani tu bazální znalost, aby uměli toto rozlišení provést. Ve své neznalosti si myslí, že pracují con lege artis a vůbec netuší, že by někdy stačilo opravdu jen málo.

Programátoři, kteří přehled mají, taky dělají kompromisy. Ale činí tak uvědoměle, na základě nějakého ratia.

Naopak je smutné vidět, když programátor pracuje s blbým milionem řádků v jedné tabulce a vůbec mu nepřijde podivné, že nějaké jednoduché zpracování trvá celé sekundy... Pokud je to na webu, pak ještě tlačí na admina, aby posouval limity na běhy scriptů a timeouty na http serveru a proxy na desítky sekund. Pak, když server začne nestíhat (protože není ani chráněný limity a timeouty), tak zákazník ječí ještě víc, než když nefunguje jen ten jeden formulář. Pak začne ten pravý boj. Zákazník ječí, a management hledá viníka. Admin namítá, že o problémech věděl a upozorňoval na nevhodný návrh zavčas, vývoj namítá, že mu nikdo nedal čas a prostředky to udělat lépe. Otázku, jestli za tím vším nestojí jen úplně obyčejné neznalosti, už management nedokáže posoudit (obvykle). A aby se něco udělalo, tak se většinou spíš posílí železo, doprogramují se (navíc!) nějaké aplikační zrychlováky, čímž se problém úspěšně zažene do kouta, kde na bobečku čeká na vhodnou příležitost, aby o sobě zase dal vědět.

Kritika, že by vývojáři měli znát aspoň možnosti RDBMS, je na místě!

[NaRootuJeNeskutecneDebilniRegistracniFormular]

Co myslíte - kolik "developerů" tuší, že existuje tranasction isolation level?

[Miroslav Šilhavý]

Co myslíte - kolik "developerů" tuší, že existuje tranasction isolation level?

Hůř. Kolik myslíte, že existuje developerů, kteří tuší, že existují transakce?

[PanVP]

Kritika, že by vývojáři měli znát aspoň možnosti RDBMS, je na místě!

A stejně tak by měli znát:
- hodně od bezpečnosti
- aplikace by měli na bezpečnost testovat
- měli by programy psát tak, aby se s každou verzí knihovny aktualizovaly
- měli by mít spoustu času po sobě kód kontrolovat
- měli by umět psát bezchybné testy
- měli by mít dost času pro komunikaci s uživateli
- měli by umět udělat perfektní UI
- měli by programy skládat pouze z odolných knihoven, které napíší nejlepší autoři
- měli by být v kontaktu se skutečnými odborníky, kteří rozumí problematice projektu (řízení chemičky, výroba papíru, měření velikosti vajec)
- měli by mít dost prostoru, aby nepracovali ve stresu
- měli by mít šéfa, který DOKÁŽE SVÝM PODŘÍZENÝM POSKYTNOUT POŽADOVANOU PODPORU a ne jen dementa, co je popohání
....
....
...
..
..

Mezi těmi všemi ostatními věcmi je znalost RDBMS ...tak už nějak podružná.

Šáhněte si do svědomí, jestli sám máte všechno v pořádku a jestli je ta nedokonalá znalost RDBMS opravdu to jediné, co nás trápí...

[Reklama]

[Miroslav Šilhavý]

Šáhněte si do svědomí, jestli sám máte všechno v pořádku a jestli je ta nedokonalá znalost RDBMS opravdu to jediné, co nás trápí...

Snažím se vždy posoudit (neformalizovaně), jak velké mezery v které oblasti (z těch jmenovaných) a na kterém projektu mám, a volím ten kompromis co nejvíc racionálně. Snažím se udržovat si přehled, jakým směrem se projekt může ubírat a hlídat ty části, na kterých by to mohlo narazit. Na registrační formulář, pro zákazníka, který má po 20 letech činnosti pár tisíc registrací, klidně šoupnu MySQL a ORM, ale pohlídám, že se to neobjeví na projektu, kde mám po roce desítky milionů záznamů (položek) a vím, že je nutné s nimi pracovat dál. Jenže na to musíte mít aspoň ten přehled (a toho není nikdy dost, to uznávám).

Ale taky se setkávám s vývojáři, pro které je překvapením, že by nějaká i free databáze mohla dávat mnohořádově vyšší výkon, nebo vůbec netuší, že je ORM odizoluje od možnosti optimalizací, které k tomu vedou. Nevědí, že stejná databáze může úplně stejný výsledek poskytnout mnohem rychleji, když se navrhne trochu jinak. Jsou prostě naučeni jeden jediný postup, aniž by znali jeho výhody a nevýhody.

Pokud tedy nevědí, kde jaký prostor je, pak nemohou činit ani rozhodnutí.

Co tady říkám (a mám dojem, že Pavel taky) je to, že by vývojáři měli mít právě ten vhled do těch oblastí, a aby uměli vytipovat místa a chvíle, kdy je potřeba se zeptat někoho dalšího. Tedy např.: budu programovat e-shop, který bude vše feedovat do ERP systému. Je vhodné použít ORM? Vs. budu programovat e-shop s pokročilou administrací, s požadavkem na složité výstupy, napojený na dalších 12 systémů - je ORM vhodné? Jenže na to musí vědět, že takovou otázku (si) musí vůbec položit.

[PanVP]

Takže, jinými slovy, z celého příspěvku jste si vybral jedinou věc a ještě jí otočil tak, aby vám vyhovovala a hodila se do vašeho pojetí světa

[Miroslav Šilhavý]

Takže, jinými slovy, z celého příspěvku jste si vybral jedinou věc a ještě jí otočil tak, aby vám vyhovovala a hodila se do vašeho pojetí světa

Kterou? Moje odpověď obsahovala příklad z ranku RDBMS, ale týká se všech zmíněných (i dalších) témat.

[tomas88]

Pak začne ten pravý boj. Zákazník ječí, a management hledá viníka. Admin namítá, že o problémech věděl a upozorňoval na nevhodný návrh zavčas, vývoj namítá, že mu nikdo nedal čas a prostředky to udělat lépe. Otázku, jestli za tím vším nestojí jen úplně obyčejné neznalosti, už management nedokáže posoudit (obvykle).

To je preci jednoducha situace. Vinikem je samozrejme managemnt jako takovy. Nema to davat delat skupine junioru s vidinou nizsich nakladu

[PanVP]

Vinikem je samozrejme managemnt jako takovy. Nema to davat delat skupine junioru s vidinou nizsich nakladu

Přesně tak.
Nic proti Juniorům, ale kolikrát jsem viděl, že odešli padesátiletého programátora, PROTOŽE TO CHTĚL DĚLAT, JAK SE PATŘÍ. Prostě v jednu chvíli řekl "Stát, nejprve to promysleme, dobře připravme a pak to správně poskládáme."
Odpověď vedení: Je starý! Je mu padesát! Dejte mu papuče a pytlík bomparů na cestu, ať to dělají mladí vlčáci, kteří se nebojí do klávesnice pořádně bušit! Moderní je Agilní vývoj! (Myslí si, že to znamená aplikaci napsat do zítra!)

Takže ano, tohle je 100% selhání managementu.
Hlavní problém je, že management SW firem je často líný, vyžraný, přeplacený, finančně nenažraný a nekompetentní.
Výsledkem jsou týmy, které ze všeho nejvíc IMPROVIZUJÍ, aby se to nějak stihlo.

Snem takového nekompetentního management je "moula programátor", který drží ústa a improvizací se snaží NĚJAK hasit problémy managementu.

Cituji: "V očích Němců je improvizace v podstatě až poslední možnost, krajní řešení způsobené nepřipraveností, neodborností a špatným naplánováním. Pro Čecha je naopak improvizace profesionální kvalitou, na kterou jsme hrdí."

MANAGEMENT je zodpovědný za práci svých podřízených, jejich výsledky a práci. Pokud většina lidí má problém s nějakou technologií, je to o selhání a nekompetence managementu.

V Anglickém loďstvu, pokud na lodi měli kapitána, který nedokázal svoje námořníky naučit vázat uzly, šel do vězení.
Pokud vázat uzel neuměl jeden námořník, dobrý důstojník se postaral, aby se to naučil. Pokud to uměl, ale kašlal na to, byl námořník bičován. Většina SW firem "najímá posádky" z juniorů a naopak vyhazuje ty staré, kteří by mohli ty mladé vest.

[Logik]

Výsledkem jsou týmy, které ze všeho nejvíc IMPROVIZUJÍ, aby se to nějak stihlo.

Není problém, když projekt dělá člověk v časové tísni a někde použije jednodušší a rychlejší řešení,které je špatně rozšiřitelné. To se dělo, děje a bude dít.
Problém je, když projekt dělá někdo, kdo neví, jak se to má dělat správně - a volí řešení, které nenírychlejší (na vývoj), ale je prostě blbější.
Když zatloukáš šroubek kladivem, místo co bys použil šroubovačku, tak Ti to moc času neušetří. Ale výsledek je takovej jakej je (přítomným truhlářům, pokud se pletu a existují vruty, které jdou zatlouct rozumně, se omlouvám :-) - možná jen zas já neumít zatloukat vruty? :-))

[BoneFlute]

Šáhněte si do svědomí, jestli sám máte všechno v pořádku a jestli je ta nedokonalá znalost RDBMS opravdu to jediné, co nás trápí...

Snažím se vždy posoudit (neformalizovaně), jak velké mezery v které oblasti (z těch jmenovaných) a na kterém projektu mám, a volím ten kompromis co nejvíc racionálně. Snažím se udržovat si přehled, jakým směrem se projekt může ubírat a hlídat ty části, na kterých by to mohlo narazit. Na registrační formulář, pro zákazníka, který má po 20 letech činnosti pár tisíc registrací, klidně šoupnu MySQL a ORM, ale pohlídám, že se to neobjeví na projektu, kde mám po roce desítky milionů záznamů (položek) a vím, že je nutné s nimi pracovat dál. Jenže na to musíte mít aspoň ten přehled (a toho není nikdy dost, to uznávám).

Ale taky se setkávám s vývojáři, pro které je překvapením, že by nějaká i free databáze mohla dávat mnohořádově vyšší výkon, nebo vůbec netuší, že je ORM odizoluje od možnosti optimalizací, které k tomu vedou. Nevědí, že stejná databáze může úplně stejný výsledek poskytnout mnohem rychleji, když se navrhne trochu jinak. Jsou prostě naučeni jeden jediný postup, aniž by znali jeho výhody a nevýhody.

Pokud tedy nevědí, kde jaký prostor je, pak nemohou činit ani rozhodnutí.

Co tady říkám (a mám dojem, že Pavel taky) je to, že by vývojáři měli mít právě ten vhled do těch oblastí, a aby uměli vytipovat místa a chvíle, kdy je potřeba se zeptat někoho dalšího. Tedy např.: budu programovat e-shop, který bude vše feedovat do ERP systému. Je vhodné použít ORM? Vs. budu programovat e-shop s pokročilou administrací, s požadavkem na složité výstupy, napojený na dalších 12 systémů - je ORM vhodné? Jenže na to musí vědět, že takovou otázku (si) musí vůbec položit.

Přinese mi NoSQL zajímavé výhody, nebo mohu toho samého dosáhnout pomocí klasické SQL (jak už tu bylo ukázáno)?

[BoneFlute]

Když zatloukáš šroubek kladivem, místo co bys použil šroubovačku, tak Ti to moc času neušetří. Ale výsledek je takovej jakej je (přítomným truhlářům, pokud se pletu a existují vruty, které jdou zatlouct rozumně, se omlouvám :-) - možná jen zas já neumít zatloukat vruty? :-))

Vruty se zatloukat dají, jde to rychle. Má to případ užití. Asi jeden :-)

Je to jako všude. Člověk tomu musí rozumět a zvolit správný nástroj. Jenže někdy se děje, v IT konkrétně, že se nezkoumá příčina. Například já opakovaně bojuju (jen to zmíním, nechci to znovu rozvíjet) s mýtem, že dynamické jazyky (bez statické typové kontroly) mají nějaké výhody. A přitom ve skutečnosti vznikli jen díky tomu, že jazyk bez typové kontroly je možné snáz implementovat.

Zda to je mýtus nebo není, se dobře pozná podle toho, zda to ten dotyčný dokáže obhájit. Když nedokáže, je to (pravděpodobně) mýtus.

[BoneFlute]

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 ...

Následně se nějaký trouba zeptá, ok, jaké to nerelační čerpadlo má výhody? A dostane se mu odpovědi - to musíš zkusit.

Takhle jsi to myslel? ;-)

[Idris]

A přitom ve skutečnosti vznikli jen díky tomu, že jazyk bez typové kontroly je možné snáz implementovat.

Není to spíš naopak? Je implementoval oba typy jazyků a runtime pro jazyk bez typové kontroly je těžší napsat, právě kvůli absenci garancí.