Fórum Root.cz

Hlavní témata => Server => Téma založeno: registrovany123 16. 04. 2021, 21:59:57

Název: MariaDB vs Postgres vs SQL Server
Přispěvatel: registrovany123 16. 04. 2021, 21:59:57
Kdo mate zkusenosti s temito databazemi, co preferujete? Ja jsem z postgres ponekud rozcarovan, delamv nem uz 2 roky a je tam hodne bugu v query planneru - musi se to porad nejak workaroundovat. S MariaDB jsem zatim moc nedelal. A SQL Serverem jsem delal jen na VS, ale tipuju, ze to bude asi bude fungovat velice dobre.

Je tady nekdo kdo ma zkusenosti s Postgres a jeste s nejakou jinou z techto 2 databazi?
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: PanVP 16. 04. 2021, 22:05:42
A dál? Jako o co ti jde? Co čekáš?

MariaDB skvělá na ty eshopy, co občas dělám, řekněme - že LAMP byla a je klasika.
MS SQL je drahá, ale spolehlivá databáze.
PostgreSQL funguje.
Stejně to jsou všechno podobné mrchy.

Zkus si MongoDB a budeš koukat na drát, jaký s tím jdou suprový věci a jak rychle v tom některé projekty napíšeš.
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: Miroslav Šilhavý 16. 04. 2021, 22:06:24
Nepovaužuji se za velkého odborníka, ale pokud jste s plannerem v PostgreSQL nespokojený, s MariaDB budete zoufalý. Optimalizovat query nad dva, tři joiny je pro MariaDB stále ještě neřešitelný problém. Nicméně, chtělo by to rozebrat spíš na konkrétní situaci, než takto obecně. Je možné, že nevolíte správnou strukturu dotazů a query planneru nedáváte dobrou možnost pro sestavení správného plánu.
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: Filip Jirsák 16. 04. 2021, 22:06:56
MariaDB nemá smysl s těmi druhými dvěma databázemi srovnávat. PostgreSQL a MS SQL jsou ve soustě věcí srovnatelné, v některých je lepší ta, v jiných druhá. Záleží na konkrétním použití, asi bych nestavěl jednu nad druhou.

Spíš napište, s čím konkrétně máte problémy u PostgreSQL. Občas se tu vyskytuje Pavel Stěhule, ten vám určitě k PostgreSQL řekne víc.
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: PanVP 16. 04. 2021, 22:10:25
Nicméně, chtělo by to rozebrat spíš na konkrétní situaci

Tak nějak, pokud to nemá být vlákno "Zeď nářků".

Mezi námi, povedlo se mi sprasit dotazy i v MSSQL a přišel jsem na to až po roce provozu.  ::)
Ne snad, že bych čubčil data, ale nejprve Select trval desetinu sekundy, pak půl sekundy a po roce pět minut ;D
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: Pavel Stěhule 16. 04. 2021, 23:07:10
Kdo mate zkusenosti s temito databazemi, co preferujete? Ja jsem z postgres ponekud rozcarovan, delamv nem uz 2 roky a je tam hodne bugu v query planneru - musi se to porad nejak workaroundovat. S MariaDB jsem zatim moc nedelal. A SQL Serverem jsem delal jen na VS, ale tipuju, ze to bude asi bude fungovat velice dobre.

Je tady nekdo kdo ma zkusenosti s Postgres a jeste s nejakou jinou z techto 2 databazi?

Nejvíc zkušeností mám samozřejmě s Postgresem, ale znám i obě druhé databáze. U MySQL se dá mluvit o kvalitnějším planneru až od 8čky, zrovna tak implementaci joinů. U komplikovanějších dotazů na trochu větších datech může být Postgres 10x rychlejší (všimněte si, kolik nových věcí v MySQL 8 je napsáno podle Postgresu). Na druhou stranu MySQL má jednodušší planner a index optimized tables (tabulky jsou organizované podle primárního klíče). Tudíž triviální dotazy, které jdou přes primární klíč, jsou u MySQL rychlejší. MySQL má také jinak reference v indexech, díky čemuž je u MySQL výrazně rychlejší UPDATE, pokud je nad modifikovanou tabulkou hodně indexů (vyšší desítky).

Postgresu vyhovuje dobře normalizované databázové schéma - je to hodně klasická relační databáze, která je ale silná díky extenzím, a bohaté nabídce práce s daty. XML, JSON, HStore, PostGIS - tam si myslím, že je nabízí komfort srovnatelný s Oraclem, a v drtivé většině případů podobný výkon (v OLTP). Vůči MySQL má výrazně pohodlnější, bohatší SQL s větší shodou se standardem, ale na to aby to člověku k něčemu bylo, tak je potřeba umět SQL. Navíc umí věci, které běžně ostatní os db neumí - např. více sloupcové statistiky, speciální indexy - pro GIS, pro LIKE, Dávno před Oraclem, a MS Postgres uměl podmíněné indexy. Roky umí Postgres použít víc indexů nad jednou tabulkou, atd - na druhou stranu MySQL má náskok v replikacích - v multimasteru - má to dost omezení (ale to je v ok v duchu MySQL), ale na eshopy to stačí. Pro Postgres zatím žádné multimaster řešení není tak etablované. Zase naopak vestavěná primary-hot standby replikace je výrazně lepší než to, co nabízí MySQL (možná něco podobného má komerční Enterprise MySQL). Command line nástroje jsou výrazně lepší u Postgresu (např. exportované CSV je skutečné CSV, a ne něco, co se CSV někdy podobá). MySQL má naopak propracovaný MySQL workbench. Postgres je komunitní sw (vývoj není soustředěný v jedné firmě). U MySQL nebo MariaDB je vývoj naopak centralizovaný.

MS SQL je relativně starý produkt doplněný o pěkné technologie pro OLAP - paměťový column store, .. MSSQL má svoje SQL (vychází to z Sybase, a je to zajímavý mix SQL a procedurálního kódu). Je to poměrně old school - mimo ANSI/SQL - a je to hodně vzdálené Oracle (naopak Postgres je z relačních databází Oracle nejblíž - syntaxí, stylem). Postgres má lepší SQL, modernější a o  vesmír lepší uložené procedury. MSSQL naopak optimalizovat některé konstrukce - umí push aggregate, umí procpat predikáty skrze funkce. Microsoft SQL má dobré GUI a výborné datové pumpy. Postgres je UNIX databáze, a perfektně zapadá do Linuxu. Naopak MS SQL je odjakživa Win db (poslední 2 roky je i pro Linux, ale teď se Linuxové verzi nemluví). A Microsoft si vytunil SQL pro Win a Win pro SQL. Nicméně neslyšel jsem, že by byl Postgres (v OLTP) výrazně pomalejší než MS SQL. Záleží dotaz od dotazu.

U všech nových databází je optimalizace postavená na odhadech výsledku dotazu. Pokud se odhad povede (tak v 70%), tak MSSQL a Postgres a možná nový MySQL 8 budou dávat data plus mínus stejně rychle - čekáte buďto na IO nebo na RAM. Pokud se odhad nepovede - moc nebo málo, tak ten výkon může být dost tragický. Jelikož je to postavené na heuristikách, a různě nastavených konstantách, tak každá databáze má trochu jinak odhady, a tudíž dobře a špatně optimalizuje jiné dotazy. Jinak storage je ve všech případech MVCC. A jelikož typický programátor ví o db plus mínus prd, tak se přetlačuje s optimalizátorem, místo toho, aby se snažil umožnit db mít správné odhady - případně podepřít dotazy správnými indexy (což taky programátoři moc nedávají - bo neumí číst prováděcí plány (takže neví, kam dát index), a typicky znají jen jednoduchý a složený index, a tím končí.

Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: PanVP 16. 04. 2021, 23:12:18

Mluvíte o originální MySQL nebo o MáničkaSQL?

Mimochodem, po oddělení MySQL a MáničkaSQL - oba projekty se ubírají svojí cestou nebo se nějak přenáší featury z jedné do druhé?
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: Miroslav Šilhavý 16. 04. 2021, 23:31:38
Mluvíte o originální MySQL nebo o MáničkaSQL?

Verze 8 (zmiňovaná) se týká jistě MySQL. Máňa má verze 5.5 a pak až 10.0+.
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: Pavel Stěhule 16. 04. 2021, 23:38:34

Mluvíte o originální MySQL nebo o MáničkaSQL?

O MáničceSQL jsem neslyšel, ale poslední roky už se s nepotkávám s lidma, kteří píší weby, takže neznám hantýrku. To co jsem napsal ale +/- platí o MySQL, Mariidb i Perconě. Zapoměl jsem napsat, že u MySQL je možné už od 5ky mít jiný engine (což je v případě MySQL docela velký kus databáze včetně např. optimalizátoru). Vzniklo pár zajímavých engines (implementace column store). U Postgresu je tato možnost až od 12ky, kdy se ale spíš jedná jen o formát uložení dat (transakční mechanismus, optimalizátor zůstává), a teď Citus (Microsoft) releasnul první verzi sloupcového storage.

Přiznám se, že v Čechách neznám nikoho, kdo by MySQL dobře uměl, a rozuměl mu od optimalizace po konfiguraci. Jsou tu asi lidi, co umí nakonfigurovat MySQL, ale nemyslím si, že by rozuměli databázím obecně - pro ně tuning db, je tuning konfigurace (čímž se získá pár procent výkonu - ale je možné, že u MySQL to jinak nejde). Co se týče Postgresu, tak minimálně vím o 4 lidech v republice, kteří umí Postgres na top úrovni - máme i českého commitera Tomáše Vondru. Dost fíčur pro Postgres napsali češi, a je se kde zeptat. U MySQL narazíte na experty, kteří vám místo přidání indexu poradí přepis aplikace do Monga. U MySQL se problémy řeší spíš silou, u Postgresu víc inženýrsky. U MySQL je hodně prezentací o tom, jak napsat SQL dotaz - u Postgresu jak funguje optimalizátor (předpokládá se, že každý umí SQL), jak si napsat extenzi nebo jak si napsat vlastní index. MySQL a Postgres jsou dva naprosto odlišné technické světy a dvě odlišné kultury.

Z MySQL vznikly dva forky - jeden kvůli osobě zakladatele (MariaDB), a druhý kvůli rychlejší a kvalitnější opravě bugů (Percona). U Postgresu vzniklo několik forků a extenzí, které přináší technický posun, progres - EDB, Postgres Pro, Green Plum, RedShift, Timescale, Citus, .. Záleží samozřejmě, kdo se dívá a jak vidí do hloubky, ale jsou to absolutně různé světy.
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: PanVP 16. 04. 2021, 23:57:23
MariaDB

Maria -> Marie -> Máňa / Mánička.

Jinak, řekněme IMHO, MáničkaDB se používá na věci jako "Aby bylo kam ta data dávat".
Jednak to je historicky a jednak se na ní obvykle žádné větší nároky nekladou.

Projekty se optimalizovaly pro Oracle DB, osobně jsem si kdysi dělal různé certifikace na Oracle 10g a rozhodně se to nebralo style MáničkaDB "Zapnu, narvu tam data a ono to něco bude dělat."

Rozhodně se optimalizuje pro MSSQL - od pokročilých view a trigry (což se na Máně nedělalo - a v případě trigrů to snad ani dřív nešlo). Až po OLAP / datové kostky. Používá se to řekněme poněkud jinak než MáňaDB. Ale MSSQL je hodně drahé. Teď už pro svůj provoz nepotřebuje WidloServer, ale stačí tomu nějaký ten enterprise linux, což nic nemění na tom, že to je prostě dost drahá sranda.

Z mého pohledu jsou buď projekty velké, kam se použije MSSQL a cena za licenci se tam ztratí/použije se Express s limitem 10 GB (15?) nebo právě projekty "směšné", na které stačí MáňaDB.

Mezi námi, žádný ze zákazníků už nehoní ani PgSQL ani Oracle. Všichni mají MáňaDB a ti větší MYSQL. Vlastně nic mezi tím.

Takové PS: Ad Máňa DB - pokud člověk zadá apt-get install mysql a ono mu to nainstaluje MáňaDB, je to stejné, jako kdyby na instalačním USB Debianu byl instalátor Windows. Další věc je, že třeba používání datových konektorů z MYSQL proti MáňaDB porušuje licenční podmínky atd....

Doplním, že sám sebe nepovažuji za odborníka na databáze.
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: Pavel Stěhule 16. 04. 2021, 23:57:30

Mluvíte o originální MySQL nebo o MáničkaSQL?

Mimochodem, po oddělení MySQL a MáničkaSQL - oba projekty se ubírají svojí cestou nebo se nějak přenáší featury z jedné do druhé?

Až z té druhé věty jsem pochopil, že myslíte MariaDB. Někde jsem slyšel, že už MariaDB a MySQL začínají být nekompatibilní na aplikační úrovni. U MariaDB i u MySQL se objevily podobné fíčury ale v různém pořadí, ale bez toho, abych kontroloval zdrojáky ( a to se mi nechce) neumím říct, jestli tam dochází k přejímání patchů (kódu) nebo jen k inspiraci. Oficiálně se o tom moc nemluví. Na různých webech, kde před 4 rokama se MySQL a MariaDB prezentovaly společně, tak to už není. Na planet MySQL už nejsou příspěvky od lidí, kteří by dělali na Mariii. Občas se tam objeví příspěvek lidí od Percony. Podíval jsem se na planet MariaDB, a tam jsou jen věci o MariaDB a Perconě.

MySQL 8 by měla být hodně překopaná - má komplětně nový executor a optimalizátor. Po takovém zásahu už moc nejde přenášet patche, a je skorem jednodušší patch napsat znovu než portovat. Ty databáze se binárně rozjedou, a jediné co bude společné bude komunikační protokol.
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: PanVP 17. 04. 2021, 00:12:01

Doplním, že velkou konkurencí pro MánaDB (resp. jakékoliv MySQL) dnes není MSSQL, ale spíš třeba MongoDB resp. NoSQL databáze obecně. Pokud jste to ještě nezkoušel, zkuste to.
Jestliže programujete v nějakém OOP, je to úžasně rychlé z hlediska vývoje.
Vyhnete se situacím, kdy přemýšlíte, jak tabulku poskládat a pokud nepoužíváte automatizované nástroje, tak jak jí změnit. Rychlost samozřejmě hovoří ve prospěch "pořádných" databází. Ale právě MáňaDB obsluhuje 90% všech eshopů, pro které může být Mongo lepší volba.
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: Pavel Stěhule 17. 04. 2021, 00:12:56

Z mého pohledu jsou buď projekty velké, kam se použije MSSQL a cena za licenci se tam ztratí/použije se Express s limitem 10 GB (15?) nebo právě projekty "směšné", na které stačí MáňaDB.

Mezi námi, žádný ze zákazníků už nehoní ani PgSQL ani Oracle. Všichni mají MáňaDB a ti větší MYSQL. Vlastně nic mezi tím.

Asi přesnější by bylo, že žádný z vašich zákazníků nehoní Pg a Oracle.

Může být. Pokud používáte db, abyste měli kam něco uložit, tak je to jedno. A takových aplikací je hodně.

Pokud ale nad daty děláte nějakou analýzu, tak licenčně může být MSSQL drahá záležitost - to se trochu kroutí i banky a telco. A to je MSSQL vůči Oraclu za rozumné peníze. Což je prostor pro Postgres, bo na 40 CPU to trhá asfalt a nestojí vás to ani korunu.

A pak je dost firem a lidí, kteří nepoužívají db jen jako uložiště a pro ně je Postgres to pravé ořechové. A Postgres je, když se to umí, hodně rychlá a robustní databáze - běží na ní Fortuna, běží nad ní GoodData, Aukro, Job.cz a tedy až na GoodData, který má vyšší desítky serverů a možná 100TB strukturovaných dat, tak ostatní beží na pár serverech bez potřeby horizontálního škálování. Mraky podniků mají Postgres interně kvůli Jire a confluence. Jsou různé přístupy jak pracovat s databází - někomu vyhovuje MySQL a jiným zas Postgres - nebo jiné db.
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: PanVP 17. 04. 2021, 00:24:29
běží na ní

Velmi zajímavé!
Já PgSQL neodsuzuji, jen že se s tím nepotkávám.
Jsem samozřejmě rád, že PgSQL žije a že je využívaná.
Nicméně "mainstream" jsou právě MSSQL, MáňaDB a hodně na vzestupuje myslím i to Mongo.

Další výhoda MáňaDB je v tom, že běží na zařízeních Synology.
Několikrát jsem (v malých firmách) viděl systémy opřené o databázi právě na nějakém NASu.

Abych Mongo jen nechválil, je to komerční produkt a taky se dokáže slušně prodražit, klidně 5-15k USD ročně, což cenou konkuruje některým konfiguracím MSSQL (podle licenčního modelu).

Doplnění: Vaše argumenty pro PgSQL beru, nezpochybňuji a jsem za ně rád!
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: Pavel Stěhule 17. 04. 2021, 00:27:38

Doplním, že velkou konkurencí pro MánaDB (resp. jakékoliv MySQL) dnes není MSSQL, ale spíš třeba MongoDB resp. NoSQL databáze obecně. Pokud jste to ještě nezkoušel, zkuste to.
Jestliže programujete v nějakém OOP, je to úžasně rychlé z hlediska vývoje.
Vyhnete se situacím, kdy přemýšlíte, jak tabulku poskládat a pokud nepoužíváte automatizované nástroje, tak jak jí změnit. Rychlost samozřejmě hovoří ve prospěch "pořádných" databází. Ale právě MáňaDB obsluhuje 90% všech eshopů, pro které může být Mongo lepší volba.

Mongo má suprovou vlastnost horizontálního škálování, ale pokud ho nasadíte v single módu, tak to žádný rychlík není a je to dost primitivní. Každý ten model má svoje - v SQL a relačních databázích si musím rozmyslet, jak rozdělit data, ale pak je mohu jednoduše a rychle spojovat (ve starších verzích MySQL je nešlo rychle spojovat). V Mongu musím nasypat všechno na jednu hromadu, protože pak už nemám JOIN - nebo na úrovni toho nejpomalejšího, co je v relačních db. To, že tam můžu nasypat cokoliv může vést k tomu, že po X letech můsím u čtených dat verifikovat formát při čtení.  Relační databáze líp drží strukturu.

Jinak ale dnešní relační db bezproblémově umí pracovat s JSONem, XMLkem, takže určitou svobodu v ukládání tam máte také. Přidání nebo zrušení sloupce jsou na moderních relačních db (alespoň na Postgresu) roky atomické operace (jenom se mění metadata, na vlastní data se nesahá). Relační databáze (alespoň klasické) nikdy nebudou umět tak dobře a jednoduše horizontálně škálovat jako NoSQL - to relační model spolu s ACID neumožňuje (kdežto aktualizace jednoho dokumentu ve shodě s CAP teorémem je na to jako dělaná). Když nepotřebuji horizontální škálování (a eshop pro střední evropu nic takového nepotřebuje), tak nemám důvod používat NoSQL (když umím SQL). Je dobré mít přehled - jsou věci na které se relační db nehodí nebo NoSQL jsou výrazně praktičtější - třeba správa logů, fulltext, IoT, ..
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: PanVP 17. 04. 2021, 00:40:02
Když nepotřebuji horizontální škálování (a eshop pro střední evropu nic takového nepotřebuje), tak nemám důvod používat NoSQL (když umím SQL).

Myslím si, že v tomhle případě argument obracíte tak, aby seděl do vašeho vidění světa.
Velmi snadno můžete říct "Proč použít SQL databázi, když zákazník, objednávka i produkt jsou vlastně jen objekty/dokumenty."

NoSQL databáze velmi snadno obslouží většinu webových projektů, troufnu si říct, že i s úsporou 2/3 času programátora.
Jistě, pokud používáte věci jako NHibernate ... tak můžete použít SQL databázi. Jenže NHibernate je jen "rovnák na ohýbák", tedy vytváří z SQL databáze NoSQL databázi ;D

A co si budeme povídat, NHibernate je oblíbené právě proto, že spousta lidí chce udělat z SQL databáze NoSQL databázi.
Když si MongoDB zkusíte, zjistíte - alespoň v C# - že se používá snáz a příjemněji než NHibernate a to s velmi podobným výsledkem. Samozřejmě, o nějakém výkonu nemůže být řeč, ale překvapivě velké množství projektů není na rychlost citlivých.

Neberte mě prosím příliš vážně, ale zkuste nad tím popřemýšlet, jestli na tom vlastně není kousek pravdy.
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: Pavel Stěhule 17. 04. 2021, 01:17:16
Když nepotřebuji horizontální škálování (a eshop pro střední evropu nic takového nepotřebuje), tak nemám důvod používat NoSQL (když umím SQL).

Myslím si, že v tomhle případě argument obracíte tak, aby seděl do vašeho vidění světa.
Velmi snadno můžete říct "Proč použít SQL databázi, když zákazník, objednávka i produkt jsou vlastně jen objekty/dokumenty."

NoSQL databáze velmi snadno obslouží většinu webových projektů, troufnu si říct, že i s úsporou 2/3 času programátora.
Jistě, pokud používáte věci jako NHibernate ... tak můžete použít SQL databázi. Jenže NHibernate je jen "rovnák na ohýbák", tedy vytváří z SQL databáze NoSQL databázi ;D

A co si budeme povídat, NHibernate je oblíbené právě proto, že spousta lidí chce udělat z SQL databáze NoSQL databázi.
Když si MongoDB zkusíte, zjistíte - alespoň v C# - že se používá snáz a příjemněji než NHibernate a to s velmi podobným výsledkem. Samozřejmě, o nějakém výkonu nemůže být řeč, ale překvapivě velké množství projektů není na rychlost citlivých.

Neberte mě prosím příliš vážně, ale zkuste nad tím popřemýšlet, jestli na tom vlastně není kousek pravdy.

Ano - relační databáze s NHibernete může být stejně pomalá jako Mongo. Ale vaše argumentace je zcestná. Co není objektem, co není dokumentem? Samozřejmě, že můžete použít NoSQL databázi i na účetnictví (ale s ACIDem to bude pomalé, bez ACIDu nezabepečené) , a upíšete se, až budete psát reporty, a navíc vaše aplikace bude šnek - nebo to budete muset honit železem. SQL je jazyk na psaní reportů, na práci s daty. Proč bych měl používat Javascript, který je navržený aby handloval alert, když píšu report.

Uložit data je jednoduché. Na to vám stačí NoSQL databáze - na to mi stačí memcache. Ale pracovat s daty je komplikovanější, a když chcete výsledek nad miliónem řádků do pár vteřin, tak to musíte udělat dobře - nebo musíte horizontálně škálovat - a to vás stojí licence, železo - ono dobré železo na AWSku není zadarmo, a je rozdíl jestli platíte 10 serverů nebo 100 serverů.

Pravda je jen jedna. Ale každý můžeme mít svůj názor :-).

