Rada při návrhu db tabulek

[Google CTCCTCGGCGGGCACGTAG]

V 1 mohu mít taky dost logiky v DB a používat custom SQL dotazy,

To jde a zpravidla se to tak dělá. Ale to má své velké problémy. Co když chci udělat jako "custom SQL dotaz" update dané vlastnosti, která ovšem je "ztrigerovaná" nikoli v DB, ale v APP? Nebo co když chci jen udělat custom select podle dané vlastnosti, ale ta je ve skutečnosti na APP vrstvě nějak předefinována?

V případě malého projektu, kde se lidé "osobně domluví co bude kde", tak to jde nějak udržet. Ale s  růstem projektu se je podle mne třeba dohodnout, na které úrovni funguje bussines logika - jestli na APP nebo na DB vrstvě, a respektovat to. Lezení pod tuto dohodnutou úroveň je pak "ugly hack". Tzn. jakmile mám nějakou část logiky v APP, tak bych neměl jen tak "mírnix týrnix" lézt bokem do databáze.

Ne, že by takovou app (kde se bokem leze) nešlo "ukočírovat" - jde to, a asi nemálo lidí to tak dělá. Ale s příbývající komplexitou se pak člověk nevyhne dublování funkcionality na APP a na DB vrstvě - a i s tím spojenými chybami, když se ty implementace "rozjedou" (anebo prostě nejsou napsány 100% shodně).

uvedte priklad updatu, ktery nejde delat pomoci ORM.

[Reklama]

[Logik]

A.P.Hacker:Asi si nerozumíme. Samozřejmě, pokud uděláš ORM turingovsky úplný, tak s ním vyjádříš jakékoli SQL. Ale - omlouvám se, že se opakuju - kde máš bussines logiku?

• Pokud v databázi, tak to není ORM. ORM je object relation mapping. Pokud máš bussines logiku v DB, tak máš objekty v databázi. To, na co je mapuješ vlastně nejsou "objekty", nemají na APP rovině logiku a objekt tvoří data+logika. V takovém případě podle mne opravdu nejde o ORM, ale o QueryBuilder. Který je samozřejmě užitečný a potřeba.
• Pokud v APP, tak máš problém s jakýmikoli hromadnými operacemi. Např. primitivní nastavení vlastnosti: když uděláš "UPDATE cars SET color = 'green'", ale v APP logice budeš mít u některých aut zákaz je nazelenit, tak to rozbiješ, protože tu APP logiku rozbiješ.

Situaci, kdy se používá mix přístupů výše jsem už komentoval.

[SB]

- ORM není o tom, nedostat se nebo schovat SQL. Když už něco schovávat, tak to je relační algebra. Ale SQL nikomu nevadí.

To je protimluv. SQL přímo realizuje relační algebru.

Zkuste se zamyslet nad zkratkou ORM, obsahuje přímočarou odpověď.

[Google CTCCTCGGCGGGCACGTAG]

A.P.Hacker:Asi si nerozumíme. Samozřejmě, pokud uděláš ORM turingovsky úplný, tak s ním vyjádříš jakékoli SQL. Ale - omlouvám se, že se opakuju - kde máš bussines logiku?

• Pokud v databázi, tak to není ORM. ORM je object relation mapping. Pokud máš bussines logiku v DB, tak máš objekty v databázi. To, na co je mapuješ vlastně nejsou "objekty", nemají na APP rovině logiku a objekt tvoří data+logika. V takovém případě podle mne opravdu nejde o ORM, ale o QueryBuilder. Který je samozřejmě užitečný a potřeba.

vzdy bude cast logiky v aplikaci a jina cast v databazi, nikdy nebude vse v databazi, neznamena to, ze se neco duplikuje.

   

• Pokud v APP, tak máš problém s jakýmikoli hromadnými operacemi. Např. primitivní nastavení vlastnosti: když uděláš "UPDATE cars SET color = 'green'", ale v APP logice budeš mít u některých aut zákaz je nazelenit, tak to rozbiješ, protože tu APP logiku rozbiješ.

Situaci, kdy se používá mix přístupů výše jsem už komentoval.

