MariaDB vs Postgres vs SQL Server

[BoneFlute]

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ě?

[Reklama]

[BoneFlute]

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.

[tomas88]

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.

[Idris]

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.

[BoneFlute]

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.

[Reklama]

[Jan Karasek]

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.

[Idris]

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

[BoneFlute]

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?

[BoneFlute]

V takovych diskuzich se pak cas od casu najdou lide, kteri upozorni, ze existuji i nadale 'nerelacni' cerpadla a ze by nebylo od veci se po takovych poohlednout.
V nasledne diskuzi ...

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

Takhle jsi to myslel? ;-)

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.

[BoneFlute]

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.

[Idris]

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

[Ondrej Nemecek]

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.

[Idris]

LINQtoSQL?

LINQ je náznak, jak by to zhruba mělo vypadat.

[Idris]

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 

[Ondrej Nemecek]

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:

Java version of Realm currently runs only on Android
https://github.com/realm/realm-java