Ono je někdy nemožné odlišit příčinnu a důsledek - MySQL mělo pomalé JOINy (protože to byla primitivní jednoduchá databáze a její autor je bastlíř), jejím uživatelům to bylo jedno, protože stejně neuměli joinovat a vůbec netušili jak a proč joinovat, a joiny nepoužívali, a potom autoři MySQL nebyli nuceni implementovat JOINY. Kruh se uzavřel - v rámci komunity ok. Problém byl, že uživatelé MySQL začali propagovat názor, že JOIN je špatně, protože je pomalý, ... ale nevěděli, že to platí pouze pro MySQL.

Dost lidí se trápí s relačními databázemi, a pak vidíte, že jejich aplikace je debilně navržená, proti samotným principům relačních db. Drtivá většina eshopů, které jsem viděl jsou ukázkou jak se to dělat nemá. A pak dostanou do ruky NoSQL a jsou šťastní. Problém je, že vědí málo, jak o relačních db, tak i o NoSQL. Ale samozřejmě, že mají názor.

Každá technologie by se měla posuzovat objektivně - je to jenom technologie - a ten kdo ji posuzuje, by měl mít znalosti, nikoliv názor nebo jen zkušenost. Názory i zkušenosti jsou subjektivní. V IT chybí znalosti - zatím v IT převládají zkušenosti - tohle mi fungovalo, tohle mi nefungovalo, ale jen málokdo dokáže říct, proč něco funguje a proč něco nefunguje.
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: tacoberu 17. 04. 2021, 02:11:23
Velmi snadno můžete říct "Proč použít SQL databázi, když zákazník, objednávka i produkt jsou vlastně jen objekty/dokumenty."

NoSQL databáze velmi snadno obslouží většinu webových projektů, troufnu si říct, že i s úsporou 2/3 času programátora.
Jistě, pokud používáte věci jako NHibernate ...

A když použiju PG, v něm tabulku nosql, obsahující sloupce id a data, a do data budu ukládat dokumenty jako json; v čem jsem hůř než když bych použil MongoDB?
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: PanVP 17. 04. 2021, 02:19:34
Samozřejmě, že můžete použít NoSQL databázi i na účetnictví

Já rozhodně nepropaguji NoSQL jako lék na všechno.
Jen tvrdím, že hřebík by se měl zatloukat kladivem a kombinačky použít na štípání drátu.
Vy svým způsobem tvrdíte, že můžete hřebík zatloukat pomocí kombinaček (strčit pod eshop SQL databázi) a že vám to půjde, s jistou praxí, stejně rychle jako s kladivem. No ano. S jistou praxí hřebík pomocí kombinaček zatlučete.
Ale jestli není náhodou lepší použít kladivo. Já eshopy dělal docela dlouho a když jsem pak začal pracovat s Mongo DB, jen jsem vrtěl hlavou, kolik kódu jsem zbytečně napsal.

No a účetnictví zase je (podle mého názoru) naprostý nesmysl dělat nad NoSQL databází.

Ad trápení se s relačními databázemi.
Jedním z důvodů může být i to, že se lidé snaží napasovat kulatý dílek do čtvercového otvoru.
Tedy použít SQL databázi na něco, co se pro ní přímo nehodí. Nebo obráceně.

Ad JOINy nebo komplikované dotazy obecně.
Osobně znám člověka, který z hlavy programuje v Brainf*cku.
Netuším, jestli na to má nějaký trik nebo jestli mu mozek skutečně tak dobře funguje.
Běžnější je hrát šachy s lidmi, kteří se vůbec nedívají na šachovnici, jen tak si leží a přesto vyhrají.
Tak jestli ty problémy nejsou i nějak spojené s SQL jazykem jako takovým.
Ostatně LinQ "nás má SQL zbavit".

A v případě zpracování ohromného množství čísel - na to bude asi ještě velmi dlouho nejlepší právě SQL.
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: PanVP 17. 04. 2021, 02:29:57
A když použiju PG, v něm tabulku nosql, obsahující sloupce id a data, a do data budu ukládat dokumenty jako json; v čem jsem hůř než když bych použil MongoDB?

C# dovoluje objekt uložit přímo do Monga.
Stejně tak dovoluje tyto objekty z Monga získat.
Navíc mi dovoluje z Monga získat jen věci, které chci.
Vrať mi objekty, jejichž hodnota typ = auto a cena > 100000 a < 200000.

Nevím jak cizí, ale moje programy fungují tak, že uvedu referenci na Mongo, určím si objekty, které se ukládají do Monga a pokud chci provést změnu objektu, řeknu objektu "ulož se" a on se uloží. Vůbec se o nějakou databázi nezajímám.
Vlastně mě to zajímá jen v případě "SELECTU", kdy si na základě vlastností řeknu, které objekty chci z databáze načíst.

Ale pořád pracuji jen se svým objektem.
Práce s MongoDB je mnohem blíž NHibernate než práci s SQL databází bez ORM.
Měl byste si to zkusit, abyste to pochopil, to je nejsnazší.
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: PanVP 17. 04. 2021, 02:45:50
Doplnění: A to všechno s desetinou snahy a 20% kódu oproti blbnutí s SQL. Předtím jsem dlouho nebyl z ničeho tak nadšený jako z MongoDB.

A protože jsem nedávno potřeboval udělal logování přístupů, použil jsem na to samozřejmě MáňaSQL.
Psát "docházku" pomocí MongoDB by nedávalo smysl. Do MáňaSQL pošlu číslo čipu a triger pro insert mi do toho záznamu sám doplní čas (na serveru) a ve správném formátu.
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: Pavel Stěhule 17. 04. 2021, 05:34:43

Já rozhodně nepropaguji NoSQL jako lék na všechno.
Jen tvrdím, že hřebík by se měl zatloukat kladivem a kombinačky použít na štípání drátu.
Vy svým způsobem tvrdíte, že můžete hřebík zatloukat pomocí kombinaček (strčit pod eshop SQL databázi) a že vám to půjde, s jistou praxí, stejně rychle jako s kladivem. No ano. S jistou praxí hřebík pomocí kombinaček zatlučete.
Ale jestli není náhodou lepší použít kladivo. Já eshopy dělal docela dlouho a když jsem pak začal pracovat s Mongo DB, jen jsem vrtěl hlavou, kolik kódu jsem zbytečně napsal.


Popravdě nevím, co je na eshopu tak speciálního, že by tam nešla nasadit relační databáze. A čím by se eshop měl lišit od účetnictví, aby bylo tak skvělé pro NoSQL databázi. Moderní relační databáze vám umožní (z pohledu datového modelu) totéž jako dokumentová databáze.  Nemyslím si, že to je správný přístup, protože degradujete databázi na storage, ale někomu to může vyhovovat. A jsou use cases, kde se dokumentový přístup hodí (nebo kde se hodí nějaký hybridní přístup).

Já v Postgresu můžu mít jak relační tak dokumentový model (podle toho co se mi hodí, a podle toho, jaké operace budu nad daty dělat - např. třeba hromadné operace). V mongu máte jen dokumentový model, a když chcete dělat hromadné operace, tak si musíte před materializovat data, aby to mělo vůbec nějakou rychlost.

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.

Věřte mi, že SQL je jedna z nejlépe navržených věcí v IT. To, že ho někdo neumí používat je jen jeho mentální blok, nebo smůla, že měl špatné učitele, nebo lenost, že si neudělal čas (4-8 hodin), aby se jej naučil.
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: Pavel Stěhule 17. 04. 2021, 05:59:24
A když použiju PG, v něm tabulku nosql, obsahující sloupce id a data, a do data budu ukládat dokumenty jako json; v čem jsem hůř než když bych použil MongoDB?

C# dovoluje objekt uložit přímo do Monga.
Stejně tak dovoluje tyto objekty z Monga získat.
Navíc mi dovoluje z Monga získat jen věci, které chci.
Vrať mi objekty, jejichž hodnota typ = auto a cena > 100000 a < 200000.

Nevím jak cizí, ale moje programy fungují tak, že uvedu referenci na Mongo, určím si objekty, které se ukládají do Monga a pokud chci provést změnu objektu, řeknu objektu "ulož se" a on se uloží. Vůbec se o nějakou databázi nezajímám.
Vlastně mě to zajímá jen v případě "SELECTU", kdy si na základě vlastností řeknu, které objekty chci z databáze načíst.

Ale pořád pracuji jen se svým objektem.
Práce s MongoDB je mnohem blíž NHibernate než práci s SQL databází bez ORM.
Měl byste si to zkusit, abyste to pochopil, to je nejsnazší.

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í. U serializace objektů si můžete vybrat, jak budete serializovat - jestli jednoduše a použijete dokumentový model nebo zkusíte ORM. Obojí ale vede k tomu, že moc nebudete umět provést hromadnou operaci (vždy musíte provádět deserializaci celého objektu). Pokud nepotřebujete hromadné operace - ok, je to jedno - ale ono je většinou potřebujete - a pokud máte víc než desítky tisíc operací, tak je objektový přístup zoufale neefektivní.

Dneska už mají zákazníci s kterými pracuji větší data - TB (a to jsou strukturovaná data, nejedná se o BLOBY), a tam je parádně vidět, jak omezený je objektový přístup. U SQL databází se to dá někdy zachránit, tím že vyskočíte z ORM a ručně napíšete SELECT, někdy je to tak zmršené, že ani to nejde. A přístup k optimalizaci Monga - tak tam dejte víc serverů, to nefunguje - vy potřebujete databázi zrychlit 10x - 100x. 10 serverů vám nikdo nezaplatí. Ne každý eshop má TB dat - drtivá většina eshopů budou mít v databázi možná pár GB - a tudíž pomalá hromadná operace bude v horizontu desítek sec, což je ještě akceptovatelné - tak tam asi nemá cenu extra řešit jestli SQL nebo NoSQL. Pokud vám SQL nejde nebo se nedokážete utrhnout od OOP, tak ok, použijte NoSQL nebo SQLite, nebo dokumentový model v MySQL. Ale u větších dat to fakt nefunguje (pokud děláte hromadné operace).

Viděl jsem aplikace, které velkou část dat cpala do NoSQL databáze - kde nebyl potřeba ACID, a hodilo se horizontální škálování, a bokem tlačila přes kavku data do relační databáze pro reporting a pro účetnictví. 
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: registrovany123 17. 04. 2021, 11:43:14
Doplnění: A to všechno s desetinou snahy a 20% kódu oproti blbnutí s SQL. Předtím jsem dlouho nebyl z ničeho tak nadšený jako z MongoDB.

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.

Jakmile budu muset krkolome roubovat grafovou strukturu na stromovou a zase zpatky, tak chci videt, jak napisu jen 20% kodu oproti klasice SQL + ORM. Navic stromova struktura automaticky znamena, ze budu mit dupiicity v datech - ani nebudu rikat co z toho plyne, to mate jako programator vedet.

Relacni databaze mi umoznuje 1:1 ukladat grafove struktury do databaze, zejmena dobre se to pouziva kdyz mam Hibernate. Specializovany Select na ktery mi ORM nestaci nebo by byl pomaly si muzu napsat rucne v SQL. A vytvorit si template s kompletnim stackem DB+Hibernate+Liquibase neni problem.

A dostanu tim univerzalni stack na reseni 99% potencionalnich uloh, kterymi moje aplikace bude zatizena. Kdezto s MongoDB se bude jednat o kompromisni reseni.

NoSQL databaze jsou dobre tak leda jako doplnkove k Relacnim, na reseni urcitych typu ukolu, ktere by byly v Relacnich potencionalne moc velky opruz. Pak jsou jeste dobre pro webvyvojare, kterym dostacuje trivialnost reseni ktere jim poskytnou.
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: registrovany123 17. 04. 2021, 11:51:03
Citace
Pak jsou jeste dobre pro webvyvojare, kterym dostacuje trivialnost reseni ktere jim poskytnou.

A jeste poznamka: a jsou pro ne vyhodne zejmna pro to, ze webvyvojari pouzivani relacnich databazi a vubec nejakych pokrocilejsich technologii nezvladaji - jakmile to clovek uz umi, a pracuje v projektu s inzenyrama, tak to ztraci pointu.

Jenom jeste podotykam, ze pro "trivialni" aplikace muzu pouzit treba souborovou databazi SQLite, ktera je velice oblibena v Pythonu a je tam dokonce i ve standardni knihovne.
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: Jan Forman 17. 04. 2021, 13:33:05
Fajn diskuze možná bych přihodil, že rozdíl mezi
MySQL a MariaDB už je v úrovni jako mezi OpenOffice a LibreOffice.

Původní vývojáři jsou v MariaDB foundation a ORACLE to nějak nechává žít zřejmě pro své korporátní zákazníky.
Smysl tedy má bavit se o MariaDB 10.x

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

Microsoftí server jsem odepsal dávno a popravdě častěji se narazí na ORACLE když už klient má peníze na rozhazování.
Není mi zcela jasné, jestli někdo má nějaký use-case, kde to dává smysl.
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: Pavel Stěhule 17. 04. 2021, 14:05:46
Původní vývojáři jsou v MariaDB foundation a ORACLE to nějak nechává žít zřejmě pro své korporátní zákazníky.
Smysl tedy má bavit se o MariaDB 10.x

Tady se musím zastat Oracle - Nabrali nové lidi, a 8čka rozhodně není databáze, kterou bych označil jako dožívající. Vůči 5.7 verzi je to ohromný pokrok. Samozřejmě, že je to Oracle - a nikdo neví, co mají v plánu.

Microsoftí server jsem odepsal dávno a popravdě častěji se narazí na ORACLE když už klient má peníze na rozhazování.
Není mi zcela jasné, jestli někdo má nějaký use-case, kde to dává smysl.

Tady hodně záleží, kde se člověk pohybuje - jsou oblasti a firmy, kde MSSQL dominuje - a když si vzpomenu na rozhovor s kamarádem, který je špičkový Oraclista, a dnes už zkušený a dobrý Postgresista, tak cca před dvěma roky velice pozitivně hodnotil MSSQL vůči Oracle. Oracle je jednak drahá databáze a druhak relativně náročná na administraci. Administrace MSSQL je výrazně jednodušší - a navíc Oracle začal dost brutálně tlačit svoje zákazníky do Oracle cloudu. A komu se do něj nechce, tak tomu hodně znepříjemňuje život.
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: tacoberu 17. 04. 2021, 14:57:23
Microsoftí server jsem odepsal dávno a popravdě častěji se narazí na ORACLE když už klient má peníze na rozhazování.
Není mi zcela jasné, jestli někdo má nějaký use-case, kde to dává smysl.

Tady hodně záleží, kde se člověk pohybuje - jsou oblasti a firmy, kde MSSQL dominuje - ...
Moje zkušenost (nijak rozsáhlá samozřejmě) je taková, že MSSQL používají Windows vývojáři protože se stalo. Šáhli po tom, co se jim nabízelo, a co znali. Nijak zvlášť to nepromýšleli.
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: tacoberu 17. 04. 2021, 15:02:32
A když použiju PG, v něm tabulku nosql, obsahující sloupce id a data, a do data budu ukládat dokumenty jako json; v čem jsem hůř než když bych použil MongoDB?

C# dovoluje objekt uložit přímo do Monga.
Stejně tak dovoluje tyto objekty z Monga získat.
Navíc mi dovoluje z Monga získat jen věci, které chci.
Vrať mi objekty, jejichž hodnota typ = auto a cena > 100000 a < 200000.
Ano. To s tou mou tabulkou v PG mohu úplně stejně.

Nevím jak cizí, ale moje programy fungují tak, že uvedu referenci na Mongo, určím si objekty, které se ukládají do Monga a pokud chci provést změnu objektu, řeknu objektu "ulož se" a on se uloží. Vůbec se o nějakou databázi nezajímám.
Vlastně mě to zajímá jen v případě "SELECTU", kdy si na základě vlastností řeknu, které objekty chci z databáze načíst.

Ale pořád pracuji jen se svým objektem.
Práce s MongoDB je mnohem blíž NHibernate než práci s SQL databází bez ORM.
Takže ta výhoda je v tom, že pro PostgreSQL musím napsat drobný wraper (odhadem na deset řádek), abych dosáhl toho samého co MongoDB? To zase není tak velká cena.