jeste jednou, ORM je (mimo jine) lepsi QueryBuilder, ktery vyuziva informace z definice modelu

   

• Pokud v APP, tak máš problém s jakýmikoli hromadnými operacemi. Např. primitivní nastavení vlastnosti: když uděláš "UPDATE cars SET color = 'green'", ale v APP logice budeš mít u některých aut zákaz je nazelenit, tak to rozbiješ, protože tu APP logiku rozbiješ.

Situaci, kdy se používá mix přístupů výše jsem už komentoval.

proc bych psal SQL update rucne? Jeste jednou, kazde ORM umi vygenerovat validni batch update dotaz.
[/list]

[Google CTCCTCGGCGGGCACGTAG]

To, na co je mapuješ vlastně nejsou "objekty", nemají na APP rovině logiku a objekt tvoří data+logika. V takovém případě podle mne opravdu nejde o ORM, ale o QueryBuilder. Který je samozřejmě užitečný a potřeba.[/li][/list]

na APP rovine (v definici tridy, kdyz chcete) je definovana logika (ruzna integritni omezeni, trigery a podobne), ktera je nasledne synchonizovana s databazi. Potom objekty pouzivate stejne jako by logika byla v aplikaci. Jina cast logiky je ciste v aplkikaci.

V praxi neexistuji cista oddeleni na vrstvy a skatulky, to jen v korporatni mluve

[Reklama]

[Miroslav Šilhavý]

   

• Pokud v APP, tak máš problém s jakýmikoli hromadnými operacemi. Např. primitivní nastavení vlastnosti: když uděláš "UPDATE cars SET color = 'green'", ale v APP logice budeš mít u některých aut zákaz je nazelenit, tak to rozbiješ, protože tu APP logiku rozbiješ.

Situaci, kdy se používá mix přístupů výše jsem už komentoval.

proc bych psal SQL update rucne? Jeste jednou, kazde ORM umi vygenerovat validni batch update dotaz.

Tohle je z principu nemožné.
Pokud bude "zákaz zazelenit" vyhodnocený aplikační logikou, pak ORM nedokáže sestavit žádný efektivní update dotaz do databáze. V nejlepším případě bude posílat list IDček k updatování, nebo něco podobného.

[Tomas-T]

Tohle je z principu nemožné.
Pokud bude "zákaz zazelenit" vyhodnocený aplikační logikou, pak ORM nedokáže sestavit žádný efektivní update dotaz do databáze. V nejlepším případě bude posílat list IDček k updatování, nebo něco podobného.

Pokud ta "aplikační logika" bude vycházet přímo z vlastností objektů (když má auto výkon > 100kW a jen dvoje dveře, nemůže být obarvené na zeleno, ostatní můžou), které jsou mapovány do databáze, tak by to ORM zvládnout mohl. Ale už i ten zápis se bude asi přibližovat relačnímu SQL jazyku.
Ale já jsem stará konzerva, nejsem příznivec ORM, takže to zkoumat nebudu.

[Miroslav Šilhavý]

Tohle je z principu nemožné.
Pokud bude "zákaz zazelenit" vyhodnocený aplikační logikou, pak ORM nedokáže sestavit žádný efektivní update dotaz do databáze. V nejlepším případě bude posílat list IDček k updatování, nebo něco podobného.

Pokud ta "aplikační logika" bude vycházet přímo z vlastností objektů (když má auto výkon > 100kW a jen dvoje dveře, nemůže být obarvené na zeleno, ostatní můžou), které jsou mapovány do databáze, tak by to ORM zvládnout mohl. Ale už i ten zápis se bude asi přibližovat relačnímu SQL jazyku.

Přesně to mám na mysli. Definice takových mapovaných objektů, nebo zápis požadavku bude sice jinou mluvou, ale nevyhne se složitosti zápisu v SQL.

Ale můžeme to rozvést dál: pokud to bude vycházet z databáze, ale jaksi "na volno" - nebude to vyjádřené vazbami, pohledy, constraints, triggery, opatřené žádoucími indexy, ..., ale třeba jen definované zápisem nějaké konfigurace => pak to taky v obecném případě nedosáhne výkonu, který RDBMS může poskytnout, a ani to nebude mít potenciál optimalizovatelnosti to ke stejnému výkonu. Pokud by to bylo v DB definované přesně, a na pevno, pak ORM neusnadní práci při tvoření struktury a práci s daty, pouze poskytne vhodnější interface bližší k jazyku aplikace.

