Kniha Objektové programování od Čady

[SB]

O limitu jsem nic nepsal. Problém ORM frameworků je, že si člověk "snadno" kdekoliv v kódu šáhne pro cokoliv jako by to byla lokální proměnná a vůbec neřeší, jak ve skutečnosti budou vypadat ty dotazy, jaká s tím bude režie. V tom je ten ďábel v detailu.

To se dá ale ošetřit, taková db4o měla svého času konfigurovatelná omezení (není to ORM, ale čistě objektová databáze, což je zde ovšem irelevantní). Navíc když je někdo pablb, tak zprasí dotazy do DB i bez ORM.

Jistě, vysvětlovat řešení problému RDB na ODB je velice přínosné.

[Reklama]

[SB]

O limitu jsem nic nepsal. Problém ORM frameworků je, že si člověk "snadno" kdekoliv v kódu šáhne pro cokoliv jako by to byla lokální proměnná a vůbec neřeší, jak ve skutečnosti budou vypadat ty dotazy, jaká s tím bude režie. V tom je ten ďábel v detailu.

To stejné byste mohl napsat o každé technologii přidávající úroveň abstrakce. Když to používáte správně, ušetří vám to spoustu práce. Zejména pokud dlouhodobě pracujete se složitější databází a provádíte často podobné, ale ne úplně stejné dotazy. Kdybyste měl stále dokola zapisovat ty stejné joiny, tak byste se z toho zbláznil.

Asi tak. Problémem je především skutečnost, že p. Prýmek považuje použití ORM (což je logické, jinak by aplikace musela zůstat relační) za chybu, ale použití RDB na objektovou doménu mu přijde zcela v pořádku.

[SB]

Ona ta transpilace do JS nevadí, transpiler si většinou nestěžuje, že musí generovat prasokód (pokud to je program, ne nějaký Ind).

Je to vrstva navíc přidávající práci, chyby atd. Nadbytečné.

[Mirek Prýmek]

Asi tak. Problémem je především skutečnost, že p. Prýmek považuje použití ORM (což je logické, jinak by aplikace musela zůstat relační) za chybu, ale použití RDB na objektovou doménu mu přijde zcela v pořádku.

Ne. Já považuju za chybu používat jakoukoli knihovnu/framework/abstrakci, která je natolik složitá a neprůhledná, že programátor nedokáže pohledem na kód říct, co vlastně v danou chvíli udělá, a zároveň má potenciálně velmi zásadní vliv na výkon aplikace.

Můžu přidat i osobní zkušenost: v jednom projektu byla komponenta provádějící jakýsi relativně jednoduchý (kontextem parametrizovaný) výpočet nad daty přicházejícímu z vnějšku. Kdyby to dělal člověk ručně, načte si z DB předem cca pět čísel jedním dotazem a pak spustí výpočet, už kompletně bez side effectů, čili snadno paralelizovatelný atd. Ovšem historie tomu chtěla, že danou komponentu psal djangista, čili konfigurace byla uložena pomocí django ORM, načítala se pomocí nějakých magických django objektů a když to bylo v provozu, lámali jsme si hlavu nad tím, proč tak děsně zatěžuje DB. No, nenačítalo se pět čísel, ale nějaké modely, ORM se z nějakého důvodu rozhodl, že k tomu potřebuje i nějaké související hodnoty, takže se ve finále pořádně košatým JOINem načítalo i spousta věcí, které pro výpočet vůbec nebyly potřeba, a to ještě vesele kdykoli jakkoli, třeba uprostřed výpočtu. Nekontrolovatelně. Nádhera...

(Nechci se hádat o to, jestli tahle konkrétní situace jde nebo nejde v Djangu nějak potunit, pointa je v tom, že místo aby se udělala jednoduchá DB s jasnou strukturou a jednoduché SQL dotazy, kterým by každý rozuměl a uměl je ladit, použil se "pohodlný nástroj", který ve finále aplikaci úplně zabil)

[zboj]

Když už se tu začlo s ORM vs. RDB, proč v OO jazyce nepoužít přímo nějakou čistě objektovou databázi?

[Reklama]

[UF]

Když už se tu začlo s ORM vs. RDB, proč v OO jazyce nepoužít přímo nějakou čistě objektovou databázi?

a vo cem by se pak jako tady psalo?

[Youda]

Když už se tu začlo s ORM vs. RDB, proč v OO jazyce nepoužít přímo nějakou čistě objektovou databázi?

ORM, ElasticSearch nebo objektove databaze maji smysl, kdy je potreba ukladat male mnozstvi dat aplikace, napr pro ukladani konfigurace si user preferences.

Pokud ale aplikace ma zpracovavat vetsim mnozstvim externich dat, typicky treba generovani PDF faktur z databaze CRM systemu, pak je ORM totalne k hounu a dokaze zabit cely projekt. Externi data se typicky v objektove podobe nevyskytuji.
Kdyz architekt pak do projektu tupe nacpe ORM, protoze tak tomu bylo v tutorialu "Pet Shop", vysledek je otres.

[Kit]

Když už se tu začlo s ORM vs. RDB, proč v OO jazyce nepoužít přímo nějakou čistě objektovou databázi?

Běžně používám i objektové databáze a nevidím v tom problém. Při správném návrhu bývají o 2 řády výkonnější než běžný paskvil ORM+RDB.

[UF]

Pojem databaze je jeden z nejvetsich pruseru v IT vubec

[gll]

