Rada při návrhu db tabulek

BoneFlute

  • *****
  • 1 733
    • Zobrazit profil
Re:Rada při návrhu db tabulek
« Odpověď #195 kdy: 07. 07. 2021, 00:20:27 »
Ale pracuje s tím i programátor,
Nepracuje. Proč by programátor měl vědět víc než ORM? Neví.
Zkus prosím toto zohlednit, a možná se posuneme dále.

Ani s tou milisekundou sem, milisekundou tam podle mě nemáte pravdu. Obecně ORM systémy generují vyšší počet dotazů. Když máte 50 dotazů na úkon, a na každém dotazu ztratíte 5 ms a k systému přistupuje 100 lidí, vytvoříte si lap 25 sekund. V lepším případě se to projeví jen tím, že každý uživatel čeká o čtvrt sekundy déle, což bývá přijatelné. V horším případě čekají transakce za sebou (kvůli ACID) a lap na uživatel je mnohem vyšší.
Já mluvil o milisekundách spálených na mapování výsledku dotazu na objektovou reprezentaci. V žádném případě na tom, že by ORM mělo posílat horší dotazy než by napsal vývojář.

Zbytek je opět sklouznutí ke steskům nad nekvalitou ORM.

Podle mě v úvahách směřujete spíš od ORM k nějaké objektové databázi,
Určitě ne.

Citace
Zde je naprosto mylně uvedený vztah. Nejedná se o ORM versus DB. Ale o ORM versus vývojář.Pokud je třeba získat nějaké informace, tak se ptáme - kdo je dokáže získat lépe stroj=ORM, nebo vývojář?
Ty, které může lépe získat stroj: tzn. statistiky atd...., ORM získat za rozumný čas nemůže, protože prostě na ně "nevidí". Nemá ty data, ty má DB. Proto je tato otázka chybně položená. Není problém v "STROJ versus VÝVOJÁŘ", problém je v tom, jaké možnosti má stroj na úrovni ORM vrstvy - a že kdybys chtěl ty problémy překonat, tak bys musel do té ORM vrstvy nutně zabudovat i celou databázi.
No a pak jsou informace, které prostě stroj (přinejmenším v dnešním stavu AI) získat prostě nemůže. To, co si od takového ORM představuješ je defakto schopnost programovat, a ta jestli je principiálně vůbec možná (asi jo), tak je úplně někde jinde, než co dneska umíme.
Jak píše Pavel: i SQL databáze, která řeší jednoduché a matematicky snadno popsatelné problémy relační algebry, řeší u každého přístupu jen pár vhodných strategií - a i tam občas selhává. A ty bys chtěl vlastně po ORM něco, co by umělo ne volit jednu strategii z pár "napevno zadrátovaných", ale které by umělo algoritmizaci. Jasně - teroreticky to asi možný je. Ale až to budeme umět, tak budeme umět konstruovat androidy - a programátoři přijdou o práci.... :-)
To je tak vágně položený příspěvek, že na něj nejsem schopen šikovně reagovat. Obecně v něm tuším názorový vzor, stejně jako u @Miroslav Šilhavý, že ORM nemůže (z principu) něco vidět, co vývojář může. S tím kategoricky nesouhlasím. Jistě, jsou určité okrajové oblasti které může vědět pouze vývojář - například, že nějaká tabulka se nemá z iracionálních důvodů optimalizovat. Ale to jsou okrajové případy řešitelné natvrdo hintem. Cokoliv dokáže vývojář vyčíst z databáze, dokáže ORM vyčíst taky a to lépe.


Re:Rada při návrhu db tabulek
« Odpověď #196 kdy: 07. 07. 2021, 06:50:09 »
To je tak vágně položený příspěvek, že na něj nejsem schopen šikovně reagovat. Obecně v něm tuším názorový vzor, stejně jako u @Miroslav Šilhavý, že ORM nemůže (z principu) něco vidět, co vývojář může. S tím kategoricky nesouhlasím. Jistě, jsou určité okrajové oblasti které může vědět pouze vývojář - například, že nějaká tabulka se nemá z iracionálních důvodů optimalizovat. Ale to jsou okrajové případy řešitelné natvrdo hintem. Cokoliv dokáže vývojář vyčíst z databáze, dokáže ORM vyčíst taky a to lépe.