Měl byste si to zkusit, abyste to pochopil, to je nejsnazší.
Je mnoho software, které si žádá mou pozornost. Pokud nejste schopen obhájit jeho výhody, tak to asi nestojí za to :-)
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: Ondrej Nemecek 17. 04. 2021, 16:25:05
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í.
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: PanVP 17. 04. 2021, 16:51:01
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  ;D

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
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: BoneFlute 17. 04. 2021, 19:23:51
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ě"?
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: Miroslav Šilhavý 17. 04. 2021, 21:12:34
@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. :(
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: Pavel Stěhule 18. 04. 2021, 05:43:15
@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.
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: Miroslav Šilhavý 18. 04. 2021, 07:42:50
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).
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: Pavel Stěhule 18. 04. 2021, 08:39:50
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.
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: registrovany123 18. 04. 2021, 12:57:19
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.
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: Ondrej Nemecek 18. 04. 2021, 22:53:31
...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 (https://en.wikipedia.org/wiki/Db4o)) existuje např. MapDB (https://github.com/jankotek/mapdb/), ZooDB (https://github.com/tzaeschke/zoodb), pcollections (https://github.com/hrldcpr/pcollections) nebo asi nejprogresivnější MicroStream (https://microstream.one/).
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: Jan Karasek 20. 04. 2021, 12:22:53
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.
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: Miroslav Šilhavý 20. 04. 2021, 12:56:13
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ě).
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: Pavel Stěhule 20. 04. 2021, 12:59:36
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.
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: PanVP 20. 04. 2021, 13:21:38
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...

Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: Standa Blábol 20. 04. 2021, 13:27:49
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.
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: Miroslav Šilhavý 20. 04. 2021, 14:23:39
IMHO jsou dnesni IT zamestnanci cim dal blbejsi a linejsi.

Eufemisticky se tomu říká "specializace" a "fokus na projekt" :).
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: Pavel Stěhule 20. 04. 2021, 14:31:14
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 :-)).
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: PanVP 20. 04. 2021, 15:04:12

V USA si můžete na VŠ vybrat čistě teoretické obory i čistě praktické nebo mezi.
Dis. má u nás asi stejný respekt jako maturita.

Podle vaší logiky by chirurg měl být diplomovaný specialista, co se to naučí "ještě navíc k maturitě", ale politolog musí být trojitý Dr. To rozhodně odmítám.

Není důvod ponižovat praktické obory, pokud se člověk naučí vše potřebné pro svojí praxi.
Podle mého názoru jsou teoretické obory na prd a buližník.

Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: Pavel Stěhule 20. 04. 2021, 15:26:15

V USA si můžete na VŠ vybrat čistě teoretické obory i čistě praktické nebo mezi.
Dis. má u nás asi stejný respekt jako maturita.

Podle vaší logiky by chirurg měl být diplomovaný specialista, co se to naučí "ještě navíc k maturitě", ale politolog musí být trojitý Dr. To rozhodně odmítám.

Není důvod ponižovat praktické obory, pokud se člověk naučí vše potřebné pro svojí praxi.
Podle mého názoru jsou teoretické obory na prd a buližník.

Každý ať studuje, to co mu vyhovuje, a co si myslí, že má pro něj smysl. Nejde mít všechno. Můžete míť buďto šírší záběr nebo větší hloubku. Každé má svoje pro a svoje proti. A zrovna tak každý člověk je nějaký, někomu od začátku vyhovuje specializace a jinému ne. A zrovna tak v práci - je dobré mít specialisty, a je dobré mít i lidi, kteří mají širší přehled. Důležité je, aby člověk věděl, co ví, a co neví. Ve stavařině nebo ve strojařině, když něco pokurvíte, tak to může zabít lidi, takže člověk by měl vědět, co dělá.
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: Jan Karasek 20. 04. 2021, 16:45:02

Ty problémy by měla každá databáze - ...... A)

V IT dělá každý, kdo má ruce. .... B)

A)
moje zkusenost je takova, ze kdyz se nepouzije SQL tak zadne problemy s SQL nejsou. U databazi jako ADABAS, SAP-DB, SolidDB, SAP Advanced Server, Faircom, BerkeleyDB nemusite vubec nikoho skolit na SQL , nikdo nevi co je referencni integrita a normalni formy, kdy se u jake databaze smi a nesmi pouzit jaky trigger   a presto je vsechno vpohode a ACID  :)
Aplikacni programatori si prectou na A4 papiru, jak se jmenuji ty funkce , ktere prectou data z databaze a jak se jmenuji ty, ktere neco zapisuji. Jedine co musi clovek mentalne uchopit je pojem indexu a k cemu je to dobre - ale to se dozvi kazdy programator v prvnim prikladu, kdy ma vytahnout z databaze vsechny faktury s datumem XX.XX.ZZZZ.

B)
jestli tomu rozumim, tak ten rozpor na ktery upozornuji - totiz SQL je jednoduchy koncept versus SQL nikde nefunguje poradne - vysvetlujetezrovna tak  jako nekolik ostatnich kolegu tim, ze uroven lidi v IT je spatna?
Ale co proti tomu delat? Udelat si lepsi lidi?
Nebylo by skutecne mozne, ze ta SQL technologie nastavuje prece jenom pro siroke vrstvy prilis vysokou latku?
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: Miroslav Šilhavý 20. 04. 2021, 17:13:10
(...) SQL je jednoduchy koncept versus SQL nikde nefunguje poradne - vysvetlujetezrovna tak  jako nekolik ostatnich kolegu tim, ze uroven lidi v IT je spatna?
Ale co proti tomu delat? Udelat si lepsi lidi?
Nebylo by skutecne mozne, ze ta SQL technologie nastavuje prece jenom pro siroke vrstvy prilis vysokou latku?

Pavel to psal. Programátorům často chybí odhad, že daný úkol musí jít vyřešit lépe, případně dostatečná znalost, aby aspoň rozeznali, že použité řešení dobře nefunguje. Když vidím jednoduchý script, který má přijmout data a uložit, nebo naopak vytáhnout malá data a odeslat, a trvá 100 ms, a programátora to nealarmuje, pak to žádná technologie nezachrání. Tam chybí elementární znalosti či zkušenosti.

Stesk nad tím, jak se používá SQL není o vysoké laťce. Pokud z jakékoliv databáze, či API, či úložiště programátor vytahuje bimbobajty dat na to, aby je zpracoval na 32bitový integer, pak mu chybí základní znalost. Znalost toho, že přenášet data je časově a paměťově náročné. Mělo by to ihned indukovat myšlenku, jak získat rovnou ze zdroje ten malý výsledek. Pokud užívá jakoukoliv databázi (nemusí to být klasická SQL RDBMS), měl by vědět, že na 99 % dokáže požadovanou operaci provést efektivněji, než kód, který si napíše na náročně přenesenými daty. Tyto základy už pak nutně vedou k tomu, že vyřeší, nebo se doptá jak vyřešit úkol lépe. Ale musí to vůbec napadnout.

Typickým příkladem je paginace na stránkách. 90 % programátorů nejdřív udělá SELECT count() a poté, ihned za ním SELECT ... ORDER BY LIMIT OFFSET, přičemž oba dotazy mají úplně stejné parametry. Programátorovi musí dojít, že je nesmysl nechat databázi vyhodnotit dotaz a spočítat počet řádků a ihned poté udělat to samé a vzít si jen pár řádků do aplikace. Dvakrát stejná práce. Opět, musí to jen napadnout. To taky není o znalosti SQL.
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: Pavel Stěhule 20. 04. 2021, 17:38:30

Ty problémy by měla každá databáze - ...... A)

V IT dělá každý, kdo má ruce. .... B)

A)
moje zkusenost je takova, ze kdyz se nepouzije SQL tak zadne problemy s SQL nejsou. U databazi jako ADABAS, SAP-DB, SolidDB, SAP Advanced Server, Faircom, BerkeleyDB nemusite vubec nikoho skolit na SQL , nikdo nevi co je referencni integrita a normalni formy, kdy se u jake databaze smi a nesmi pouzit jaky trigger   a presto je vsechno vpohode a ACID  :)
Aplikacni programatori si prectou na A4 papiru, jak se jmenuji ty funkce , ktere prectou data z databaze a jak se jmenuji ty, ktere neco zapisuji. Jedine co musi clovek mentalne uchopit je pojem indexu a k cemu je to dobre - ale to se dozvi kazdy programator v prvnim prikladu, kdy ma vytahnout z databaze vsechny faktury s datumem XX.XX.ZZZZ.

B)
jestli tomu rozumim, tak ten rozpor na ktery upozornuji - totiz SQL je jednoduchy koncept versus SQL nikde nefunguje poradne - vysvetlujetezrovna tak  jako nekolik ostatnich kolegu tim, ze uroven lidi v IT je spatna?
Ale co proti tomu delat? Udelat si lepsi lidi?
Nebylo by skutecne mozne, ze ta SQL technologie nastavuje prece jenom pro siroke vrstvy prilis vysokou latku?

Ty databáze, které tu zmiňujete jsou buďto jednoúčelová ořezávátka, nebo hodně jednoduché kousky, které toho moc neuměly, a o to víc musel umět programátor, aby z toho na tehdejším železe něco vyrazil. A zákazník si nemohl moc vymýšlet. A také bylo mnohem méně dat. Nevěřím vám, že na tehdejších databázích nebyly problémy. Hodně projektů mělo problémy, a je pravda, že železo na kterém tyto databáze běželo, tak nebylo nic moc (z dnešního pohledu), ale uživatelé byli rádi, když dostali výsledek (v hodinách). A programátoři, kteří se k těmto databázím dostali, tak nejspíš měli hodně intenzivní znalosti tunění operačního systému, možná i psaní v assambleru.

Dneska si zákazník navýmýšlí, obchodník a projekťák bez znalosti technologie odkývá všechno, a programátor musí aplikaci do dvou měsíců předat. To, co se v době ADABASu psalo 2 roky se dneska píše 2 týdny. A zákazník očekává, že na TB dat dotazy pojedou interaktivně do vteřin (protože mu to obchodníci naslibovali). Navíc tehdejší aplikace byly jednoduché - skládaly se z pár komponent, pár vrstev - žádné železo by to jinak neutáhlo. Dneska tam máte tuny balastu. A když něco nefunguje, tak dá dost práce poznat co nefunguje. Teď měl zákazník problém s lagy, a dost možná (a možná ne) byl na vině REDIS (inmemory databáze), a nebo možná poddimenzovaný virtuál, na kterém to běželo. Klobouk dolů, co se před 30 rokama naprogramovalo, a v čem. Ale z dnešního pohledu mi to přijde jako idyla.
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: Ondrej Nemecek 20. 04. 2021, 19:24:20
Vinit z těch nešvarů SQL nedává smysl. Je to obecný jev napříč všemi technologiemi a ani super přímočaré a jednoduché koncepty to nezlepšují (např. JSON se používá protože je tak jednoduchý a každý ho pochopí - ale že má nějaká omezení, které přinesou problémy a odloženou pracnost, to si řada lidí neuvědomí).

Ve skutečnosti je to prostě projev změněných poměrů - jiné množství programátorů, jiný poměr počtu lidí vs. počtu počítačů, jiný rozsah kódu atd. atd.

Asi to lze řešit na osobní úrovni - kdo chce pracovat s kvalitním kódem, musí se probojovat do nejlepších kruhů, kde se děje něco zajímavého nebo běží nějaký výzkum. Jinak plave v kompromisech, které ale na druhou stranu na řadu věcí stačí a pracovat tímto stylem taky není ostuda, alespoň pokud se k nim člověk přiklání vědomě.

Jako třeba ten příklad s taháním celých dat, abych použil jedno číslo - to zase není rozhodnutí jednoho programátora, jde o množství kódu, použitý framework (často ORM, které má přinejlepším nějaký lazy loading) takže nakonec se programátor rozhoduje zda napíše nové sql dotazy (které bude muset navíc obhájit) nebo použije existující otestovaný kód pro uložení celé beany. Prostě - kompromis.
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: Miroslav Šilhavý 20. 04. 2021, 19:27:23
(...) na řadu věcí stačí a pracovat tímto stylem taky není ostuda, alespoň pokud se k nim člověk přiklání vědomě.

Jako třeba ten příklad s taháním celých dat, abych použil jedno číslo - (...) nakonec se programátor rozhoduje zda napíše nové sql dotazy (které bude muset navíc obhájit) nebo použije existující otestovaný kód pro uložení celé beany. Prostě - kompromis.

Moje zkušenost je, že obvykle to není vědomý kompromis, ale většinou neznalost, co vlastně tím způsobují.
Jinak tam, kde se jedná o vědomý a uvážený kompromis - souhlas s tím, co píšete.
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: PanVP 20. 04. 2021, 23:12:54
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á.

Takže jeho tvrzení "Na blbnutí s SQL nemáme čas!"  zpětně považuji za pravdivé - v kontextu daného projektu.
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: Pavel Stěhule 21. 04. 2021, 10:31:21

Ty problémy by měla každá databáze - ...... A)

V IT dělá každý, kdo má ruce. .... B)

A)
moje zkusenost je takova, ze kdyz se nepouzije SQL tak zadne problemy s SQL nejsou. U databazi jako ADABAS, SAP-DB, SolidDB, SAP Advanced Server, Faircom, BerkeleyDB nemusite vubec nikoho skolit na SQL , nikdo nevi co je referencni integrita a normalni formy, kdy se u jake databaze smi a nesmi pouzit jaky trigger   a presto je vsechno vpohode a ACID  :)
Aplikacni programatori si prectou na A4 papiru, jak se jmenuji ty funkce , ktere prectou data z databaze a jak se jmenuji ty, ktere neco zapisuji. Jedine co musi clovek mentalne uchopit je pojem indexu a k cemu je to dobre - ale to se dozvi kazdy programator v prvnim prikladu, kdy ma vytahnout z databaze vsechny faktury s datumem XX.XX.ZZZZ.


Pokud budete používat denormalizované tabulky, a na nich si vyrobíte indexy, tak máte ADABAS. Se všemi výhodami a zejména nevýhodami. Je to jen podmnožina relačního modelu, která má dvě zásadní nevýhody: a) konzistenci si musíte ošetřit na aplikační straně, b) nad files jde dělat jenom omezený počet reportů. Pokud se do toho vlezete, tak to bude rychlé. Pokud ne, tak musíte udělat výrazně víc práce, a ještě report bude pomalý. 

Relační databáze - návrh normálních forem vychází přesně z těch zkušeností s databázemi jako byl ADABAS, a snaží se řešit problémy, které na těchto databázích byly. Byly to jednoduchý stroje, a nijak zvlášť nepodporovali kreativitu. Což je do jisté míry výhoda - nikdo si moc nevymýšlí, a nestaví vzdušné zámky. Pokud jste věděli, co to zvládne, a pokud jste zadání i realizaci s tímto vědomím, tak to mohlo fungovat. Ale to platí na 100% i o dnešním SQL. Dnešní problém je paradoxní. Výkon dnešních databází jak po stránce hw, tak po stránce sw je někde úplně jinde. Ale znalosti a schopnosti vývojářů dost degradovaly a určitě se posunuly. V dobách ADABASu se neřešil uživatelský interface - výsledkem byl papírový report. Dneska programátoři primárně řeší UI, případně integraci komponent, a skrz ty komponenty už nevidí databázi. Díky výkonu dnešních databází se to ještě většinou urve. S nějakým lehkým tuningem (indexy) většina aplikací funguje relativně dobře. Ale ten styl programování je z pohledu db ještě horší než jak se psalo vůči ADABASu. Kdyby se aplikace napsala tak, že klíčové výpočty se provedou SQL nebo uloženými procedurami, tak by mohla být ještě o řád rychlejší.

Nechci se vás dotknout - ale řekl bych, že si ty předrelační databáze idealizujete :-). V té době se fůra věcí nedělala - a) na tehdejším hw vůbec nešla dělat, b) nebyli lidi, c) nebyla data.
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: registrovany123 21. 04. 2021, 10:34:39
Pavel Snehule:

Co si mysliteo tom, kdyz vyvojari kvuli perfromance problemum zacnou denormalizovat tabulky v databazi? Ja si myslim, ze to je spatny postup, ze to nefunguje, a ze to akorat zvysi bordel v aplikaci. Podle me u beznych 95% servis v SOA architekture jsou perfromance issue zpusobene bordelem, spatnymi indexy a deadloky, a nema tomoc spolecneho s tim, ze tabulkuy jsou normalizovane. A denormalizace jenom prileva olej do ohne vseobecneho bordelu, ktery zpusobuje nejen problemy s perfroamnce, ale i bugy.
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: registrovany123 21. 04. 2021, 10:35:10
Pavel Snehule:

Co si mysliteo tom, kdyz vyvojari kvuli performance problemum zacnou denormalizovat tabulky v databazi? Ja si myslim, ze to je spatny postup, ze to nefunguje, a ze to akorat zvysi bordel v aplikaci. Podle me u beznych 95% servis v SOA architekture jsou perfromance issue zpusobene bordelem, spatnymi indexy, spatnymi sql dotazy (bordel), blokujicimi transakcemi (kvuli bordelu v kodu), a nema to moc spolecneho s tim, ze tabulkuy jsou normalizovane. A denormalizace jenom prileva olej do ohne vseobecneho bordelu, ktery zpusobuje nejen problemy s performance, ale i bugy.

Potrebuju nejakou munici na vyvojare, az budou pindat ze serivce ma performance issues a budou chtit jako prvni stupidni reseni co je napadne delat denormalizaci.
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: Miroslav Šilhavý 21. 04. 2021, 10:59:52
@registrovany123

Pavel určitě odpoví, ale napíšu i já.

Denormalizace je svůdná praktika. Na jeden partikulární problém to může být efektivní řešení. Odtrhnete si data a přestanete na ně čekat, protože jsou zablokovaná.

Ta stinná stránka je přesně to, co popisujete. Denormalizace, pokud má být funkční, předpokládá, že vývojář neudělal chybu v úsudku. Může se lehce stát, že odtrhne data, která v důsledku jiných operací přestanou být konzistentní. To pak musíte pohlídat na aplikační úrovni, a to Vás opravdu může stát víc, než si dát databázi do pořádku. A jsme znovu na začátku: musí být v týmu někdo, kdo ten správný úsudek má. Pokud takového člověka v týmu máte, pak se jeho znalost dala rovnou využít k tomu, abyste se vůbec nedostal do stavu, kdy o denormalizaci uvažujete. Je to uzavřený kruh.

Osobně si myslím, že je jednodušší v týmu vypěstovat určité základní znalosti, co se dá očekávat od techniky. Programátor nemusí znát hluboce RDBMS, ale měl by rozpoznat moment, kdy se má poradit s kolegou, který je má.

Když se to nedělá (průběžně), tak se projekt může dostat do stavu, kdy už není jiná možnost, než spoustu práce zahodit a celé části přepsat znovu. To nikdo nechce. Ani zadavatel, který za to platí - tomu těžko vysvětlíte, že jste mu celý rok šli na ruku, aby měl úpravy hotové rychle, ale že po roce se velká část práce může hodit do koše a musí se refaktorovat. Je jen málo zadavatelů, kteří jsou schopni kvalifikovat důsledky rychlého vs. systematického vývoje, ale pochopitelně i takoví existují. Někdy je opravdu obchodně výhodnější "psát na prasátko" s vědomím, že se to později refaktoruje.
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: Pavel Stěhule 21. 04. 2021, 11:16:01
Pavel Snehule:

Co si mysliteo tom, kdyz vyvojari kvuli performance problemum zacnou denormalizovat tabulky v databazi? Ja si myslim, ze to je spatny postup, ze to nefunguje, a ze to akorat zvysi bordel v aplikaci. Podle me u beznych 95% servis v SOA architekture jsou perfromance issue zpusobene bordelem, spatnymi indexy, spatnymi sql dotazy (bordel), blokujicimi transakcemi (kvuli bordelu v kodu), a nema to moc spolecneho s tim, ze tabulkuy jsou normalizovane. A denormalizace jenom prileva olej do ohne vseobecneho bordelu, ktery zpusobuje nejen problemy s performance, ale i bugy.

Potrebuju nejakou munici na vyvojare, az budou pindat ze serivce ma performance issues a budou chtit jako prvni stupidni reseni co je napadne delat denormalizaci.

Na to se nedá jednoduše odpovědět. U OLAPu, když máte star schema nebo snowflake schéma, tak se běžně pracuje s silně denormalizovanými daty (a k tomu se používají databáze optimalizované pro OLAP - sloupcové analytické databáze - vertika, monet nebo snowflake. Tím, že máte předem známé schéma, tak pak můžete používat generické nástroje pro tvorbu MD reportů. OLAP databáze jsou ale sekundární - nejsou primární, a pracuje se tam s transformovanými daty, takže zřejmé nevýhody nenormalizované databáze jsou potlačené.

Pokud máte OLTP databázi s dobře navrženým schématem, tak si myslím, že denormalizace je blbost. Pak mraky dotazů jsou naprosto nesmyslný typu SELECT ... WHERE id = x LIMIT 1. To rozhodně výkonnostně nepomůže. Databáze má evidenci o tom, které hodnoty jsou unikátní, a dokáže tuto informaci využít. Denormalizací redukujete počet unikátních indexů. Nehledě na to, že pak, pokud musíte, tak napsat SQL v ruce bolí, a je neskutečně nečitelné, protože musíte redukovat duplicity - musíte nadužívat DISTINCT, případně zbytečně používat agregace MIN, MAX. To všechno blokuje optimalizaci a má velkou režii. Určitě denormalizací něco zrychlíte, ale dost věcí jinde si zkomplikujete a zpomalíte. Někdy na opravdu velkých tabulkách může mít smysl si přikopírovat sloupec, podle kterého budete filtrovat (někdy se vyplatí data před filtrovat před JOINem, nebo předagregovat). Ale to se bavíme o tabulkách, které mají desítky možná stovky miliónů záznamů.

Pokud se JOIN provádí na úrovni aplikace (díky ORM - kdy v cyklu v aplikaci se volá nějaká metoda, která stahuje data z db), tak se implementuje ta nejpomalejší metoda JOINu, která existuje - nested loop - navíc zpomalený velkou režií vzdálené komunikace. Stáhnout si z jakékoliv databáze 1M hodnot po jednom řádku je neskutečně pomalé. Tím, že denormalizuji, abych získal lepší výkon s ORM, tak já si myslím, že ten nejhorší způsob, co může být. Bohužel ORMka jsou natolik komplikovaná, že tahle dementní cesta, je jediná, která je dosažitelná pro běžného programátora. SQL neumí, a přetlačit ORM také ne - to není o změně ORM, ale o změně patternů (jak to ORM použít).

Pokud si nešikovně namapujete objekty do relační databáze (snažíte se o implementaci dědičnosti na úrovni databáze), tak se může stát, že ve vašem schématu nebude entitě odpovídat tabulka. Pak někdo dělá denormalizaci - ale to není denormalizace, ale materializace entity. V podstatě se dostáváte do správného stavu.

Pokud máte správně znormalizované schéma (a vaše aplikace je OLTP), tak je denormalizace blbost (defakto se snažíte vytvořit jakési materializované pohledy) pro ORM, ale pak se ta databáze hrozně blbě používá. To máte osypky, když máte napsat SQLko.

Je to podobné jako s typovým systémem. V podstatě si můžete vystačit s varcharem (a také jsem viděl takové databáze), ale ve výsledku je to dost pomalé (neefektivně uložená data, neustálé konverze), všechno si musíte udělat sami, a neupozorní vás to na chyby, na které by vás to upozornit mohlo.
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: redustin 21. 04. 2021, 11:21:04
Kdyby se aplikace napsala tak, že klíčové výpočty se provedou SQL nebo uloženými procedurami, tak by mohla být ještě o řád rychlejší.

Již tu zaznělo slovo kompromis. 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í.
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: Pavel Stěhule 21. 04. 2021, 11:42:50
Kdyby se aplikace napsala tak, že klíčové výpočty se provedou SQL nebo uloženými procedurami, tak by mohla být ještě o řád rychlejší.

Již tu zaznělo slovo kompromis. 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í.

Uznávám, že tohle je už hodně kontroverzní téma. Jednak zdrojáky uložených procedur můžete mít ve zdrojácích aplikace, jen je jiný deployment. Ono nejde ani tak o maximalizaci výkonu. Častý (typický) problém je, že vývoj probíhá nad prazdnou databází, a nad ní jsou výpočty rychlé. V momentě, kdy se tam naimportují data, tak už je pozdě něco měnit. Určitě není důvod optimalizovat na krev, na druhou stranu to zpomalení dané tím, že se databáze bere jen jako storage, a že stěhujete data mezi db a aplikací je dost brutální. To může být o řád až  dva. Což může být znatelné u interaktivních aplikací - je rozdíl jestli mám výsledek za sec nebo za deset sec, je rozdíl jestli při 1000 aktivních uživatelů mám cpu na 10% nebo na 80%. A může to být problém i neinteraktivních věcí - pokud vám denní úzávěrka běží 10 hodin a musíte ji mít spočítanou do následujích 24 hod, tak už vám moc nezůstane času na údržbu. Pokud by vám běžela hodinu, tak máte výrazně větší rezervu.

Nemám rád přístup, kdy programátoři, kvůli svému pohodlí předají aplikaci, a pak dalších deset let kolem ní tancují admini,  a uživatelé se můžou učekat. A programátoři jsou v pohodě - mají zdrojáky na jednom místě.
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: Miroslav Šilhavý 21. 04. 2021, 11:56:15
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í.
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: PanVP 21. 04. 2021, 12:26:08
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 ;D 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 ;D 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.
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: Logik 21. 04. 2021, 13:18:02
Citace
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.
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: Pavel Stěhule 21. 04. 2021, 13:23:00

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.
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: Standa Blábol 21. 04. 2021, 18:18:18
Citace
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.
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: Ondrej Nemecek 21. 04. 2021, 20:07:34
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...
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: jouda2 22. 04. 2021, 09:52:04
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.
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: jouda2 22. 04. 2021, 10:07:01
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 :-(
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: Logik 22. 04. 2021, 12:51:09
Jouda: Dobře řečeno


Ondra:
Citace
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
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: Ondrej Nemecek 22. 04. 2021, 15:36:42
Ondra:
Citace
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.
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: BoneFlute 22. 04. 2021, 15:50:37
ž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ázev: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: Ondrej Nemecek 22. 04. 2021, 17:16:58
ž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.
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: Jan Karasek 22. 04. 2021, 17:23:29
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'.
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: Tomas-T 23. 04. 2021, 01:16:08
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.
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: Pavel Stěhule 23. 04. 2021, 05:40:55
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ářů.
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: PanVP 23. 04. 2021, 07:51:46
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!"
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: Miroslav Šilhavý 23. 04. 2021, 08:44:29
@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ě!
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: NaRootuJeNeskutecneDebilniRegistracniFormular 23. 04. 2021, 09:35:13
Co myslíte - kolik "developerů" tuší, že existuje tranasction isolation level?
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: Miroslav Šilhavý 23. 04. 2021, 09:36:47
Co myslíte - kolik "developerů" tuší, že existuje tranasction isolation level?

Hůř. Kolik myslíte, že existuje developerů, kteří tuší, že existují transakce?
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: PanVP 23. 04. 2021, 09:52:43
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í...
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: Miroslav Šilhavý 23. 04. 2021, 10:09:06
Šá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.
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: PanVP 23. 04. 2021, 12:46:49

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 ;D
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: Miroslav Šilhavý 23. 04. 2021, 12:49:40
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 ;D

Kterou? Moje odpověď obsahovala příklad z ranku RDBMS, ale týká se všech zmíněných (i dalších) témat.
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: tomas88 23. 04. 2021, 12:56:23
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 :)
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: PanVP 23. 04. 2021, 13:17:16
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.
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: Logik 23. 04. 2021, 16:00:41
Citace
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? :-))
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: BoneFlute 23. 04. 2021, 16:15:30
Šá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)?
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: BoneFlute 23. 04. 2021, 16:25:35
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.
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: BoneFlute 23. 04. 2021, 16:31:33
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? ;-)
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: Idris 23. 04. 2021, 16:36:30
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í.
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: Idris 23. 04. 2021, 16:47:06
...a to je mi právě záhada, proč se více neuchytily a nerozšířily objektové databáze.
Kdysi jsem se bavil s autorem db4objects (C. Rosenberger). Hlavní problém je v neflexibilnosti tzv. OO jazyků. On zápasil s Javou (a portem pro C#, pro ten si napsal transpiler z Javy), dnes by to pro Rust, Swift nebo Go bylo ještě horší.
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: BoneFlute 23. 04. 2021, 20:07:53
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í.
Jaké garance máš na mysli?
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: BoneFlute 23. 04. 2021, 20:11:49
...a to je mi právě záhada, proč se více neuchytily a nerozšířily objektové databáze.
Kdysi jsem se bavil s autorem db4objects (C. Rosenberger). Hlavní problém je v neflexibilnosti tzv. OO jazyků. On zápasil s Javou (a portem pro C#, pro ten si napsal transpiler z Javy), dnes by to pro Rust, Swift nebo Go bylo ještě horší.
Když si vezmu třeba něco takového: https://crates.io/crates/diesel, což je ještě implementace, která se mi líbí, tak jsem skončil u toho, že takto to dělat nechci. Není to správně OOP.
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: Ondrej Nemecek 23. 04. 2021, 20:43:44
...a to je mi právě záhada, proč se více neuchytily a nerozšířily objektové databáze.
Kdysi jsem se bavil s autorem db4objects (C. Rosenberger). Hlavní problém je v neflexibilnosti tzv. OO jazyků. On zápasil s Javou (a portem pro C#, pro ten si napsal transpiler z Javy), dnes by to pro Rust, Swift nebo Go bylo ještě horší.
Když si vezmu třeba něco takového: https://crates.io/crates/diesel, což je ještě implementace, která se mi líbí, tak jsem skončil u toho, že takto to dělat nechci. Není to správně OOP.

Jak souvisí Diesel v Rustu s objektovými databázemi? Mě šlo o to že objektové databáze by byly lepší než NoSQL, kde je stále to zavádějící to mapování.
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: Idris 23. 04. 2021, 21:34:27
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í.
Jaké garance máš na mysli?
Co je kde v paměti za hodnotu. Typová kontrola (inference) při překladu prostě přesně zjistí typy, velikost hodnot a polí atd.
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: Idris 23. 04. 2021, 21:39:15
...a to je mi právě záhada, proč se více neuchytily a nerozšířily objektové databáze.
Kdysi jsem se bavil s autorem db4objects (C. Rosenberger). Hlavní problém je v neflexibilnosti tzv. OO jazyků. On zápasil s Javou (a portem pro C#, pro ten si napsal transpiler z Javy), dnes by to pro Rust, Swift nebo Go bylo ještě horší.
Když si vezmu třeba něco takového: https://crates.io/crates/diesel, což je ještě implementace, která se mi líbí, tak jsem skončil u toho, že takto to dělat nechci. Není to správně OOP.
Ono se (teoreticky) ví, jak objektové databáze dělat správně, jenže současné mainstreamové jazyky mají prostě omezenou syntax. Ten zmíněný Rosenberger o tom měl dokonce akademické články. Jeho implementace v Javě používala hodně hnusné hacky.
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: tomas88 23. 04. 2021, 21:44:38
Co se tyce objektovych databazi tak podle me jsou docela rozsirene. Napr. kdyz delam mobilni appku a potrebuju nejakou persistenci objektu na strane klienta, tak sahnu po https://realm.io/. No jina vec je ze se moc nerozsili jako uloziste komplexnich systemu, ale jestli to neni spise jakousi setrvacnosti, na co jsou lidi navyknuty, a podobne. Dle me typicke v korporatech - aniz by se vedelo co ten potencionalni novy system bude delat, tak uz je temer jasne, ze tam bude Oracle DB a vubec to neni o tom, jestli to je v hodny typ uloziste pro dany system.
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: Kit 23. 04. 2021, 21:59:00
...a to je mi právě záhada, proč se více neuchytily a nerozšířily objektové databáze.
Kdysi jsem se bavil s autorem db4objects (C. Rosenberger). Hlavní problém je v neflexibilnosti tzv. OO jazyků. On zápasil s Javou (a portem pro C#, pro ten si napsal transpiler z Javy), dnes by to pro Rust, Swift nebo Go bylo ještě horší.

OO jazyky jsou flexibilní - pouze jako vývojáři děláme všechno možné pro to, aby flexibilními nebyly.
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: BoneFlute 23. 04. 2021, 22:03:06
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í.
Jaké garance máš na mysli?
Co je kde v paměti za hodnotu. Typová kontrola (inference) při překladu prostě přesně zjistí typy, velikost hodnot a polí atd.
Ty tu garanci ale nepotřebuješ. Máš pět typů hodnot (číslo, text, list, dict, funkci)[1], na ty to naparsuješ, a pak už nic víc neřešíš. Všude (na těch pár místech) jen stavíš guardy, aby ti to nepadlo na core dump [2], a to je asi tak všechno. Zatímco statické typy, tam máš celej složitej aparát validace a to mluvím jen o impotentních typech v jazycích jako je Java, C#, a spol.


[1] a to rozlišení na číslo a text je samozřejmě optimalizace.
[2] a vyhazuješ si vlastní stack trace
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: BoneFlute 23. 04. 2021, 22:04:41
...a to je mi právě záhada, proč se více neuchytily a nerozšířily objektové databáze.
Kdysi jsem se bavil s autorem db4objects (C. Rosenberger). Hlavní problém je v neflexibilnosti tzv. OO jazyků. On zápasil s Javou (a portem pro C#, pro ten si napsal transpiler z Javy), dnes by to pro Rust, Swift nebo Go bylo ještě horší.
Když si vezmu třeba něco takového: https://crates.io/crates/diesel, což je ještě implementace, která se mi líbí, tak jsem skončil u toho, že takto to dělat nechci. Není to správně OOP.

Jak souvisí Diesel v Rustu s objektovými databázemi? Mě šlo o to že objektové databáze by byly lepší než NoSQL, kde je stále to zavádějící to mapování.
ORM je jako objektová databáze která ukládá do relační databáze. Neshodnem se? V čem?
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: BoneFlute 23. 04. 2021, 22:06:00
jenže současné mainstreamové jazyky mají prostě omezenou syntax.
Uveď příklad prosím.
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: Idris 23. 04. 2021, 22:08:58
celej složitej aparát validace
Pokud stačí generické typy, tak složitý není. Až složitější typové systémy implementaci komplikují.
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: BoneFlute 23. 04. 2021, 22:13:47
celej složitej aparát validace
Pokud stačí generické typy, tak složitý není. Až složitější typové systémy implementaci komplikují.
A proto třeba veškerá typová validace Javy se při kompilaci zahodí, odvodí se vlastní.

Napsat jazyk bez typů je snadné. Důkazem je Lua, který považuji za špičku dynamického jazyka. Tam to vzaly za dobrý konec - oškubaná na kost a skoro dokonalá. A pak se k tomu přibaluje typový aparát, více či méně schopný. Samozřejmě, napsat typy aka Java/C#, to je možná pod tvou rozlišovací schopnost :-). Ale přesto je to něco navíc.
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: Idris 23. 04. 2021, 22:14:12
jenže současné mainstreamové jazyky mají prostě omezenou syntax.
Uveď příklad prosím.
Celé to je hezky shrnuté zde: https://dl.acm.org/doi/10.1145/1062455.1062488
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: Idris 23. 04. 2021, 22:17:16
Samozřejmě, napsat typy aka Java/C#, to je možná pod tvou rozlišovací schopnost
U těchto jazyků je implementace vskutku jednoduchá, ale i to dodrbali. Kvalitně je inference typů udělaná v Rustu.
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: BoneFlute 23. 04. 2021, 22:46:50
Co se tyce objektovych databazi tak podle me jsou docela rozsirene. Napr. kdyz delam mobilni appku a potrebuju nejakou persistenci objektu na strane klienta, tak sahnu po https://realm.io/.
Já teda vidím, realm.io jako ORMko do MongoDB. Koukám se špatně?
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: BoneFlute 23. 04. 2021, 22:52:30
jenže současné mainstreamové jazyky mají prostě omezenou syntax.
Uveď příklad prosím.
Celé to je hezky shrnuté zde: https://dl.acm.org/doi/10.1145/1062455.1062488
Skončil jsem u toho, že chtěj placenej účet.

Tak sem hoď jeden dva příklady.
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: tomas88 23. 04. 2021, 23:32:10
Co se tyce objektovych databazi tak podle me jsou docela rozsirene. Napr. kdyz delam mobilni appku a potrebuju nejakou persistenci objektu na strane klienta, tak sahnu po https://realm.io/.
Já teda vidím, realm.io jako ORMko do MongoDB. Koukám se špatně?

Realm is a mobile database: a replacement for SQLite & ORMs

https://github.com/realm/realm-core
https://github.com/realm/realm-java

Tohle se necha pouzivat zadarmo a dal jsem nikdy nesel. To s tim MongoDB je ohledne sync. dat mezi clientem <> serverem a okolo toho maji postaveny biznis.
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: Idris 23. 04. 2021, 23:37:22
jenže současné mainstreamové jazyky mají prostě omezenou syntax.
Uveď příklad prosím.
Celé to je hezky shrnuté zde: https://dl.acm.org/doi/10.1145/1062455.1062488
Skončil jsem u toho, že chtěj placenej účet.

Tak sem hoď jeden dva příklady.
Dej to do Googlu, tohle by mělo být na Research Gate nebo něčem podobném.
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: BoneFlute 23. 04. 2021, 23:38:58
Co se tyce objektovych databazi tak podle me jsou docela rozsirene. Napr. kdyz delam mobilni appku a potrebuju nejakou persistenci objektu na strane klienta, tak sahnu po https://realm.io/.
Já teda vidím, realm.io jako ORMko do MongoDB. Koukám se špatně?

Realm is a mobile database: a replacement for SQLite & ORMs

https://github.com/realm/realm-core
https://github.com/realm/realm-java

Tohle se necha pouzivat zadarmo a dal jsem nikdy nesel. To s tim MongoDB je ohledne sync. dat mezi clientem <> serverem a okolo toho maji postaveny biznis.
Díky.
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: Jan Karasek 23. 04. 2021, 23:43:35
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? ;-)

ne , kdyz se nekdo zepta, tak se nejdrive odkaze na CAP-teorem a pak na nejake pojednani o tom teoremu (napr. https://blog.nahurst.com/visual-guide-to-nosql-systems), aby se tazatel zacal orientovat, jake ty vztahy mezi temi relacnimi a jinymi databazemi vypadaji.

Pak se samozrejme vyjmenuji v obecne rovine ty hlavni vyhody:
- odpada impedance mismatch mezi relacnim dotazovanin a naslednym imperativnim zpracovanim dodanych dat
- skalovatelnost
- flexibilita pri ukladan dnesnich rozmanitych, ruznorodych a menícich se dat
- vestavene funkce pro vyhledavani a dotazovani, diky nimz jsou data kdykoli lepe vyuzitelna
- mozna realizace bitemporernich funkci (co se vedelo , od kdy se to vedelo)
- lepsi podpora pri realizaci 'recommender' systemu

Samozrejme, ze se vyjmenovane musi rozvest a upozornit na to, ze pro ukladani dat pro nejaky e-shop je naproso jedno do ceho se to bude ukladat. A ze ty argumenty nahore plati spis pro amazon nez pro nejakou firmicku s 5 lidma.

To vse uvedene jsou samozrejme fakta pro lidi, kteri se radi o databazich pokecaji a podiskutuji.

Pro ty praktiky staci, ze se sdeli, ze pro ty nerelacni cerpadla:
- neni potreba pan Vondra nebo Stehule
- neni potreba nejakych skoleni
- dokumentace pro pristup k datum se vejde na A4 papir
- filozofie pristupu k datum pochopi prumerny stredoskolach za 2 minuty
- na zacatku projektu neni treba vedet vsechno do detailu
- v prubehu projektu se zmeny v nazorech a pozadavcich nepromitnou negativne do prubehu projektu
- zakaznik nepozaduje pristup k datum pres SQL (protoze to neexistuje) a tim se vyhnou oba partneri garancnim sporum

na zaver je mozno zminit, ze ten nejvetsi prinos je, ze to nasazeni tech nerelacnich cerpadel teprve umozni tu rozumnou modularizaci softwaroveho produktu - ale to se rekne jenom potichu, aby si toho nikdo nevsiml - protoze to je bohuzel nevysvetlitelne.
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: Idris 23. 04. 2021, 23:44:33
jenže současné mainstreamové jazyky mají prostě omezenou syntax.
Uveď příklad prosím.
Celé to je hezky shrnuté zde: https://dl.acm.org/doi/10.1145/1062455.1062488
Skončil jsem u toho, že chtěj placenej účet.

Tak sem hoď jeden dva příklady.
Jinak příkladem je jakýkoliv netriviální dotaz, například:
Kód: [Vybrat]
var query = \person => person.age > xyzŽádný mně známý rozšířený jazyk neumožňuje z λ-výrazu vytvořit efektivní dotaz (nad indexy databáze). To je jádro věci. Nejblíže k tomu má asi C++, ale taky to jde jen horkotěžko.

Další komplikace jsou pak sémantického rázu, zmíněná db4objects používá kvůli efektivitě proxy objekty, jejichž parametry se musí konfigurovat atd. Celkově tehdy (před 10-15 lety) to byl dost vopruz, proto OODB zůstaly na okraji zájmu (podle Rosenbergera, i když toho to asi moc netrápí, prodal svou OODB za hezkou sumičku).
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: BoneFlute 24. 04. 2021, 03:32:04
Jinak příkladem je jakýkoliv netriviální dotaz, například:
Kód: [Vybrat]
var query = \person => person.age > xyzŽádný mně známý rozšířený jazyk neumožňuje z λ-výrazu vytvořit efektivní dotaz (nad indexy databáze). To je jádro věci. Nejblíže k tomu má asi C++, ale taky to jde jen horkotěžko.
LINQtoSQL?

Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: BoneFlute 24. 04. 2021, 03:38:29
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? ;-)

ne , kdyz se nekdo zepta, tak se nejdrive odkaze na CAP-teorem a pak na nejake pojednani o tom teoremu (napr. https://blog.nahurst.com/visual-guide-to-nosql-systems), aby se tazatel zacal orientovat, jake ty vztahy mezi temi relacnimi a jinymi databazemi vypadaji.

Pak se samozrejme vyjmenuji v obecne rovine ty hlavni vyhody:
- odpada impedance mismatch mezi relacnim dotazovanin a naslednym imperativnim zpracovanim dodanych dat
- skalovatelnost
- flexibilita pri ukladan dnesnich rozmanitych, ruznorodych a menícich se dat
- vestavene funkce pro vyhledavani a dotazovani, diky nimz jsou data kdykoli lepe vyuzitelna
- mozna realizace bitemporernich funkci (co se vedelo , od kdy se to vedelo)
- lepsi podpora pri realizaci 'recommender' systemu

Samozrejme, ze se vyjmenovane musi rozvest a upozornit na to, ze pro ukladani dat pro nejaky e-shop je naproso jedno do ceho se to bude ukladat. A ze ty argumenty nahore plati spis pro amazon nez pro nejakou firmicku s 5 lidma.

To vse uvedene jsou samozrejme fakta pro lidi, kteri se radi o databazich pokecaji a podiskutuji.

Pro ty praktiky staci, ze se sdeli, ze pro ty nerelacni cerpadla:
- neni potreba pan Vondra nebo Stehule
- neni potreba nejakych skoleni
- dokumentace pro pristup k datum se vejde na A4 papir
- filozofie pristupu k datum pochopi prumerny stredoskolach za 2 minuty
- na zacatku projektu neni treba vedet vsechno do detailu
- v prubehu projektu se zmeny v nazorech a pozadavcich nepromitnou negativne do prubehu projektu
- zakaznik nepozaduje pristup k datum pres SQL (protoze to neexistuje) a tim se vyhnou oba partneri garancnim sporum


Hmmm, když jsem to přelouskal, oprostil od balastu, a porovnal s možnostmi relačních databází, tak mi vypadly tyto výhody NoSQL:
- možnost škálovat (za cenu ztráty ACID)
- vestavěné bezešvé ORM

Což mi připomělo, že jsem si chtěl udělat výkonnostní test vyhledávání NoSQL versus SQL.

na zaver je mozno zminit, ze ten nejvetsi prinos je, ze to nasazeni tech nerelacnich cerpadel teprve umozni tu rozumnou modularizaci softwaroveho produktu - ale to se rekne jenom potichu, aby si toho nikdo nevsiml - protoze to je bohuzel nevysvetlitelne.
OMG, už zase esoterika.
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: BoneFlute 24. 04. 2021, 03:50:08
Další komplikace jsou pak sémantického rázu, zmíněná db4objects používá kvůli efektivitě proxy objekty, jejichž parametry se musí konfigurovat atd. Celkově tehdy (před 10-15 lety) to byl dost vopruz, proto OODB zůstaly na okraji zájmu (podle Rosenbergera, i když toho to asi moc netrápí, prodal svou OODB za hezkou sumičku).

Když si nad tím trochu zafilozofujem, a vrátíme se ke kořenům - tak jde o to, že máme nějakou běžící aplikaci, která má stav. Já tu aplikaci ukončím, a když ji zase spustím, tak chci, aby měla stejný stav jako předtím. Přidáme síťování, a tedy chci, aby když v jedné instanci aplikace upravím nějaká data, tak aby se mi magicky promítli do všech ostatních instancí (něco co dělá Slack pro příklad). To je cíl.

V praxi ale vidím něco jiného - mám aplikaci, a ta si svůj stav synchronizuje s databází (buřt jestli relační, nebo objektovou). Což by zase tak moc nevadilo, když by tato skutečnost neprosakovala do architektury té aplikace. Což by zase tolik nevadilo, když by si architekti ujasnili, jestli to chtějí přiznat, nebo ne, a nedělali to napůl.

Překvapivě nejčistší to mají funkcionální jazyky. Tam je jasně by design oddělený stav a logika, a tak není problém ten stav frknout do databáze, a všichni vědí. Zatímco u objektových jazyků furt cítím (na základě projektů se kterými jsem dělal i diskusí, které jsem vedl) děsnou schízu a neujasněnost.
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: Idris 24. 04. 2021, 10:54:58
Překvapivě nejčistší to mají funkcionální jazyky. Tam je jasně by design oddělený stav a logika, a tak není problém ten stav frknout do databáze, a všichni vědí.

Logické jazyky ještě víc, tam je program DB + pravidla :)

Zatímco u objektových jazyků furt cítím (na základě projektů se kterými jsem dělal i diskusí, které jsem vedl) děsnou schízu a neujasněnost.
Kromě Smalltalku ;)
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: Ondrej Nemecek 24. 04. 2021, 14:56:04
Překvapivě nejčistší to mají funkcionální jazyky. Tam je jasně by design oddělený stav a logika, a tak není problém ten stav frknout do databáze, a všichni vědí.

Logické jazyky ještě víc, tam je program DB + pravidla :)

Zatímco u objektových jazyků furt cítím (na základě projektů se kterými jsem dělal i diskusí, které jsem vedl) děsnou schízu a neujasněnost.
Kromě Smalltalku ;)

No a jsme u toho. Pro spoustu malých projektů by stačil přístup Smalltalku.
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: Idris 24. 04. 2021, 14:59:51
LINQtoSQL?
LINQ je náznak, jak by to zhruba mělo vypadat.
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: Idris 24. 04. 2021, 15:00:28
Překvapivě nejčistší to mají funkcionální jazyky. Tam je jasně by design oddělený stav a logika, a tak není problém ten stav frknout do databáze, a všichni vědí.

Logické jazyky ještě víc, tam je program DB + pravidla :)

Zatímco u objektových jazyků furt cítím (na základě projektů se kterými jsem dělal i diskusí, které jsem vedl) děsnou schízu a neujasněnost.
Kromě Smalltalku ;)
No a jsme u toho. Pro spoustu malých projektů by stačil přístup Smalltalku.
To se taky moc nechytlo  :-\
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: Ondrej Nemecek 24. 04. 2021, 15:02:54
Co se tyce objektovych databazi tak podle me jsou docela rozsirene. Napr. kdyz delam mobilni appku a potrebuju nejakou persistenci objektu na strane klienta, tak sahnu po https://realm.io/.
Já teda vidím, realm.io jako ORMko do MongoDB. Koukám se špatně?