[BoneFlute]

- ORM není o tom, nedostat se nebo schovat SQL. Když už něco schovávat, tak to je relační algebra. Ale SQL nikomu nevadí.

To je protimluv. SQL přímo realizuje relační algebru.

Zkuste se zamyslet nad zkratkou ORM, obsahuje přímočarou odpověď.

Není to protimluv.
První věc, kterou šikovné ORM schová, tak je joinování. Každopádně pointa je jinde.

[Logik]

vzdy bude cast logiky v aplikaci a jina cast v databazi, nikdy nebude vse v databazi, neznamena to, ze se neco duplikuje.

Neduplikuje se do té doby, než zjistíš, že v nějakých SQL dotazech potřebuješ použít tu logiku, jejíž část je v APP. Protože ji tam prostě nemáš. V takovém případě prostě buďto tu logiku obcházíš (což je budoucí průšvih), nebo ji duplikuješ (což je opět budoucí průšvih).

Třetí - správná cesta - je přesun té logiky do DB, ale to může být netriviální refaktor a klient Tě umlátí, že chceš za z jeho pohledu primitivní úpravu aplikace nehoráznou sumu. Takže to tak neuděláš a volíš jedno z řešení výše... To není teorie, to je praxe...
Nejhorší na tom ale je, že ve větším projektu nevíš jaká logika je v APP a jaká v DB. Takže když chceš pracovat na DB vrstvě, tak prostě nevíš, jestli náhodou neobcházíš nějakou logiku na APP vrstvě. V lepším případě to jsi schopen ověřit kontrolou zdrojových kódů APP popř. projitím dokumentace a stojí Tě to jen nemálo času. V horším případě je dokumentace nekompletní (kdo máte v projektech dokumentaci 100%?) anebo danej kus kódu s danou logikou nenajdeš/špatně pochopíš a vyrobils problém.

proc bych psal SQL update rucne? Jeste jednou, kazde ORM umi vygenerovat validni batch update dotaz.

Jak píšou kolegové, pokud máš logiku v APP, tak to prostě není možné, protože na APP vrstvě je aplikační logika postavená nad ORM a tedy ji ORM nevidí a neumí použít.
Leda, že bys psal APP logiku ve vrstvě pod ORM jako nějakou konfiguraci ORM - jenže v čem? Nějaký "user-friendly" deklarativní způsob nebude ani vzdáleně turingovsky úplný, a tedy v něm většinu APP bussines logiky prostě nenapíšeš. A jakýkoli složitější jazyk? Pak je otázka, proč vymešlet kolo: pokud to bude komplexní, tak to nebude o tolik jednodušší než SQL, aby to ospravedlnilo veškeré nevýhody z toho plynoucí (další jazyk v projektu, problémy vzniklé mapováním toho jazyka na SQL atd... atd....).

Jako teoreticky si dokážu představit ORM, které by bylo např. v Pythonu, a kde by definice objektů byla napsaná tak, že by se z ní automaticky vytvářely PL/Python stored procedury, ale takový ORM imho neexistuje a napsat něco takovýho by byla hodně netriviální věc.
Navíc, takový přístup by vlastně nebyl nic jiného, než dublování funkcionality, o kterém píšu více, jen díky "strojovému generování" s menším rizikem desynchronizace implementací.

[BoneFlute]

proc bych psal SQL update rucne? Jeste jednou, kazde ORM umi vygenerovat validni batch update dotaz.

Jak píšou kolegové, pokud máš logiku v APP, tak to prostě není možné, protože na APP vrstvě je aplikační logika postavená nad ORM a tedy ji ORM nevidí a neumí použít.

Já bych pro dávkové příkazy ORM neobcházel. To ORM tam jednou mám, a tak to píšu přes něj. Pod kapotu jdu v případě, kdy potřebuju optimalizovat na krev, ne v případě kdy potřebuju "něco spustit".