V databázi (ve schématu) nemáte žádné informace o procesech - o tom, jak se data mění, v jakých proporcích, jak a kde dochází k zámkům, atd atd. Schéma je statická záležitost - minimálně v tuto chvíli neumí popsat dynamiku dat a dynamické (chronologické) závislosti. Schéma například neobsahuje žádnou informaci o frekvenci update, kterou já jako vývojář beru v potaz už při návrhu schématu. Jelikož sleduji vývoj zpracování statistik (práce Tomáše Vondry), tak vím, jak je náročné vysledovat něco, co není explicitně zadáno v datech databáze (například závislosti mezi sloupci, korelace mezi tabulkami). Ne, že by to nebylo technicky realizovatelné - ale ta úloha je náročná - příliš dat, příliš kombinací. Takže větu "Cokoliv dokáže vývojář vyčíst z databáze, dokáže ORM vyčíst taky a to lépe." považuji za úplně odtrženou od reality. Databáze je model, popisuje zjednodušenou realitu, a tudíž nemůže principiálně obsahovat vše, a je potřeba brát v potaz výpočetní náročnost optimalizačních úloh.

Re:Rada při návrhu db tabulek
« Odpověď #197 kdy: 07. 07. 2021, 06:56:33 »
ORM ma vic informaci nez schema, ma treba vic moznosti jak preddefinovat ruzne implicitni joiny.

Re:Rada při návrhu db tabulek
« Odpověď #198 kdy: 07. 07. 2021, 07:43:09 »
ORM ma vic informaci nez schema, ma treba vic moznosti jak preddefinovat ruzne implicitni joiny.

???

Re:Rada při návrhu db tabulek
« Odpověď #199 kdy: 07. 07. 2021, 08:14:37 »
ORM ma vic informaci nez schema, ma treba vic moznosti jak preddefinovat ruzne implicitni joiny.

???

treba casto k nejake tabulce joinujete jinou tabulku s nejakou netrivialni podminkou, nad hodnotami z te jine tabulky provadite nejake netrivialni mapovani

takovych operaci je vic a chcete je ruzne kombinovat

muzete vytvorit pro kazdy pripad zvlastni pohled, nebo nechat ORM ty dotazy generovat


Re:Rada při návrhu db tabulek
« Odpověď #200 kdy: 07. 07. 2021, 08:46:08 »
ORM ma vic informaci nez schema, ma treba vic moznosti jak preddefinovat ruzne implicitni joiny.

???

treba casto k nejake tabulce joinujete jinou tabulku s nejakou netrivialni podminkou, nad hodnotami z te jine tabulky provadite nejake netrivialni mapovani

takovych operaci je vic a chcete je ruzne kombinovat

muzete vytvorit pro kazdy pripad zvlastni pohled, nebo nechat ORM ty dotazy generovat

Jasně, ale a) je to statická věc - nepodchytíte tím žádnou dynamiku, b) není to nic, co by ORM získalo samo, musí to programátor explicitně napsat - a je funkčně jedno jestli to programátor udělá ručně SQL nebo přes definici v aplikaci, a pak to SQL vygeneruje query builder.  ORM nikdy nemůže získat žádnou znalost samo. A minimálně v tuto chvíli neexistuje samoučící se (adaptabilní) ORM systém - všechno to jsou statické systémy.

Je velký rozdíl jestli píšete aplikaci vůči velké databázi s netriviální zátěží nebo s malou databází s malou zátěží. U velké databáze by měl komplexní SQL dotaz programátora "bolet". Chtěnou vlastností různých ORM systémů je maskování komplexity dotazů - jenomže to způsobuje dva problémy - umožňuje dlouhodobě pracovat s špatně navržený datovým modelem, aniž by se programátor pozvracel - ale špatně navržený datový model nutně vede k pomalým dotazům a slabému výkonu - a v pozdější době, kdy už programátor musí psát některé dotazy ručně, tak zvrací každý den, nebo striktně odmítne jakýkoliv zásah - a pak tam máte dotazy, které ručně trvají 20ms, a generované 20000ms - a pokud takových dotazů máte víc, tak hezky tavíte CPU.

Re:Rada při návrhu db tabulek
« Odpověď #201 kdy: 07. 07. 2021, 08:50:22 »

treba casto k nejake tabulce joinujete jinou tabulku s nejakou netrivialni podminkou, nad hodnotami z te jine tabulky provadite nejake netrivialni mapovani

takovych operaci je vic a chcete je ruzne kombinovat

muzete vytvorit pro kazdy pripad zvlastni pohled, nebo nechat ORM ty dotazy generovat

Jinak v SQL mám pro tento účel pohledy (kdybych chtěl udělat tyto vazby perzistentní) anebo CTE pro semi pohledy.

Ale je to jedno, jestli pohledy si vytváříte aplikačně nebo databázově. Dneska i 8 řada MySQL už umí nematerializované pohledy, takže není důvod obcházet databázi.