V čem konkrétně je to jiné kromě chybějících uvozovek? Dokázal byste uvést příklad použití atomu, pro který nelze použít string?

To je jako byste se ptal na příklad použití enumu, pro který nelze použít string.

Když použiju nedefinovaný atom, tak se vytvoří nový. To je chování stringu a ne enumu.

[UF]

V čem konkrétně je to jiné kromě chybějících uvozovek? Dokázal byste uvést příklad použití atomu, pro který nelze použít string?

To je jako byste se ptal na příklad použití enumu, pro který nelze použít string.

Když použiju nedefinovaný atom, tak se vytvoří nový. To je chování stringu a ne enumu.

Surova naprosto odzbrojujici uvaha pri niz clovek ztvrdne jako kamen naprosto - paralizovan. Vypalena jako kulka - znicujici. Neposkutuje moznost obrany - bez odpovedi. Proste tohle presne dokaze vyvolat to prave ticho.

[Mirek Prýmek]

Když použiju nedefinovaný atom, tak se vytvoří nový. To je chování stringu a ne enumu.

Jiste, kazde prirovnani v necem kulha.

Ze je atom v principu imutabilni, deduplikovany string, jsem uz napsal. Pokud chcete, muzete si atomy v libovolnem jazyce takhle implementovat. Ale tak jako tak to bude jiny typ nez string a budete se k nemu muset chovat jinak (kdyz prijde treba po siti, musite atom deduplikovat, string nemusite a v mnoha pripadech ani nemuzete). Cili je potreba je odlisit a JSON k tomu nedava zadny nastroj, narozdil od poradnych serializacnich formatu. Cili skoncite u "formatu nad formatem", napriklad takto:

Kód: [Vybrat]

{
"atom": {"type": "atom", value: "my_atom"},
"string": "myString"
}

Pokud chcete dobrou serializaci, musite totez udelat i pro int a float. A porad jeste nemate vyhrano, porad tady mame problem map s klici, ktere JSON nepodporuje. Takze tu budete muset pro zmenu implementovat nejspis jako

Kód: [Vybrat]

{"type": "general_map", "key_type": "...", value: [[..,..],[..,..]]
}

...coz je proste na palici. Ergo JSON je proste se skripenim zubu zkousnutelny pro jednoduche veci, ale jako obecny serializacni format je to peklo. A nechapu, proc opet musite krecovite obhajovat neobhajitelne...

[gll]

Když použiju nedefinovaný atom, tak se vytvoří nový. To je chování stringu a ne enumu.

Jiste, kazde prirovnani v necem kulha.

Ze je atom v principu imutabilni, deduplikovany string, jsem uz napsal. Pokud chcete, muzete si atomy v libovolnem jazyce takhle implementovat. Ale tak jako tak to bude jiny typ nez string a budete se k nemu muset chovat jinak (kdyz prijde treba po siti, musite atom deduplikovat, string nemusite a v mnoha pripadech ani nemuzete). Cili je potreba je odlisit a JSON k tomu nedava zadny nastroj, narozdil od poradnych serializacnich formatu. Cili skoncite u "formatu nad formatem", napriklad takto:

Kód: [Vybrat]

{
"atom": {"type": "atom", value: "my_atom"},
"string": "myString"
}

Pokud chcete dobrou serializaci, musite totez udelat i pro int a float. A porad jeste nemate vyhrano, porad tady mame problem map s klici, ktere JSON nepodporuje. Takze tu budete muset pro zmenu implementovat nejspis jako

Kód: [Vybrat]

{"type": "general_map", "key_type": "...", value: [[..,..],[..,..]]
}

...coz je proste na palici. Ergo JSON je proste se skripenim zubu zkousnutelny pro jednoduche veci, ale jako obecny serializacni format je to peklo. A nechapu, proc opet musite krecovite obhajovat neobhajitelne...

deduplikace proběhne automaticky.

JSON dnes jde otevřít v každém jazyku. Když chcete ukládat data specifická pro Erlang, můžete rovnou použít serializovaný Erlang.

[Mirek Prýmek]

Když chcete ukládat data specifická pro Erlang, můžete rovnou použít serializovaný Erlang.

A to je napad! To me nenapadlo. Cili vlastne JSON je skvely serializacni format, protoze kdyz neco neumi, muzu pouzit jiny format.

Genialni!

[JSfun]

A porad jeste nemate vyhrano, porad tady mame problem map s klici, ktere JSON nepodporuje.

Mapu muzes porad jednoduse spreadnout do pole a nestratis nic. To ze neco JS/JSON neumi, neznamena ze to nejde nebo, ze to je slozity implementovat.

Kód: [Vybrat]

var map = new Map([
  ['FOOTBALL_TEAM_NAME', 'FC Barcelona'],
  ['FOOTBALL_TEAM_NICK', 'Barca'],
  ['FOOTBALL_TEAM_ABBR', 'FCB'],
]);
// Map(3) {"FOOTBALL_TEAM_NAME" => "FC Barcelona", "FOOTBALL_TEAM_NICK" => "Barca", "FOOTBALL_TEAM_ABBR" => "FCB"}
var json = JSON.stringify([...map])
var map2 = new Map(JSON.parse(json))
// Map(3) {"FOOTBALL_TEAM_NAME" => "FC Barcelona", "FOOTBALL_TEAM_NICK" => "Barca", "FOOTBALL_TEAM_ABBR" => "FCB"}
map2.get("FOOTBALL_TEAM_ABBR")
// "FCB"