MariaDB vs Postgres vs SQL Server

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

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?

[Reklama]

[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 

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.

[Kit]

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.

[BoneFlute]

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

[Idris]

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.

[Reklama]

[Ondrej Nemecek]

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.

[Idris]

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.

[BoneFlute]

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.

[BoneFlute]

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

Jak řešili konflikty?

[Idris]

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

[Idris]

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

[BoneFlute]

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?

[BoneFlute]

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.

[BoneFlute]

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

[Idris]

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