Re:Rada při návrhu db tabulek
« Odpověď #202 kdy: 07. 07. 2021, 10:38:18 »
Ale pracuje s tím i programátor,
Nepracuje. Proč by programátor měl vědět víc než ORM? Neví.
Zkus prosím toto zohlednit, a možná se posuneme dále.

Já myslím, že jsme u jádra pudla.
Zkusíme to na malých a extrémních příkladech.

Zkuste mi prosím popsat, jak by ORM mohlo vědět např. kdy se vyplatí z DB vytáhnout více dat hromadně dopředu, když v daný okamžik má požadavek třeba jen na jeden záznam - přičemž programátor s určitou přesností ví, že bude potřebovat vybranou sadu záznamů? ORM se může rozhodnout mezi dvěma extrémy - vzít a doručit jednu položku (a pokud to bude ve smyčcce, tak vygeneruje spoustu dotazů), nebo natáhnout do aplikace všechny (třeba i spoustu zbytečných). ORM není schopno rozhodnout "nic mezi", zatímco programátor s určitým úspěchem ano.

Nebo, někdy se vyplatí k záznamům rovnou dotáhnout (joinem) navázané informace. Aplikace je může potřebovat až někdy později za běhu, ale ví se, že je potřebovat bude (v některých případech). ORM se zase může leda rozhodnout, že je dotáhne ad hoc po jednom (spousta dotazů ve smyčce), ad hoc hromadně (pak join provádí aplikace svojí logikou), nebo dopředu (tj. bude je tahat i v případech, kdy nebudou potřeba). Opět, toto může ovlivnit jedině programátor tím, že to tomu ORM dá nějak na vědomí.

To jsou dva úplně triviální příklady, kdy se ORM nemůže rozhodnout za programátora. Ano, programátor může ORM nahintovat, aby se zachovalo tak, jak si představuje. Tím se ale ztrácí kus univerzálnosti ORM řešení, a navíc ten programátor stejně musí znát, co je v pozadí. Bez toho nemůže vědět, jak hintovat.

Já mluvil o milisekundách spálených na mapování výsledku dotazu na objektovou reprezentaci. V žádném případě na tom, že by ORM mělo posílat horší dotazy než by napsal vývojář.

Zbytek je opět sklouznutí ke steskům nad nekvalitou ORM.

Ta ztráta času je především v tom, že potřebujete snížit počet dotazů i za cenu komplikovaného dotazu. Potřebujete to snížit, abyste omezil obvykle neefektivní aplikační logiku a nekumuloval dotazové latence. Jak jsem psal výše, to rozhodnutí nejde udělat v rámci automatiky ORM.

Re:Rada při návrhu db tabulek
« Odpověď #203 kdy: 07. 07. 2021, 13:12:20 »
Až bude nějaké ORM + AI natolik dobré, že si tohle postupně při běhu aplikace odvodí samo a dooptimalizuje k ideálnímu stavu, tak takové AI rovnou může tvořit celé aplikace - zákazník mu jen předhodí své požadavky co od aplikace chce.  ;D
A teď z růžového obláčku zatím zpátky na zem.

BoneFlute

  • *****
  • 1 733
    • Zobrazit profil
Re:Rada při návrhu db tabulek
« Odpověď #204 kdy: 07. 07. 2021, 14:08:33 »
Ale pracuje s tím i programátor,
Nepracuje. Proč by programátor měl vědět víc než ORM? Neví.
Zkus prosím toto zohlednit, a možná se posuneme dále.

Já myslím, že jsme u jádra pudla.
Zkusíme to na malých a extrémních příkladech.

Zkuste mi prosím popsat, jak by ORM mohlo vědět např. kdy se vyplatí z DB vytáhnout více dat hromadně dopředu, když v daný okamžik má požadavek třeba jen na jeden záznam - přičemž programátor s určitou přesností ví, že bude potřebovat vybranou sadu záznamů? ORM se může rozhodnout mezi dvěma extrémy - vzít a doručit jednu položku (a pokud to bude ve smyčcce, tak vygeneruje spoustu dotazů), nebo natáhnout do aplikace všechny (třeba i spoustu zbytečných). ORM není schopno rozhodnout "nic mezi", zatímco programátor s určitým úspěchem ano.