[Miroslav Šilhavý]

Já bych pro dávkové příkazy ORM neobcházel. To ORM tam jednou mám, a tak to píšu přes něj. Pod kapotu jdu v případě, kdy potřebuju optimalizovat na krev, ne v případě kdy potřebuju "něco spustit".

To moc dobře nefunguje. Databáze je zatížená spoustou neefektivních dotazů, a ve chvíli, kdy potřebujete jeden ladit "na krev", tak se nikam nehnete. Zjistíte, že i ten jeden, jinak třeba dobře napsaný dotaz prostě čeká kvůli ostatním neefektivním transakcím a lockům z ORM.

Celkově je hloupé mít dobrou technologii, zmrzačit ji, a pak se snažit zrmzačený pahýl znovu rozhýbat.

Psal jsem to už výše, ORM má svoje místo, ale problém nastává ve chvíli, kdy někoho napadne, že by si mohl pomoct obejitím. Získá tím málo, ale hodně zkomplikuje situaci. Když ORM, tak kompletně, přijmout jeho výhody a nevýhody. Data pak jedině přes aplikaci, nikdy už ne přímo z DB.

[BoneFlute]

Já bych pro dávkové příkazy ORM neobcházel. To ORM tam jednou mám, a tak to píšu přes něj. Pod kapotu jdu v případě, kdy potřebuju optimalizovat na krev, ne v případě kdy potřebuju "něco spustit".

To moc dobře nefunguje. Databáze je zatížená spoustou neefektivních dotazů, a ve chvíli, kdy potřebujete jeden ladit "na krev", tak se nikam nehnete. Zjistíte, že i ten jeden, jinak třeba dobře napsaný dotaz prostě čeká kvůli ostatním neefektivním transakcím a lockům z ORM.

Celkově je hloupé mít dobrou technologii, zmrzačit ji, a pak se snažit zrmzačený pahýl znovu rozhýbat.

Psal jsem to už výše, ORM má svoje místo, ale problém nastává ve chvíli, kdy někoho napadne, že by si mohl pomoct obejitím. Získá tím málo, ale hodně zkomplikuje situaci. Když ORM, tak kompletně, přijmout jeho výhody a nevýhody. Data pak jedině přes aplikaci, nikdy už ne přímo z DB.

Nerozumím. Odporuješ si. Já tvrdím, že bych dávkové příkazy honil přes ORM, a ty namítneš, že "Když ORM, tak kompletně, přijmout jeho výhody a nevýhody. Data pak jedině přes aplikaci, nikdy už ne přímo z DB."?

[Miroslav Šilhavý]

Nerozumím. Odporuješ si. Já tvrdím, že bych dávkové příkazy honil přes ORM, a ty namítneš, že "Když ORM, tak kompletně, přijmout jeho výhody a nevýhody. Data pak jedině přes aplikaci, nikdy už ne přímo z DB."?

Reagoval jsem na druhou větu: >>Pod kapotu jdu v případě, kdy potřebuju optimalizovat na krev, ne v případě kdy potřebuju "něco spustit".<<

[BoneFlute]

Nerozumím. Odporuješ si. Já tvrdím, že bych dávkové příkazy honil přes ORM, a ty namítneš, že "Když ORM, tak kompletně, přijmout jeho výhody a nevýhody. Data pak jedině přes aplikaci, nikdy už ne přímo z DB."?

Reagoval jsem na druhou větu: >>Pod kapotu jdu v případě, kdy potřebuju optimalizovat na krev, ne v případě kdy potřebuju "něco spustit".<<

OK.

V tom případě, v tom já nevidím problém. Jdu pod kapotu ORM (nikoliv napřímo do db). Mnoho z nich (ORM) obsahuje různé nástroje jak optimalizovat různé věci. Je to stále v režii ORM, neobcházím validaci (nebo to činím při plném vědomí), a nevidím v tom žádný problém. Nepovažuji to za mrzačení.

Samozřejmě v tomto případě ale nemohu pouštět write dotazy napřímo do databáze, protože pak dotyčené ORM obcházím; on je source of truth.