Realm is a mobile database: a replacement for SQLite & ORMs

https://github.com/realm/realm-core
https://github.com/realm/realm-java

Tohle se necha pouzivat zadarmo a dal jsem nikdy nesel. To s tim MongoDB je ohledne sync. dat mezi clientem <> serverem a okolo toho maji postaveny biznis.

Vypadá to, že to je orientované na Android, protože:

Citace
Java version of Realm currently runs only on Android
https://github.com/realm/realm-java (https://github.com/realm/realm-java)
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: Ondrej Nemecek 24. 04. 2021, 15:07:17
Překvapivě nejčistší to mají funkcionální jazyky. Tam je jasně by design oddělený stav a logika, a tak není problém ten stav frknout do databáze, a všichni vědí.

Logické jazyky ještě víc, tam je program DB + pravidla :)

Zatímco u objektových jazyků furt cítím (na základě projektů se kterými jsem dělal i diskusí, které jsem vedl) děsnou schízu a neujasněnost.
Kromě Smalltalku ;)
No a jsme u toho. Pro spoustu malých projektů by stačil přístup Smalltalku.
To se taky moc nechytlo  :-\

Hlavně se nechytla Gemstone database, což je škoda.

Což je ale IMHO dáno historickým kontextem.

Používal jste někdo Gemstone?
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: Idris 24. 04. 2021, 15:13:04
Překvapivě nejčistší to mají funkcionální jazyky. Tam je jasně by design oddělený stav a logika, a tak není problém ten stav frknout do databáze, a všichni vědí.

Logické jazyky ještě víc, tam je program DB + pravidla :)

Zatímco u objektových jazyků furt cítím (na základě projektů se kterými jsem dělal i diskusí, které jsem vedl) děsnou schízu a neujasněnost.
Kromě Smalltalku ;)
No a jsme u toho. Pro spoustu malých projektů by stačil přístup Smalltalku.
To se taky moc nechytlo  :-\

Hlavně se nechytla Gemstone database, což je škoda.

Což je ale IMHO dáno historickým kontextem.

Používal jste někdo Gemstone?
Kdysi dávno jsem používal její klon pro ObjC. Pracovalo se s tím velmi dobře.
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: Kit 24. 04. 2021, 15:27:49
Překvapivě nejčistší to mají funkcionální jazyky. Tam je jasně by design oddělený stav a logika, a tak není problém ten stav frknout do databáze, a všichni vědí.
Logické jazyky ještě víc, tam je program DB + pravidla :)

Stačí se jen trošičku snažit a jde to krásně i v objektových jazycích. Stačí necpat data do objektů, ale do kolekcí. Stavy v objektech pak slouží výhradně k řízení toho objektu.

Zatímco u objektových jazyků furt cítím (na základě projektů se kterými jsem dělal i diskusí, které jsem vedl) děsnou schízu a neujasněnost.
Kromě Smalltalku ;)
No a jsme u toho. Pro spoustu malých projektů by stačil přístup Smalltalku.
To se taky moc nechytlo  :-\

Smalltalk samotný asi ne, ale mnohé přístupy jsou použitelné i v jiných jazycích.
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: BoneFlute 24. 04. 2021, 18:13:22
Kromě Smalltalku ;)
Smalltalk určitě můžeme považovat za výjimku potvrzující pravidlo.

Jen pro pořádek, setkal jsi se s řešením více instancí jednoho image, tedy tak, aby sdíleli stejný stav, ideálně i napříč sítí?
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: Idris 24. 04. 2021, 18:36:58
Kromě Smalltalku ;)
Smalltalk určitě můžeme považovat za výjimku potvrzující pravidlo.

Jen pro pořádek, setkal jsi se s řešením více instancí jednoho image, tedy tak, aby sdíleli stejný stav, ideálně i napříč sítí?
Ne, v praxi nesetkal.
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: Ondrej Nemecek 24. 04. 2021, 19:55:59
Kromě Smalltalku ;)
Smalltalk určitě můžeme považovat za výjimku potvrzující pravidlo.

Jen pro pořádek, setkal jsi se s řešením více instancí jednoho image, tedy tak, aby sdíleli stejný stav, ideálně i napříč sítí?
Ne, v praxi nesetkal.

Což je IMHO omezení toho konceptu. Sdílená paměť sice není problém, ale problém je asi distribuce změn. Protože dělat to celé synchronizované by byl výkonnostní nesmysl. A bez okamžité synchronizace se zas dojde k nějakému distribuovanému systému s mapováním, řešením verzí, kolizí, s attache a detached persistentním stavem atd., tedy vše co se řeší v SQL příp. ORM.
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: Idris 24. 04. 2021, 20:15:35
Kromě Smalltalku ;)
Smalltalk určitě můžeme považovat za výjimku potvrzující pravidlo.

Jen pro pořádek, setkal jsi se s řešením více instancí jednoho image, tedy tak, aby sdíleli stejný stav, ideálně i napříč sítí?
Ne, v praxi nesetkal.
Což je IMHO omezení toho konceptu. Sdílená paměť sice není problém, ale problém je asi distribuce změn.
Tohle vedlo ke konceptu distribuovaných objektů, což byl svého času rozšířený buzzword. Ale ty se taky neujaly.

Distribuci změn dobře řešilo Lotus Notes/Domino nebo Groove.
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: BoneFlute 24. 04. 2021, 22:51:00
Kromě Smalltalku ;)
Smalltalk určitě můžeme považovat za výjimku potvrzující pravidlo.

Jen pro pořádek, setkal jsi se s řešením více instancí jednoho image, tedy tak, aby sdíleli stejný stav, ideálně i napříč sítí?
Ne, v praxi nesetkal.

Což je IMHO omezení toho konceptu. Sdílená paměť sice není problém, ale problém je asi distribuce změn. Protože dělat to celé synchronizované by byl výkonnostní nesmysl. A bez okamžité synchronizace se zas dojde k nějakému distribuovanému systému s mapováním, řešením verzí, kolizí, s attache a detached persistentním stavem atd., tedy vše co se řeší v SQL příp. ORM.
To bych neřekl. V čem se Smalltalkovské image liší od oddělené databáze jak to známe dnes je skutečnost, že se o to nemusel vývojář starat. Byla to vlastnost toho systému. Takže, čistě teoreticky, není problém aby si ten systém distribuovanost řešil sám, a všechno fungovalo naprosto transparentně.

nějakému distribuovanému systému s mapováním, řešením verzí, kolizí, s attache a detached persistentním stavem atd., tedy vše co se řeší v SQL příp. ORM.
Tak přesně takto to není. Vše, co jsi uvedl je problematika čistě toho našeho nám známého řešení. A ani náhodou to není univerzální problematika. Snad jedině řešení kolizí stojí za úvahu.
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: BoneFlute 24. 04. 2021, 22:52:47
Distribuci změn dobře řešilo Lotus Notes/Domino nebo Groove.
Jak řešili konflikty?
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: Idris 24. 04. 2021, 22:58:42
Distribuci změn dobře řešilo Lotus Notes/Domino nebo Groove.
Jak řešili konflikty?
U záznamů unifikací na úrovni polí. Domino má jako dokumentová databáze poddokumenty, tam končí konfliktní dokumenty, když se nedají data sloučit automaticky. Groove si už nepamatuju, ale navrhoval ho stejný člověk, takže asi podobně.
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: Idris 24. 04. 2021, 23:00:12
že se o to nemusel vývojář starat. Byla to vlastnost toho systému. Takže, čistě teoreticky, není problém aby si ten systém distribuovanost řešil sám, a všechno fungovalo naprosto transparentně.
Jako JavaSpaces?
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: BoneFlute 24. 04. 2021, 23:05:24
Kromě Smalltalku ;)
Smalltalk určitě můžeme považovat za výjimku potvrzující pravidlo.

Jen pro pořádek, setkal jsi se s řešením více instancí jednoho image, tedy tak, aby sdíleli stejný stav, ideálně i napříč sítí?
Ne, v praxi nesetkal.
Což je IMHO omezení toho konceptu. Sdílená paměť sice není problém, ale problém je asi distribuce změn.
Tohle vedlo ke konceptu distribuovaných objektů, což byl svého času rozšířený buzzword. Ale ty se taky neujaly.
IMHO distribuované objekty jsou trochu něco jiného. Nejsou to více provázaných instancí, ale klasicky klient server. Ve windows COM, na Linuxu CORBA, Java má RMI... Všechno se celkem používá. Nebo jsem tě nepochopil?
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: BoneFlute 24. 04. 2021, 23:06:02
Distribuci změn dobře řešilo Lotus Notes/Domino nebo Groove.
Jak řešili konflikty?
U záznamů unifikací na úrovni polí. Domino má jako dokumentová databáze poddokumenty, tam končí konfliktní dokumenty, když se nedají data sloučit automaticky. Groove si už nepamatuju, ale navrhoval ho stejný člověk, takže asi podobně.
Díky.
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: BoneFlute 24. 04. 2021, 23:09:41
že se o to nemusel vývojář starat. Byla to vlastnost toho systému. Takže, čistě teoreticky, není problém aby si ten systém distribuovanost řešil sám, a všechno fungovalo naprosto transparentně.
Jako JavaSpaces?
Úplně dobře to neznám, ale přijde mi, že je to taky jen trochu vymazlenější Client/Server.
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: Idris 24. 04. 2021, 23:11:01
IMHO distribuované objekty jsou trochu něco jiného. Nejsou to více provázaných instancí, ale klasicky klient server. Ve windows COM, na Linuxu CORBA, Java má RMI... Všechno se celkem používá. Nebo jsem tě nepochopil?
Spíš DCOM než COM. Jeho použití moc nevidím, javovské RMI taky ne. Měl jsem na mysli spíš ty staré systémy DO od Sunu apod. integrované přímo do jazyků, které se neujaly. Standardy jako CORBA a SOAP se trochu chytly (i když dnes už o nich taky není moc slyšet).
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: Idris 24. 04. 2021, 23:12:15
že se o to nemusel vývojář starat. Byla to vlastnost toho systému. Takže, čistě teoreticky, není problém aby si ten systém distribuovanost řešil sám, a všechno fungovalo naprosto transparentně.
Jako JavaSpaces?
Úplně dobře to neznám, ale přijde mi, že je to taky jen trochu vymazlenější Client/Server.
Javovskou verzi taky neznám do hloubky, ale původní koncept “tuple spaces” byl spíš P2P.
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: Ondrej Nemecek 24. 04. 2021, 23:13:52
nějakému distribuovanému systému s mapováním, řešením verzí, kolizí, s attache a detached persistentním stavem atd., tedy vše co se řeší v SQL příp. ORM.
Tak přesně takto to není. Vše, co jsi uvedl je problematika čistě toho našeho nám známého řešení. A ani náhodou to není univerzální problematika. Snad jedině řešení kolizí stojí za úvahu.