Nebo, někdy se vyplatí k záznamům rovnou dotáhnout (joinem) navázané informace. Aplikace je může potřebovat až někdy později za běhu, ale ví se, že je potřebovat bude (v některých případech). ORM se zase může leda rozhodnout, že je dotáhne ad hoc po jednom (spousta dotazů ve smyčce), ad hoc hromadně (pak join provádí aplikace svojí logikou), nebo dopředu (tj. bude je tahat i v případech, kdy nebudou potřeba). Opět, toto může ovlivnit jedině programátor tím, že to tomu ORM dá nějak na vědomí.
Oblíbená strategie, která se už běžně používá, a tedy není to žádné scifi je, že se provede první kolo, kde se použijou úplně naivní a neefektivní dotazy, a na základě toho se odvodí, jak má vypadat optimální.

Máš tam něco těžšího? :-)

Opravdu, ta představa, že programátor ví víc, než je schopen zjistit stroj je mylná (čest výjimkám).
Normální programátor jde, a koukne se do databáze. To ORM může udělat taky. Normální programátor jde, a vytvoří nějaký požadavek na data. To ví ORM taky.
Co by ORM nemohla vědět?

To jsou dva úplně triviální příklady, kdy se ORM nemůže rozhodnout za programátora. Ano, programátor může ORM nahintovat, aby se zachovalo tak, jak si představuje. Tím se ale ztrácí kus univerzálnosti ORM řešení, a navíc ten programátor stejně musí znát, co je v pozadí. Bez toho nemůže vědět, jak hintovat.
Toto jsem měl za to, že už jsme si vyříkali, a že jsem se vyjadřoval dostatečně expresivně: motivací ORM, určitě ne primární, není schovat DB. Já jsem pro hinty, a jsem pro to, aby mi ORM ukazovalo, jaké SQL vytváří, a mít možnost to ovlivnit. OK? Můžeme se k tomu už nevracet prosím?



To je tak vágně položený příspěvek, že na něj nejsem schopen šikovně reagovat. Obecně v něm tuším názorový vzor, stejně jako u @Miroslav Šilhavý, že ORM nemůže (z principu) něco vidět, co vývojář může. S tím kategoricky nesouhlasím. Jistě, jsou určité okrajové oblasti které může vědět pouze vývojář - například, že nějaká tabulka se nemá z iracionálních důvodů optimalizovat. Ale to jsou okrajové případy řešitelné natvrdo hintem. Cokoliv dokáže vývojář vyčíst z databáze, dokáže ORM vyčíst taky a to lépe.

V databázi (ve schématu) nemáte žádné informace o procesech - o tom, jak se data mění, v jakých proporcích, jak a kde dochází k zámkům, atd atd. Schéma je statická záležitost - minimálně v tuto chvíli neumí popsat dynamiku dat a dynamické (chronologické) závislosti. Schéma například neobsahuje žádnou informaci o frekvenci update, kterou já jako vývojář beru v potaz už při návrhu schématu. Jelikož sleduji vývoj zpracování statistik (práce Tomáše Vondry), tak vím, jak je náročné vysledovat něco, co není explicitně zadáno v datech databáze (například závislosti mezi sloupci, korelace mezi tabulkami). Ne, že by to nebylo technicky realizovatelné - ale ta úloha je náročná - příliš dat, příliš kombinací. Takže větu "Cokoliv dokáže vývojář vyčíst z databáze, dokáže ORM vyčíst taky a to lépe." považuji za úplně odtrženou od reality. Databáze je model, popisuje zjednodušenou realitu, a tudíž nemůže principiálně obsahovat vše, a je potřeba brát v potaz výpočetní náročnost optimalizačních úloh.
To máš samozřejmě pravdu. A to nikdo nerozporuje. A tudíž v tom nevidím ten principielní problém, který by ORM nějak zvláště hendikepovalo.


Takže větu "Cokoliv dokáže vývojář vyčíst z databáze, dokáže ORM vyčíst taky a to lépe." považuji za úplně odtrženou od reality. Databáze je model, popisuje zjednodušenou realitu, a tudíž nemůže principiálně obsahovat vše, a je potřeba brát v potaz výpočetní náročnost optimalizačních úloh.
Toto vypadá na jedno ze zásadních nepochopení. Mé tvrzení, že ORM dokáže vyčíst to samé co vývojář nijak nesouvisí se skutečností, že Databáze je model, který popisuje zjednodušenou realitu. (Nehledě na to, že i tam je spoustu "ale".)

Re:Rada při návrhu db tabulek
« Odpověď #205 kdy: 07. 07. 2021, 14:29:32 »
Prostě ORM je primárně o mapování objektů na relace, nikoli o dotazování se. To je sekundární úkol a můžu k tomu v rámci ORM použít i SQL. Tím považuju de fakto debatu za vyřešenou  :D