Příspěvky

361

Server / Re:MariaDB vs Postgres vs SQL Server

« kdy: 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.

362

Server / Re:MariaDB vs Postgres vs SQL Server

« kdy: 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?

363

Server / Re:MariaDB vs Postgres vs SQL Server

« kdy: 24. 04. 2021, 22:52:47 »

Distribuci změn dobře řešilo Lotus Notes/Domino nebo Groove.

Jak řešili konflikty?

364

Server / Re:MariaDB vs Postgres vs SQL Server

« kdy: 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.

365

Server / Re:MariaDB vs Postgres vs SQL Server

« kdy: 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í?

366

Server / Re:MariaDB vs Postgres vs SQL Server

« kdy: 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.

367

Server / Re:MariaDB vs Postgres vs SQL Server

« kdy: 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.

368

Server / Re:MariaDB vs Postgres vs SQL Server

« kdy: 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?

369

Server / Re:MariaDB vs Postgres vs SQL Server

« kdy: 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.

370

Server / Re:MariaDB vs Postgres vs SQL Server

« kdy: 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.

371

Server / Re:MariaDB vs Postgres vs SQL Server

« kdy: 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ě?

372

Server / Re:MariaDB vs Postgres vs SQL Server

« kdy: 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.

373

Server / Re:MariaDB vs Postgres vs SQL Server

« kdy: 23. 04. 2021, 22:06:00 »

jenže současné mainstreamové jazyky mají prostě omezenou syntax.

Uveď příklad prosím.

374

Server / Re:MariaDB vs Postgres vs SQL Server

« kdy: 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?

375

Server / Re:MariaDB vs Postgres vs SQL Server

« kdy: 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