Takže když změním instanci objektu z jednoho procesu, co uvidí druhý proces (co by sdílel stejný stav)? Uvidí hned změnu, sdílejí stejnou instanci? PS: Jasně, SQL je taky způsob jak sdílet stav, ale otázka asi zněla zda to jde nějak víc napřímo.
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: BoneFlute 24. 04. 2021, 23:26:24
nějakému distribuovanému systému s mapováním, řešením verzí, kolizí, s attache a detached persistentním stavem atd., tedy vše co se řeší v SQL příp. ORM.
Tak přesně takto to není. Vše, co jsi uvedl je problematika čistě toho našeho nám známého řešení. A ani náhodou to není univerzální problematika. Snad jedině řešení kolizí stojí za úvahu.

Takže když změním instanci objektu z jednoho procesu, co uvidí druhý proces (co by sdílel stejný stav)? Uvidí hned změnu, sdílejí stejnou instanci?
Uvidí změnněnou hodnotu toho objektu. Když změním třeba Person.name = "Jozef", uvidí taky "Jozef". Když přidám, nebo odeberu prvek z kolekce, přidá se či odebere i u toho druhého. (Případně ve všech ostatních.)


PS: Jasně, SQL je taky způsob jak sdílet stav, ale otázka asi zněla zda to jde nějak víc napřímo.
Ani ne. Postgresql jako správce stavu může být klidně dobrý nápad. Ale je to implementační detail. Hlavně tam nesmí být takové to:
Kód: [Vybrat]
entity = connection.query(anything)
entity.name = "Jozef"
connection.persist(entity)
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: Idris 24. 04. 2021, 23:49:07
Hlavně tam nesmí být takové to:
Kód: [Vybrat]
entity = connection.query(anything)
entity.name = "Jozef"
connection.persist(entity)
Jak bys řešil transakce?
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: Kit 25. 04. 2021, 00:02:18
Hlavně tam nesmí být takové to:
Kód: [Vybrat]
entity = connection.query(anything)
entity.name = "Jozef"
connection.persist(entity)
Jak bys řešil transakce?

Tohle právě nemá s transakcemi nic společného. Když místo toho použije UPDATE, tak je to transakce by design.
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: BoneFlute 25. 04. 2021, 00:12:50
Hlavně tam nesmí být takové to:
Kód: [Vybrat]
entity = connection.query(anything)
entity.name = "Jozef"
connection.persist(entity)
Jak bys řešil transakce?

Vycházíš z ne úplně odůvodněného předpokladu, že to mám promyšlené.

cca takhle, asi, možná:

Kód: [Vybrat]
posts = Collection<Post>
users = Collection<User>
try {
    author = User("John", "Dee")
    item = Post(author, "title", "content")
    item.discuss.add(Comment("author 1", "lorem ipsum 1"))
    item.discuss.add(Comment("author 2", "lorem ipsum 2"))
    posts.add(item)
    users.add(author)
}
catch (Exception e) {
    console.log(e.message)
}

Transakce slouží k tomu, aby vytvořili atomický blok. Mohu na to vytvořit spešl syntax, nebo zneužít třeba ty výjimky. Ta atomicita způsobí, že dokud není dokončeno, tak se změna neprojeví nikde, ani v jiném vláknu té samé instance, ani v jiné instanci sdílící stejný stav.


Shodou okolností reálný kód na neidealistické platformě (pseudokod):
Kód: [Vybrat]
posts = Collection<Post>
users = Collection<User>
conn.transaction(conn => {
    author = User("John", "Dee")
    item = Post(author, "title", "content")
    item.discuss.add(Comment("author 1", "lorem ipsum 1"))
    item.discuss.add(Comment("author 2", "lorem ipsum 2"))
    posts.add(item)
    users.add(author)
    conn.flush(posts)
    conn.flush(users)
}, e => {
    console.log(e.message)
})

Výše uvedený kód by pak měl vypadat takto:
Kód: [Vybrat]
try {
    entity = users.find(anything)
    entity.name = "Jozef"
}
catch (Exception e) {
    console.log(e.message)
}

Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: Ondrej Nemecek 25. 04. 2021, 00:15:54
Takže když změním instanci objektu z jednoho procesu, co uvidí druhý proces (co by sdílel stejný stav)? Uvidí hned změnu, sdílejí stejnou instanci?
Uvidí změnněnou hodnotu toho objektu. Když změním třeba Person.name = "Jozef", uvidí taky "Jozef". Když přidám, nebo odeberu prvek z kolekce, přidá se či odebere i u toho druhého. (Případně ve všech ostatních.)

A to takhle někde jde? A není to náhodou to stejné jako když se dva klienti připojují do SQL? Taky vidí stejné hodnoty... ...až na ty okolnosti při různém transaction isolation levels. Ale pokud uvažujeme úplně netransakčně -  kdo přijde, ten čte/mění - tam můžu sdílet paměť a při každé změně objektu tam zapsat novou hodnotu a při každém dotazu ji zase číst. A třeba může být ten zápis mezi klienty synchronizovaný (takže zapisovat budou vždy jeden po druhém, nikdy současně) Neuvažuju teď změny třídy jako takové, řekněme že se jejich definice za běhu nemění a mění se jen její fieldy (datové položky - třídní proměnné). Tak takový systém určitě bude fungovat. Ale zase k čemu vlastně bude? Typicky chci načíst objekt, nějak ho měnit, validovat a až nakonec naráz uložit. Pokud to bude dělat vše hned naživo, nechám ho v rozdrbaném stavu. Chtěl jsem takhle nějak použít ZooDB a došel jsem k tomu, že to asi nechci. Teda ještě si můžu objekt naklonovat, udělat změny, validovat a pak promítnout do původní instance. Ale to už jsme u toho attachování, které jsme vlastně nechtěli. Čili při běžném aplikačním programování se skrytě obvykle uvažují cca dvě verze instance - před změnou a po změně. Je to důsledek SQL/ORM architektury nebo obecný problém? Třeba active record pattern v ebean.io (https://ebean.io/docs/setup/activerecord) nemá attach/detach sémantiku (jede v jediné persistentní session, kterou asi ani neumí opustit), ale save() tam má. A ten si nedokážu představit bez řešení kolizí a bez transakčnosti, kterou naopak ebean.io má. Takže v praxi se podle mě naráží na stejné problémy, které mi přijdou jako obecné problémy při sdílení stavu mezi více procesy. Ale jeden benefit by tam u objektové databáze byt - absence mapování. Pokud by tam byly všechna ta synchronizační bižuterie okolo a pracovalo se přímo s object graphem bez ORM mappingu, bylo by to to co asi hledám.
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: Kit 25. 04. 2021, 00:21:47
Takže když změním instanci objektu z jednoho procesu, co uvidí druhý proces (co by sdílel stejný stav)? Uvidí hned změnu, sdílejí stejnou instanci?
Uvidí změnněnou hodnotu toho objektu. Když změním třeba Person.name = "Jozef", uvidí taky "Jozef". Když přidám, nebo odeberu prvek z kolekce, přidá se či odebere i u toho druhého. (Případně ve všech ostatních.)

Typicky chci načíst objekt, nějak ho měnit, validovat a až nakonec naráz uložit.

To je ta chyba v uvažování. Nechci ten objekt načíst, chci ho jen změnit.
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: Ondrej Nemecek 25. 04. 2021, 00:23:48
Typicky chci načíst objekt, nějak ho měnit, validovat a až nakonec naráz uložit.
To je ta chyba v uvažování. Nechci ten objekt načíst, chci ho jen změnit.

Dobře, tak ho už mám, změní se v uvažování něco? V podstatě můžu spouštět vlákna ve stejném procesu, pracovat nad stejnou pamětí, ale lze to nazvat databází? Ale bude to asi nejpodobnější tomu Smalltalku.
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: BoneFlute 25. 04. 2021, 00:24:33
Takže když změním instanci objektu z jednoho procesu, co uvidí druhý proces (co by sdílel stejný stav)? Uvidí hned změnu, sdílejí stejnou instanci?
Uvidí změnněnou hodnotu toho objektu. Když změním třeba Person.name = "Jozef", uvidí taky "Jozef". Když přidám, nebo odeberu prvek z kolekce, přidá se či odebere i u toho druhého. (Případně ve všech ostatních.)

A to takhle někde jde? A není to náhodou to stejné jako když se dva klienti připojují do SQL? Taky vidí stejné hodnoty... ...až na ty okolnosti při různém transaction isolation levels. Ale pokud uvažujeme úplně netransakčně -  kdo přijde, ten čte/mění - tam můžu sdílet paměť a při každé změně objektu tam zapsat novou hodnotu a při každém dotazu ji zase číst. A třeba může být ten zápis mezi klienty synchronizovaný (takže zapisovat budou vždy jeden po druhém, nikdy současně) Neuvažuju teď změny třídy jako takové, řekněme že se jejich definice za běhu nemění a mění se jen její fieldy (datové položky - třídní proměnné). Tak takový systém určitě bude fungovat. Ale zase k čemu vlastně bude? Typicky chci načíst objekt, nějak ho měnit, validovat a až nakonec naráz uložit. Pokud to bude dělat vše hned naživo, nechám ho v rozdrbaném stavu. Chtěl jsem takhle nějak použít ZooDB a došel jsem k tomu, že to asi nechci. Teda ještě si můžu objekt naklonovat, udělat změny, validovat a pak promítnout do původní instance. Ale to už jsme u toho attachování, které jsme vlastně nechtěli. Čili při běžném aplikačním programování se skrytě obvykle uvažují cca dvě verze instance - před změnou a po změně. Je to důsledek SQL/ORM architektury nebo obecný problém? Třeba active record pattern v ebean.io (https://ebean.io/docs/setup/activerecord) nemá attach/detach sémantiku (jede v jediné persistentní session, kterou asi ani neumí opustit), ale save() tam má. A ten si nedokážu představit bez řešení kolizí a bez transakčnosti, kterou naopak ebean.io má. Takže v praxi se podle mě naráží na stejné problémy, které mi přijdou jako obecné problémy při sdílení stavu mezi více procesy. Ale jeden benefit by tam u objektové databáze byt - absence mapování. Pokud by tam byly všechna ta synchronizační bižuterie okolo a pracovalo se přímo s object graphem bez ORM mappingu, bylo by to to co asi hledám.

Jde o styl uvažování. Dneska, díky okolnostem, je ten způsob uvažování následující:
- vytáhni z persistence
- uprav
- ulož zpět do persistence

Což je naprosto umělé. A správně by to mělo být:
- najdi v poli [1] požadovaný záznam
- uprav v něm co potřebuješ

Případně, pokud chci transakčnost, tak:
- začni atomický blok
- najdi v poli požadovaný záznam
- uprav v něm co potřebuješ
- commit

Transakce je v pohodě, o tom není řeč. Co považuji za umělé je to vytahování odněkud a pak to tam opět vracení.


1/ úplně obyčejném, nespeciálním, v žádném ORM nasledovaném
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: Kit 25. 04. 2021, 00:28:21
Typicky chci načíst objekt, nějak ho měnit, validovat a až nakonec naráz uložit.
To je ta chyba v uvažování. Nechci ten objekt načíst, chci ho jen změnit.

Dobře, tak ho už mám, změní se v uvažování něco? V podstatě můžu spouštět vlákna ve stejném procesu, pracovat nad stejnou pamětí, ale lze to nazvat databází? Ale bude to asi nejpodobnější tomu Smalltalku.

Ano, změní: Základním pravidlem je: Tell, don't ask. Když to neuděláš, děláš ze svého objektu v paměti cache. A špinavé cache jsou jedním ze dvou zel v programování právě proto, že demolují transakce.
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: Idris 25. 04. 2021, 00:29:58
Hlavně tam nesmí být takové to:
Kód: [Vybrat]
entity = connection.query(anything)
entity.name = "Jozef"
connection.persist(entity)
Jak bys řešil transakce?

Vycházíš z ne úplně odůvodněného předpokladu, že to mám promyšlené.

cca takhle, asi, možná:

Kód: [Vybrat]
posts = Collection<Post>
users = Collection<User>
try {
    author = User("John", "Dee")
    item = Post(author, "title", "content")
    item.discuss.add(Comment("author 1", "lorem ipsum 1"))
    item.discuss.add(Comment("author 2", "lorem ipsum 2"))
    posts.add(item)
    users.add(author)
}
catch (Exception e) {
    console.log(e.message)
}

Transakce slouží k tomu, aby vytvořili atomický blok. Mohu na to vytvořit spešl syntax, nebo zneužít třeba ty výjimky. Ta atomicita způsobí, že dokud není dokončeno, tak se změna neprojeví nikde, ani v jiném vláknu té samé instance, ani v jiné instanci sdílící stejný stav.


Shodou okolností reálný kód na neidealistické platformě (pseudokod):
Kód: [Vybrat]
posts = Collection<Post>
users = Collection<User>
conn.transaction(conn => {
    author = User("John", "Dee")
    item = Post(author, "title", "content")
    item.discuss.add(Comment("author 1", "lorem ipsum 1"))
    item.discuss.add(Comment("author 2", "lorem ipsum 2"))
    posts.add(item)
    users.add(author)
    conn.flush(posts)
    conn.flush(users)
}, e => {
    console.log(e.message)
})

Výše uvedený kód by pak měl vypadat takto:
Kód: [Vybrat]
try {
    entity = users.find(anything)
    entity.name = "Jozef"
}
catch (Exception e) {
    console.log(e.message)
}
Právě, ta atomicita vyžaduje kód navíc, okolo jádra kódu. Co jazyk bez výjimek?
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: Idris 25. 04. 2021, 00:33:42
Případně, pokud chci transakčnost, tak:
- začni atomický blok
- najdi v poli požadovaný záznam
- uprav v něm co potřebuješ
- commit
Tohle zní slibně. Takhle nějak fungoval jeden z módů db4objects.
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: BoneFlute 25. 04. 2021, 00:34:01
Právě, ta atomicita vyžaduje kód navíc, okolo jádra kódu. Co jazyk bez výjimek?

Transakce slouží k tomu, aby vytvořili atomický blok. Mohu na to vytvořit spešl syntax, nebo zneužít třeba ty výjimky. Ta atomicita způsobí, že dokud není dokončeno, tak se změna neprojeví nikde, ani v jiném vláknu té samé instance, ani v jiné instanci sdílící stejný stav.

Kód: [Vybrat]
posts = Collection<Post>
users = Collection<User>
transaction {
    author = User("John", "Dee")
    item = Post(author, "title", "content")
    item.discuss.add(Comment("author 1", "lorem ipsum 1"))
    item.discuss.add(Comment("author 2", "lorem ipsum 2"))
    posts.add(item)
    users.add(author)
}
fail (Error e) {
    console.log(e.message)
}
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: Idris 25. 04. 2021, 00:41:03
Právě, ta atomicita vyžaduje kód navíc, okolo jádra kódu. Co jazyk bez výjimek?

Transakce slouží k tomu, aby vytvořili atomický blok. Mohu na to vytvořit spešl syntax, nebo zneužít třeba ty výjimky. Ta atomicita způsobí, že dokud není dokončeno, tak se změna neprojeví nikde, ani v jiném vláknu té samé instance, ani v jiné instanci sdílící stejný stav.

Kód: [Vybrat]
posts = Collection<Post>
users = Collection<User>
transaction {
    author = User("John", "Dee")
    item = Post(author, "title", "content")
    item.discuss.add(Comment("author 1", "lorem ipsum 1"))
    item.discuss.add(Comment("author 2", "lorem ipsum 2"))
    posts.add(item)
    users.add(author)
}
fail (Error e) {
    console.log(e.message)
}
To jsou přejmenované výjimky ;)
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: BoneFlute 25. 04. 2021, 00:42:18
Právě, ta atomicita vyžaduje kód navíc, okolo jádra kódu. Co jazyk bez výjimek?

Transakce slouží k tomu, aby vytvořili atomický blok. Mohu na to vytvořit spešl syntax, nebo zneužít třeba ty výjimky. Ta atomicita způsobí, že dokud není dokončeno, tak se změna neprojeví nikde, ani v jiném vláknu té samé instance, ani v jiné instanci sdílící stejný stav.

Kód: [Vybrat]
posts = Collection<Post>
users = Collection<User>
transaction {
    author = User("John", "Dee")
    item = Post(author, "title", "content")
    item.discuss.add(Comment("author 1", "lorem ipsum 1"))
    item.discuss.add(Comment("author 2", "lorem ipsum 2"))
    posts.add(item)
    users.add(author)
}
fail (Error e) {
    console.log(e.message)
}
To jsou přejmenované výjimky ;)
Vypadá to podobně, že jo? :-)
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: Idris 25. 04. 2021, 00:51:01
Právě, ta atomicita vyžaduje kód navíc, okolo jádra kódu. Co jazyk bez výjimek?

Transakce slouží k tomu, aby vytvořili atomický blok. Mohu na to vytvořit spešl syntax, nebo zneužít třeba ty výjimky. Ta atomicita způsobí, že dokud není dokončeno, tak se změna neprojeví nikde, ani v jiném vláknu té samé instance, ani v jiné instanci sdílící stejný stav.

Kód: [Vybrat]
posts = Collection<Post>
users = Collection<User>
transaction {
    author = User("John", "Dee")
    item = Post(author, "title", "content")
    item.discuss.add(Comment("author 1", "lorem ipsum 1"))
    item.discuss.add(Comment("author 2", "lorem ipsum 2"))
    posts.add(item)
    users.add(author)
}
fail (Error e) {
    console.log(e.message)
}
To jsou přejmenované výjimky ;)
Vypadá to podobně, že jo? :-)
Tahle tvá úvaha o transparentní perzistenci mě vrací o 15 let zpátky, kdy jsem objektové databáze řešil v projektech. Těch problémů bylo víc, třeba existence více kopií stejného objektu v paměti (tehdy ještě nebyl Rust zajišťující unikátní měnitelné reference). Třeba ty typově bezpečné dotazy se běžně řešily přetěžováním operátorů.

Co když třeba najdu objekt v kolekci, pošlu ho kanálem (CSP) na jiný stroj a tam ho změním? :)
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: Ondrej Nemecek 25. 04. 2021, 01:06:26
Jde o styl uvažování. Dneska, díky okolnostem, je ten způsob uvažování následující:
- vytáhni z persistence
- uprav
- ulož zpět do persistence

Což je naprosto umělé. A správně by to mělo být:
- najdi v poli [1] požadovaný záznam
- uprav v něm co potřebuješ

Případně, pokud chci transakčnost, tak:
- začni atomický blok
- najdi v poli požadovaný záznam
- uprav v něm co potřebuješ
- commit

Transakce je v pohodě, o tom není řeč. Co považuji za umělé je to vytahování odněkud a pak to tam opět vracení.


1/ úplně obyčejném, nespeciálním, v žádném ORM nasledovaném

Jo, to se mi líbí. Tak ještě jak implementovat ten commit? Tím se ta Kitova špinavá cache přesune do ... transakčního manažera? A ten si udělá tu dočasnou kopii?
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: BoneFlute 25. 04. 2021, 01:07:22
Tahle tvá úvaha o transparentní perzistenci mě vrací o 15 let zpátky, kdy jsem objektové databáze řešil v projektech. Těch problémů bylo víc, třeba existence více kopií stejného objektu v paměti (tehdy ještě nebyl Rust zajišťující unikátní měnitelné reference). Třeba ty typově bezpečné dotazy se běžně řešily přetěžováním operátorů.
Pojďme si o těch problémech pokecat. Zajímá mě to.

Celá ta má úvaha je postavená na tom, že data persisteuju implicitně. Jinak všechny techniky, které známe se budou používat podobně.

třeba existence více kopií stejného objektu v paměti
Úplně nevím, v čem by měl být problém...
Pět referencí na stejný objekt? (jsme v OOP), ok, bude pět referencí na stejný objekt i v jiné instanci. Změním hodnotu v první referenci, změní se i v těch devíti ostatních.
Čtyři kopie jednoho objektu? ok, bude pět separé objektů i v druhé instanci. Změním hodnotu jednoho objektu, změní se hodnota právě toho stejného objektu v druhé instanci.


Co když třeba najdu objekt v kolekci, pošlu ho kanálem (CSP) na jiný stroj a tam ho změním? :)
Když ho pošlu tím kanálem, ztratím nad ním vlastnictví? Pokud ne, tak se mi změní v instanci, ze které jsem jej poslal, i v druhé instanci.
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: BoneFlute 25. 04. 2021, 01:12:10
Jde o styl uvažování. Dneska, díky okolnostem, je ten způsob uvažování následující:
- vytáhni z persistence
- uprav
- ulož zpět do persistence

Což je naprosto umělé. A správně by to mělo být:
- najdi v poli [1] požadovaný záznam
- uprav v něm co potřebuješ

Případně, pokud chci transakčnost, tak:
- začni atomický blok
- najdi v poli požadovaný záznam
- uprav v něm co potřebuješ
- commit

Transakce je v pohodě, o tom není řeč. Co považuji za umělé je to vytahování odněkud a pak to tam opět vracení.


1/ úplně obyčejném, nespeciálním, v žádném ORM nasledovaném

Jo, to se mi líbí. Tak ještě jak implementovat ten commit? Tím se ta Kitova špinavá cache přesune do ... transakčního manažera? A ten si udělá tu dočasnou kopii?
Jeho boj.
Atomický blok definuje, že dokavad ty změny nejsou provedeny všechny, tak žádné vlákno, a v našem případě ani žádná další instance aplikace sdílející stav, o tom nesmí vědět.
Stejně tak, když jsou transakce zanořené.

Jako je to úplná klasika, nic nového pod sluncem. Kdo dělá s DB, tak to určitě zná. Rozdíl je v tom, že tu máme transakčnost na úrovni jazyka, a nepracujeme (explicitně) s žádnou databází.
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: Idris 25. 04. 2021, 01:20:05
Co když třeba najdu objekt v kolekci, pošlu ho kanálem (CSP) na jiný stroj a tam ho změním? :)
Když ho pošlu tím kanálem, ztratím nad ním vlastnictví? Pokud ne, tak se mi změní v instanci, ze které jsem jej poslal, i v druhé instanci.
No právě, když chci, aby se změnil, není úplně jednoduché to naimplementovat. Teoreticky to vypadá hezky, ale všichni víme, jak spolehlivé jsou sítě.
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: BoneFlute 25. 04. 2021, 01:22:48
Co když třeba najdu objekt v kolekci, pošlu ho kanálem (CSP) na jiný stroj a tam ho změním? :)
Když ho pošlu tím kanálem, ztratím nad ním vlastnictví? Pokud ne, tak se mi změní v instanci, ze které jsem jej poslal, i v druhé instanci.
No právě, když chci, aby se změnil, není úplně jednoduché to naimplementovat. Teoreticky to vypadá hezky, ale všichni víme, jak spolehlivé jsou sítě.

To je jistě problém. Ale nesouvisí s mou vizí. Má vize je: udělá to engine/jazyk. Aktuální situace: musím si to naprogramovat sám.
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: Idris 25. 04. 2021, 01:27:46
Co když třeba najdu objekt v kolekci, pošlu ho kanálem (CSP) na jiný stroj a tam ho změním? :)
Když ho pošlu tím kanálem, ztratím nad ním vlastnictví? Pokud ne, tak se mi změní v instanci, ze které jsem jej poslal, i v druhé instanci.
No právě, když chci, aby se změnil, není úplně jednoduché to naimplementovat. Teoreticky to vypadá hezky, ale všichni víme, jak spolehlivé jsou sítě.
To je jistě problém. Ale nesouvisí s mou vizí. Má vize je: udělá to engine/jazyk. Aktuální situace: musím si to naprogramovat sám.
OK. Teď už jen brainstormuju, ale co když mám třeba:
Kód: [Vybrat]
let obj = ... // fetch somehow an object
remoteChannel <- obj
for i in range(0, obj.size) { ... }
A teď mi příjemce na druhé straně síťového kanálu změní size (řekněme, že hodnotu zmenší). Co se stane s tím for-cyklem?
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: Ondrej Nemecek 25. 04. 2021, 01:42:30
Kód: [Vybrat]
let obj = ... // fetch somehow an object
remoteChannel <- obj
for i in range(0, obj.size) { ... }
A teď mi příjemce na druhé straně síťového kanálu změní size (řekněme, že hodnotu zmenší). Co se stane s tím for-cyklem?

Jako že za běhu cyklu změní size použitý v podmínce cyklu? Stane se IMHO to stejné jako pokud na tu size sáhnu z jiného vlákna?
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: BoneFlute 25. 04. 2021, 01:46:21
Kód: [Vybrat]
let obj = ... // fetch somehow an object
remoteChannel <- obj
for i in range(0, obj.size) { ... }
A teď mi příjemce na druhé straně síťového kanálu změní size (řekněme, že hodnotu zmenší). Co se stane s tím for-cyklem?

Jako že za běhu cyklu změní size použitý v podmínce cyklu? Stane se IMHO to stejné jako pokud na tu size sáhnu z jiného vlákna?
Viděl bych to tak.

Některé jazyky pro foreach vytvoří kopii té kolekce (varianta optimistické transakce).
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: Idris 25. 04. 2021, 01:55:01
Kód: [Vybrat]
let obj = ... // fetch somehow an object
remoteChannel <- obj
for i in range(0, obj.size) { ... }
A teď mi příjemce na druhé straně síťového kanálu změní size (řekněme, že hodnotu zmenší). Co se stane s tím for-cyklem?

Jako že za běhu cyklu změní size použitý v podmínce cyklu? Stane se IMHO to stejné jako pokud na tu size sáhnu z jiného vlákna?
Viděl bych to tak.

Některé jazyky pro foreach vytvoří kopii té kolekce (varianta optimistické transakce).
To je jen ilustrace možných problémů. V rámci jedné aplikace se dají změny z jiného vlákna (nebo korutiny) ohlídat (v Rustu v době překladu), ale nad změnami na jiném stroji už člověk kontrolu nemá. Vytvoření kopie range řešení není, když ten objekt už bude menší.
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: Ondrej Nemecek 25. 04. 2021, 02:01:07
Kód: [Vybrat]
let obj = ... // fetch somehow an object
remoteChannel <- obj
for i in range(0, obj.size) { ... }
A teď mi příjemce na druhé straně síťového kanálu změní size (řekněme, že hodnotu zmenší). Co se stane s tím for-cyklem?

Jako že za běhu cyklu změní size použitý v podmínce cyklu? Stane se IMHO to stejné jako pokud na tu size sáhnu z jiného vlákna?
Viděl bych to tak.

Některé jazyky pro foreach vytvoří kopii té kolekce (varianta optimistické transakce).
To je jen ilustrace možných problémů. V rámci jedné aplikace se dají změny z jiného vlákna (nebo korutiny) ohlídat (v Rustu v době překladu), ale nad změnami na jiném stroji už člověk kontrolu nemá. Vytvoření kopie range řešení není, když ten objekt už bude menší.

Ale v principu to jsou úplně stejné problémy konkurentního přístupu jako u jediné aplikace, ne? Které by šly řešit nějakou distribuovanou transakcí? Což tedy asi může vést k tomu že to jako celek bude hrozně pomalé a deadlockující...
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: Idris 25. 04. 2021, 02:05:18
Kód: [Vybrat]
let obj = ... // fetch somehow an object
remoteChannel <- obj
for i in range(0, obj.size) { ... }
A teď mi příjemce na druhé straně síťového kanálu změní size (řekněme, že hodnotu zmenší). Co se stane s tím for-cyklem?

Jako že za běhu cyklu změní size použitý v podmínce cyklu? Stane se IMHO to stejné jako pokud na tu size sáhnu z jiného vlákna?
Viděl bych to tak.

Některé jazyky pro foreach vytvoří kopii té kolekce (varianta optimistické transakce).
To je jen ilustrace možných problémů. V rámci jedné aplikace se dají změny z jiného vlákna (nebo korutiny) ohlídat (v Rustu v době překladu), ale nad změnami na jiném stroji už člověk kontrolu nemá. Vytvoření kopie range řešení není, když ten objekt už bude menší.
Ale v principu to jsou úplně stejné problémy konkurentního přístupu jako u jediné aplikace, ne? Které by šly řešit nějakou distribuovanou transakcí?
Ano, nejspíš to tak je. Ale distr. transakce jsou celkem velká komplikace. Možná právě tento typ problémů tenhle typ řešení persistence zazdil? Na mě to působí jako málo muziky za hodně peněz. Každopádně nevím o žádné implementaci, která by nebyla jen akademickým experimentem. Ale úvahy to jsou bezpochyby zajímavé.
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: BoneFlute 25. 04. 2021, 02:10:30
Vytvoření kopie range řešení není, když ten objekt už bude menší.
hluboké kopie

Každopádně tento problém má řekl bych celkem snadné řešení. Pokud se tedy bavíme o těch kanálech. Když objekt opustí instanci, tak už jej instance nevlastní. Vyřešeno dvacet.

Pokud se bavíme čistě jen o tom "kloudu" instancí, tak prostě klasický problém jako kdyby to byla databáze. Co se stane když někdo smaže prvek z kolekce v jiné instanci?:
Kód: [Vybrat]
trx = conn.startTransaction()
for x in range(trx.query(....)) { .... }
trx.commit()
A jsou na to už provařené odpovědi. Řekl bych.
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: BoneFlute 25. 04. 2021, 02:14:41
Ano, nejspíš to tak je. Ale distr. transakce jsou celkem velká komplikace. Možná právě tento typ problémů tenhle typ řešení persistence zazdil? Na mě to působí jako málo muziky za hodně peněz. Každopádně nevím o žádné implementaci, která by nebyla jen akademickým experimentem. Ale úvahy to jsou bezpochyby zajímavé.
Mě se to nezdá. Na základě kanálů, které se začali používat v posledním roce dokazuješ, že se to proto neujalo?

IMHO se to neujalo proto, páč na začátku jsme u C byli rádi, když přišel GC. Pozdějc přišla móda dynamický jazyků se svým "hele jak hezky se to dá napsat". A pak už se usadil ten mindset, že data se vytahují a vrací z/do persistence. Technické obtíže bych v tom nehledal.
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: Idris 25. 04. 2021, 02:34:11
Ano, nejspíš to tak je. Ale distr. transakce jsou celkem velká komplikace. Možná právě tento typ problémů tenhle typ řešení persistence zazdil? Na mě to působí jako málo muziky za hodně peněz. Každopádně nevím o žádné implementaci, která by nebyla jen akademickým experimentem. Ale úvahy to jsou bezpochyby zajímavé.
Mě se to nezdá. Na základě kanálů, které se začali používat v posledním roce dokazuješ, že se to proto neujalo?

IMHO se to neujalo proto, páč na začátku jsme u C byli rádi, když přišel GC. Pozdějc přišla móda dynamický jazyků se svým "hele jak hezky se to dá napsat". A pak už se usadil ten mindset, že data se vytahují a vrací z/do persistence. Technické obtíže bych v tom nehledal.
Nic nedokazuju, ani na to nemám vyhraněný názor a nejspíš vůbec nejde říct jeden důvod neúspěchu. Nicméně v tomto případě je mnoho technických komplikací, které nějakou dostatečně robustní implementaci sabotují. Už jen u těch distr. objektů (bez úložiště) vznikaly problémy se správou paměti, asynchronním zpracováním apod.

Enterprise Objects Framework je asi jediná technologie, která ty největší problémy se ctí překonala.
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: Pavel Stěhule 25. 04. 2021, 08:05:09
Případně, pokud chci transakčnost, tak:
- začni atomický blok
- najdi v poli požadovaný záznam
- uprav v něm co potřebuješ
- commit
Tohle zní slibně. Takhle nějak fungoval jeden z módů db4objects.

Tenhle postup je důvod, proč jsou objektové databáze i vlastně i věci napsané nad ORM pomalé. Pokud objekt není už v paměti, tak načtení objektů po jednom je drahé (počínaje diskovými operacemi a konče sítí). Částečným řešením je držet si objekty v RAMce - ale tím se dostanete do problémů s udržením konzistence, zamykáním a se správou cache. A navíc potřebujete kopii databáze v paměti. V momentě, kdy se mi hromadná operace změní na cyklus nad individuálními operacemi, tak jde výkon do háje.

Oproti objektovému přístupu SQL popisuje pouze hromadné operace (operace nad relacemi). Operace nad jedním záznamem je jen jeden speciální případ. Díky tomu má optimalizátor prostor pro výběr z implementací vhodné pro zpracování většího množství záznamů (seq scan, merge join) nebo naopak menšího množství (index scan, nested loop). Podle mne je tohle základní problém.

Když se pracuje s izolovanými hodnotami, tak objektové databáze nebo ORMka nemají jediný problém. Ale pro hromadné operace, tam vlastně není moc prostoru jak je implementovat efektivně (neduplikovat objekty v RAM, redukovat síťové operace, redukovat diskové operace). Řešitelné by to podle mne bylo - tytéž operace, které dělám nad objektem bych měl být schopen udělat nad kolekcí objektů - a mohlo by to fungovat pokud by vývojář použil tento interface. Jakmile programátor ale použije cyklus, tak tam není možná optimalizace - ledaže by se reimplementoval cyklus, a že by klient dokázal distribuovat volání operací na databázový server - a že by databáze dokázala pro implementaci cyklu použít vlastní optimální algoritmus (seq scan nebo index scan).

Chápu, že programátor chce být odizolován od implementace uložení dat. Nicméně je potřeba počítat, že data se mezi storage a aplikací nepřesouvají nekonečně rychle, a že je vždy režie na záznam, a na operaci. A totéž platí i o načítání dat. Pokud pak používám interface, který určuje, že mám pracovat s konkrétním záznamem, tak už neumožňuji efektivní implementaci (rozdíl v rychlostech v přístupech k izolovaným hodnotám a v hromadných operacích) může být i o řád nebo o dva. Pokud máte v datech milióny, desítky miliónů záznamů, tak rozdíl v efektivním a neefektivním zpracování bude v hodinách.

Co zaznělo v diskuzi, tak se vývojáři objektových databází zaměřili na co nejlepší bezešvou integraci databáze s objektovým prostředím. Ale pak naráží na  efektivitu přístupu ke uložišti. SQL databáze na to jdou úplně z druhé strany. V prvé řadě řeší efektivitu přístupu k datům (minimalizace random IO, minimalizace přenesených dat po síti). Pokud mám data uložená lokálně (nedochází ke sdílení, nemusím řešit síťovou komunikaci, data jsou na ssd - nemusím řešit random IO), tak ten objektový přístup může fungovat. V opačném případě si to moc nedovedu představit. SQL databáze se snaží vývojáře izolovat od některých implementačních detailů (nemusí řešit jestli se použije seq io nebo random IO, nemusí řešit síťovou komunikaci) - a tím končí. Vůbec se nesnaží o nějakou integraci s vývojovým prostředím. To ani nejde. Nemám a ani nechci Postgres pro Javu, a jiný pro C#.
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: Idris 25. 04. 2021, 10:14:06
Co zaznělo v diskuzi, tak se vývojáři objektových databází zaměřili na co nejlepší bezešvou integraci databáze s objektovým prostředím. Ale pak naráží na  efektivitu přístupu ke uložišti. SQL databáze na to jdou úplně z druhé strany. V prvé řadě řeší efektivitu přístupu k datům (minimalizace random IO, minimalizace přenesených dat po síti). Pokud mám data uložená lokálně (nedochází ke sdílení, nemusím řešit síťovou komunikaci, data jsou na ssd - nemusím řešit random IO), tak ten objektový přístup může fungovat. V opačném případě si to moc nedovedu představit. SQL databáze se snaží vývojáře izolovat od některých implementačních detailů (nemusí řešit jestli se použije seq io nebo random IO, nemusí řešit síťovou komunikaci) - a tím končí. Vůbec se nesnaží o nějakou integraci s vývojovým prostředím. To ani nejde. Nemám a ani nechci Postgres pro Javu, a jiný pro C#.
Většina objektových databází, co se aspoň trochu chytly, fungovala lokálně (embedded). DB servery, co se nabízely, byly často nadstavbou nad tím lokálním řešením. Co si tak matně pamatuju db4objects, tak si v paměti držela výsledky dotazů v kolekci proxy objektů, které se nahrály do paměti, jakmile k nim chtěl kód přistupovat.
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: Ondrej Nemecek 25. 04. 2021, 17:26:15
(...)

Když se pracuje s izolovanými hodnotami, tak objektové databáze nebo ORMka nemají jediný problém. Ale pro hromadné operace, tam vlastně není moc prostoru jak je implementovat efektivně (neduplikovat objekty v RAM, redukovat síťové operace, redukovat diskové operace). Řešitelné by to podle mne bylo - tytéž operace, které dělám nad objektem bych měl být schopen udělat nad kolekcí objektů - a mohlo by to fungovat pokud by vývojář použil tento interface.

(...)

Takže pokud je objektový graf v paměti, nebude mít ani objektové databáze s hromadnou operací nějaký zásadní výkonnostní problém (cyklus se změnou nějaké hodnoty u kolekce objektů může být docela rychlá operace, navíc to asi půjde v řadě případů i paralelizovat). Hlavní benefit by přitom byl nulový object-relational impedance mismatch (neznám český ekvivalent tohoto pojmu). Ten sám o sobě přináší výkonnostní problémy, takže v reálných projektech by pak mohla být objektová databáze naopak rychlejší než neoptimálně použité ORM, kde navíc hrozí  i nekonzistence (při neobratném použití), což zase eliminuje další killer feature sql databází (konzistenci).

Konceptem in-memory objektové databáze se pohybujeme cca někde na úrovni toho Smalltalku, který taky ukládá image na disk až na ruční vyžádání. Čili se nakonec celá debata vede o tom, co z ACID (atomicity, consistency, isolation, durability) mohou objektové (či NoSQL) databáze vlastně nabídnout. A téma o možnosti objektovou databázi provozovat distribuovaně napříč stroji je další level téhož.
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: Pavel Stěhule 25. 04. 2021, 17:51:23
Takže pokud je objektový graf v paměti, nebude mít ani objektové databáze s hromadnou operací nějaký zásadní výkonnostní problém (cyklus se změnou nějaké hodnoty u kolekce objektů může být docela rychlá operace, navíc to asi půjde v řadě případů i paralelizovat). Hlavní benefit by přitom byl nulový object-relational impedance mismatch (neznám český ekvivalent tohoto pojmu). Ten sám o sobě přináší výkonnostní problémy, takže v reálných projektech by pak mohla být objektová databáze naopak rychlejší než neoptimálně použité ORM, kde navíc hrozí  i nekonzistence (při neobratném použití), což zase eliminuje další killer feature sql databází (konzistenci).

Konceptem in-memory objektové databáze se pohybujeme cca někde na úrovni toho Smalltalku, který taky ukládá image na disk až na ruční vyžádání. Čili se nakonec celá debata vede o tom, co z ACID (atomicity, consistency, isolation, durability) mohou objektové (či NoSQL) databáze vlastně nabídnout. A téma o možnosti objektovou databázi provozovat distribuovaně napříč stroji je další level téhož.

Pokud to bude inmemory a na aplikačním serveru, tak by výkon mohl být ok. Nicméně asi stejně potřebujete něco ve smyslu indexů (ať už nějaké stromy nebo hash tabulky). Je otázkou, jak by se to chovalo po studeném startu. Jinak samozřejmě, výkon a chování by mělo být +/- srovnatelné s ostatními inmemory databázemi. Ale i mezi inmemory databázemi mohou být výkonnostní rozdíly - v extrému se řeší i design, který minimalizuje výpadky CPU cache - on random access nesvědčí ani RAMce
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: BoneFlute 25. 04. 2021, 21:25:08
Případně, pokud chci transakčnost, tak:
- začni atomický blok
- najdi v poli požadovaný záznam
- uprav v něm co potřebuješ
- commit
Tohle zní slibně. Takhle nějak fungoval jeden z módů db4objects.

Tenhle postup je důvod, proč jsou objektové databáze i vlastně i věci napsané nad ORM pomalé. Pokud objekt není už v paměti, tak načtení objektů po jednom je drahé (počínaje diskovými operacemi a konče sítí). Částečným řešením je držet si objekty v RAMce - ale tím se dostanete do problémů s udržením konzistence, zamykáním a se správou cache. A navíc potřebujete kopii databáze v paměti. V momentě, kdy se mi hromadná operace změní na cyklus nad individuálními operacemi, tak jde výkon do háje.

Oproti objektovému přístupu SQL popisuje pouze hromadné operace (operace nad relacemi). Operace nad jedním záznamem je jen jeden speciální případ. Díky tomu má optimalizátor prostor pro výběr z implementací vhodné pro zpracování většího množství záznamů (seq scan, merge join) nebo naopak menšího množství (index scan, nested loop). Podle mne je tohle základní problém.

Když se pracuje s izolovanými hodnotami, tak objektové databáze nebo ORMka nemají jediný problém. Ale pro hromadné operace, tam vlastně není moc prostoru jak je implementovat efektivně (neduplikovat objekty v RAM, redukovat síťové operace, redukovat diskové operace). Řešitelné by to podle mne bylo - tytéž operace, které dělám nad objektem bych měl být schopen udělat nad kolekcí objektů - a mohlo by to fungovat pokud by vývojář použil tento interface. Jakmile programátor ale použije cyklus, tak tam není možná optimalizace - ledaže by se reimplementoval cyklus, a že by klient dokázal distribuovat volání operací na databázový server - a že by databáze dokázala pro implementaci cyklu použít vlastní optimální algoritmus (seq scan nebo index scan).

Chápu, že programátor chce být odizolován od implementace uložení dat. Nicméně je potřeba počítat, že data se mezi storage a aplikací nepřesouvají nekonečně rychle, a že je vždy režie na záznam, a na operaci. A totéž platí i o načítání dat. Pokud pak používám interface, který určuje, že mám pracovat s konkrétním záznamem, tak už neumožňuji efektivní implementaci (rozdíl v rychlostech v přístupech k izolovaným hodnotám a v hromadných operacích) může být i o řád nebo o dva. Pokud máte v datech milióny, desítky miliónů záznamů, tak rozdíl v efektivním a neefektivním zpracování bude v hodinách.

Co zaznělo v diskuzi, tak se vývojáři objektových databází zaměřili na co nejlepší bezešvou integraci databáze s objektovým prostředím. Ale pak naráží na  efektivitu přístupu ke uložišti. SQL databáze na to jdou úplně z druhé strany. V prvé řadě řeší efektivitu přístupu k datům (minimalizace random IO, minimalizace přenesených dat po síti). Pokud mám data uložená lokálně (nedochází ke sdílení, nemusím řešit síťovou komunikaci, data jsou na ssd - nemusím řešit random IO), tak ten objektový přístup může fungovat. V opačném případě si to moc nedovedu představit. SQL databáze se snaží vývojáře izolovat od některých implementačních detailů (nemusí řešit jestli se použije seq io nebo random IO, nemusí řešit síťovou komunikaci) - a tím končí. Vůbec se nesnaží o nějakou integraci s vývojovým prostředím. To ani nejde. Nemám a ani nechci Postgres pro Javu, a jiný pro C#.

Ano, to je další výhoda databáze jako externího řešení. Snadnější implementace.

Každopádně, abych spojil tvé připomínky s mou vizí:

Klasické řešení:
Kód: [Vybrat]
foreach (x in conn.query('SELECT * FROM post WHERE name LIKE ?', "Jozef%")) {
  format(map2object(x))
}

ORM řešení:
Kód: [Vybrat]
foreach (x in orm.find<Post>(type(Post).name.like("%Jozef%"))) {
   format(x)
}

se přeloží na:
Kód: [Vybrat]
foreach (x in conn.query('SELECT * FROM post WHERE name LIKE ?', "Jozef%")) {
  format(map2object(x))
}


Moje vize:
Kód: [Vybrat]
foreach (x in posts) {
    if startWith(x.name, "Jozef") {
        format(x)
    }
}

se přeloží na:
Kód: [Vybrat]
foreach (x in conn.query('SELECT * FROM post WHERE name LIKE ?', "Jozef%")) {
  format(map2object(x))
}

ORM jsou pomalé svině. Ale ne proto, že by pomalé být musely. Není důvod, aby se načítali po jednom. A v mnoha případech se i načítají velice chytře. Vůbec, obecně vzato není důvod si myslet, že by ORM neměli být stejně chytré, jako ručně psané SQL. IMHO je to stejný vývoj, jako ruční správa paměti -> GC -> escape analýza. Ručně psané ASM -> C -> JustInTime. Je to jen otázka času.
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: BoneFlute 25. 04. 2021, 21:27:39
Čili se nakonec celá debata vede o tom, co z ACID (atomicity, consistency, isolation, durability) mohou objektové (či NoSQL) databáze vlastně nabídnout.
No, já bych prosil komplet. Jinak nemám důvod PostgreSQL opouštět.
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: Idris 25. 04. 2021, 21:29:31
ORM jsou pomalé svině. Ale ne proto, že by pomalé být musely. Není důvod, aby se načítali po jednom. A v mnoha případech se i načítají velice chytře. Vůbec, obecně vzato není důvod si myslet, že by ORM neměli být stejně chytré, jako ručně psané SQL. IMHO je to stejný vývoj, jako ruční správa paměti -> GC -> escape analýza. Ručně psané ASM -> C -> JustInTime. Je to jen otázka času.
Tak mě v této souvislosti napadá, že místo kolekcí s proxy objekty, používaných v současných objektových databázích, by byly efektivnější streamy (bez proxy objektů).
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: Pavel Stěhule 25. 04. 2021, 22:01:27
ORM jsou pomalé svině. Ale ne proto, že by pomalé být musely. Není důvod, aby se načítali po jednom. A v mnoha případech se i načítají velice chytře. Vůbec, obecně vzato není důvod si myslet, že by ORM neměli být stejně chytré, jako ručně psané SQL. IMHO je to stejný vývoj, jako ruční správa paměti -> GC -> escape analýza. Ručně psané ASM -> C -> JustInTime. Je to jen otázka času.

Tohle nejde rozporovat :-). Koneckonců SQL je vlastně něco podobného. Funkcionalitu už tady zmíňeného ADABASu defacto představuje executor, a program napsaný v jazyku prováděcích plánů. Takže do jisté míry platí ADABAS (ISAM)->SQL. Jde jen o to, jak to udělat, aby z toho nelezl ten ISAM, případně aby nevznikl interface ještě komplikovanější než SQL. Aby došlo ke skutečnému technologickému progresu.
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: Ondrej Nemecek 25. 04. 2021, 22:08:48
ORM jsou pomalé svině. Ale ne proto, že by pomalé být musely. Není důvod, aby se načítali po jednom. A v mnoha případech se i načítají velice chytře. Vůbec, obecně vzato není důvod si myslet, že by ORM neměli být stejně chytré, jako ručně psané SQL. IMHO je to stejný vývoj, jako ruční správa paměti -> GC -> escape analýza. Ručně psané ASM -> C -> JustInTime. Je to jen otázka času.

ORM (např. jOOQ (https://www.jooq.org/)) mají API na zápis SQL 1:1, takže v dotazech asi hlavní problém nebude. Spíš jde o to že se leckdy kopíruje zbytečně sem a tam. Anebo teda, že se nepoužije join ale traversuje nějaká struktura s postupným načítáním závislých položek kus po kusu. A programátor si to nemusí uvědomit, protože z kódu není na první pohled vidět, co se děje pod kapotou.

Tak mě v této souvislosti napadá, že místo kolekcí s proxy objekty, používaných v současných objektových databázích, by byly efektivnější streamy (bez proxy objektů).

Ve kterých databázích? Je vůbec nějaků důvod, proč by funkcionální API (streamy, map, reduce) nemělo být pro objekty v paměti  dostatečné?
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: Idris 25. 04. 2021, 22:15:06
Ve kterých databázích? Je vůbec nějaků důvod, proč by funkcionální API (streamy, map, reduce) nemělo být pro objekty v paměti  dostatečné?
Například db4objects nebo Realm. Ono to právě není pro objekty v paměti, je to pro objekty na disku v embedded databázi. Proto tam mají ty proxy objekty. No a podle mě jsou lepším řešením streamy, ale možná mi uniká nějaký zásadní důvod, proč jsou proxy objekty lepší.
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: BoneFlute 25. 04. 2021, 23:46:45
ORM jsou pomalé svině. Ale ne proto, že by pomalé být musely. Není důvod, aby se načítali po jednom. A v mnoha případech se i načítají velice chytře. Vůbec, obecně vzato není důvod si myslet, že by ORM neměli být stejně chytré, jako ručně psané SQL. IMHO je to stejný vývoj, jako ruční správa paměti -> GC -> escape analýza. Ručně psané ASM -> C -> JustInTime. Je to jen otázka času.

Tohle nejde rozporovat :-). Koneckonců SQL je vlastně něco podobného. Funkcionalitu už tady zmíňeného ADABASu defacto představuje executor, a program napsaný v jazyku prováděcích plánů. Takže do jisté míry platí ADABAS (ISAM)->SQL. Jde jen o to, jak to udělat, aby z toho nelezl ten ISAM, případně aby nevznikl interface ještě komplikovanější než SQL. Aby došlo ke skutečnému technologickému progresu.
Moje idea je, že se to celé převrátí. Nebudeme se z aplikace dotazovat na data do databáze, ale budeme mít databázi, ve které bude napsaná aplikace. Další generace smalltalku.
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: Idris 26. 04. 2021, 00:07:24
ORM jsou pomalé svině. Ale ne proto, že by pomalé být musely. Není důvod, aby se načítali po jednom. A v mnoha případech se i načítají velice chytře. Vůbec, obecně vzato není důvod si myslet, že by ORM neměli být stejně chytré, jako ručně psané SQL. IMHO je to stejný vývoj, jako ruční správa paměti -> GC -> escape analýza. Ručně psané ASM -> C -> JustInTime. Je to jen otázka času.

Tohle nejde rozporovat :-). Koneckonců SQL je vlastně něco podobného. Funkcionalitu už tady zmíňeného ADABASu defacto představuje executor, a program napsaný v jazyku prováděcích plánů. Takže do jisté míry platí ADABAS (ISAM)->SQL. Jde jen o to, jak to udělat, aby z toho nelezl ten ISAM, případně aby nevznikl interface ještě komplikovanější než SQL. Aby došlo ke skutečnému technologickému progresu.
Moje idea je, že se to celé převrátí. Nebudeme se z aplikace dotazovat na data do databáze, ale budeme mít databázi, ve které bude napsaná aplikace. Další generace smalltalku.
A nechceš si napsat prototyp, ať se máme nad čím bavit? ;) Nevím, jestli přímo ve Smalltalku, ale určitě by to bylo zajímavé.
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: Ondrej Nemecek 26. 04. 2021, 00:25:40
Moje idea je, že se to celé převrátí. Nebudeme se z aplikace dotazovat na data do databáze, ale budeme mít databázi, ve které bude napsaná aplikace. Další generace smalltalku.
A nechceš si napsat prototyp, ať se máme nad čím bavit? ;) Nevím, jestli přímo ve Smalltalku, ale určitě by to bylo zajímavé.

Squeak Magma (https://wiki.squeak.org/squeak/2665)? Persistence by reachability, transparent access, multiple users via optimistic locking, transactions, proxies are used to truncate the portions of the domain model that are not currently in memory,  pretty good performance, robust querying with indexes... and more  :D


Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: BoneFlute 26. 04. 2021, 00:52:16
ORM jsou pomalé svině. Ale ne proto, že by pomalé být musely. Není důvod, aby se načítali po jednom. A v mnoha případech se i načítají velice chytře. Vůbec, obecně vzato není důvod si myslet, že by ORM neměli být stejně chytré, jako ručně psané SQL. IMHO je to stejný vývoj, jako ruční správa paměti -> GC -> escape analýza. Ručně psané ASM -> C -> JustInTime. Je to jen otázka času.

Tohle nejde rozporovat :-). Koneckonců SQL je vlastně něco podobného. Funkcionalitu už tady zmíňeného ADABASu defacto představuje executor, a program napsaný v jazyku prováděcích plánů. Takže do jisté míry platí ADABAS (ISAM)->SQL. Jde jen o to, jak to udělat, aby z toho nelezl ten ISAM, případně aby nevznikl interface ještě komplikovanější než SQL. Aby došlo ke skutečnému technologickému progresu.
Moje idea je, že se to celé převrátí. Nebudeme se z aplikace dotazovat na data do databáze, ale budeme mít databázi, ve které bude napsaná aplikace. Další generace smalltalku.
A nechceš si napsat prototyp, ať se máme nad čím bavit? ;) Nevím, jestli přímo ve Smalltalku, ale určitě by to bylo zajímavé.

Chci. Je to aktuálně můj primární hobby projekt. Ale je málo času, tak o tom maximálně žvaním tady na rootu :-)
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: Idris 26. 04. 2021, 00:59:01
ORM jsou pomalé svině. Ale ne proto, že by pomalé být musely. Není důvod, aby se načítali po jednom. A v mnoha případech se i načítají velice chytře. Vůbec, obecně vzato není důvod si myslet, že by ORM neměli být stejně chytré, jako ručně psané SQL. IMHO je to stejný vývoj, jako ruční správa paměti -> GC -> escape analýza. Ručně psané ASM -> C -> JustInTime. Je to jen otázka času.

Tohle nejde rozporovat :-). Koneckonců SQL je vlastně něco podobného. Funkcionalitu už tady zmíňeného ADABASu defacto představuje executor, a program napsaný v jazyku prováděcích plánů. Takže do jisté míry platí ADABAS (ISAM)->SQL. Jde jen o to, jak to udělat, aby z toho nelezl ten ISAM, případně aby nevznikl interface ještě komplikovanější než SQL. Aby došlo ke skutečnému technologickému progresu.
Moje idea je, že se to celé převrátí. Nebudeme se z aplikace dotazovat na data do databáze, ale budeme mít databázi, ve které bude napsaná aplikace. Další generace smalltalku.
A nechceš si napsat prototyp, ať se máme nad čím bavit? ;) Nevím, jestli přímo ve Smalltalku, ale určitě by to bylo zajímavé.
Chci. Je to aktuálně můj primární hobby projekt. Ale je málo času, tak o tom maximálně žvaním tady na rootu :-)
Ono by to nemělo být nijak zvlášť náročné, stačí nějaká atributová LR-gramatika na experimenty s interpretem ;) Akorát pozor, atributové (LR-)gramatiky mohou být NP-těžké a generovat/přijímat i dost divné kontextové jazyky (v exp. čase) :) Ale jinak to je zábava, zvlášť má-li být jazyk staticky typovaný a přitom nepříliš ukecaný.
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: Death Walker 26. 04. 2021, 09:26:31
ORM jsou pomalé svině. Ale ne proto, že by pomalé být musely. Není důvod, aby se načítali po jednom. A v mnoha případech se i načítají velice chytře. Vůbec, obecně vzato není důvod si myslet, že by ORM neměli být stejně chytré, jako ručně psané SQL. IMHO je to stejný vývoj, jako ruční správa paměti -> GC -> escape analýza. Ručně psané ASM -> C -> JustInTime. Je to jen otázka času.

Tohle nejde rozporovat :-). Koneckonců SQL je vlastně něco podobného. Funkcionalitu už tady zmíňeného ADABASu defacto představuje executor, a program napsaný v jazyku prováděcích plánů. Takže do jisté míry platí ADABAS (ISAM)->SQL. Jde jen o to, jak to udělat, aby z toho nelezl ten ISAM, případně aby nevznikl interface ještě komplikovanější než SQL. Aby došlo ke skutečnému technologickému progresu.
Moje idea je, že se to celé převrátí. Nebudeme se z aplikace dotazovat na data do databáze, ale budeme mít databázi, ve které bude napsaná aplikace. Další generace smalltalku.
A nechceš si napsat prototyp, ať se máme nad čím bavit? ;) Nevím, jestli přímo ve Smalltalku, ale určitě by to bylo zajímavé.

Chci. Je to aktuálně můj primární hobby projekt. Ale je málo času, tak o tom maximálně žvaním tady na rootu :-)


Na napisanie bussiness logiky do db je uz dostatok moznosti - https://wiki.postgresql.org/wiki/PL_Matrix

Nie je problem znapisat sp ktora ti json rozparsuje alebo funkciu ktora ti json vrati (https://www.postgresql.org/docs/current/functions-json.html) Podla mojich skusenosti, v plpgsql je to rychlejsie nez tu logiku riesit v php alebo v pythone a db volat len ako storage... To iste mozes aj v sql sevri, tam je transact sql, ale tam ma irituje ze niektore ddl dotazy su pod transakciou a ine nie...
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: Idris 26. 04. 2021, 10:43:10
Squeak Magma (https://wiki.squeak.org/squeak/2665)? Persistence by reachability [...] proxies are used to truncate the portions of the domain model that are not currently in memory
Koukám, že používání proxy objektů v obj. databázích je dost rozšířené. Jakpak by to asi udělali v C++ nebo Rustu :)
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: Ink 26. 04. 2021, 10:50:38
Squeak Magma (https://wiki.squeak.org/squeak/2665)? Persistence by reachability [...] proxies are used to truncate the portions of the domain model that are not currently in memory
Koukám, že používání proxy objektů v obj. databázích je dost rozšířené. Jakpak by to asi udělali v C++ nebo Rustu :)

V Rustu makrem, tipnul bych si.
Název: Re:MariaDB vs Postgres vs SQL Server
Přispěvatel: Idris 26. 04. 2021, 10:57:47
Squeak Magma (https://wiki.squeak.org/squeak/2665)? Persistence by reachability [...] proxies are used to truncate the portions of the domain model that are not currently in memory
Koukám, že používání proxy objektů v obj. databázích je dost rozšířené. Jakpak by to asi udělali v C++ nebo Rustu :)
V Rustu makrem, tipnul bych si.
Proxy makrem? To bych chtěl vidět, to bude hodně sofistikované.