ORM vs SQL rubrika: Programování: Java

3 jan.flos
položil/-a 26.11.2014

SQL Je etablovaný doménový jazyk. Neustále se vyvíjí a ORM Frameworky nestíhají zatím držet krok. Důvodům proč bylo ORM vymyšleno a proč se používá celkem rozumím. Nicméně v mém současném projektu mám takový pocit, že je to spíše přítěž a že přináší víc problémů než benefitů.
Má někdo podobnou zkušenost ? Především někdo používající Active Record Desgin Pattern ?
Jak by tedy vypadal svět bez ORM?

  1. Kde by byla uložena doménová logika ?
  2. Jak by vypadala datová vrstva ?
  3. Přeci jen je třeba řešit CRUD operace jak?
  4. V mnoha případech je třeba řešit transformaci řádku rekordsetu na nějaký objekt. Jak?

Komentáře

  • Tharos : @jan.flos: Četl jsi ten jeho článek? Nebo jenom titulek? ;) — 4.12.2014
odkaz
7 onelook
odpověděl/-a 26.11.2014

Ano, mám podobnou zkušenost. S ORM:
1) Typicky degraduješ DB na tupé úložiště dat. To může být někdy výhoda, ale často nevýhoda.

2) Máš malou kontrolu nad tím, co leze skutečně do DB. Když píšeš explicitně dotaz, tak víš, jaké dotazy bude DB zpracovávat. Když v DB uvidíš nějaké pomalé a neefektivní dotazy, snadno je můžeš ve zdrojáku najít a něco s tím udělat. U ORM jsi závislý na hrabání se v logách. A když chceš optimalizovat dotaz, tak napřed musíš vymyslet dotaz v SQL a pak uvažovat, jak asi ORM pracuje, a zkusit jej přepsat do jazyka ORM.

3) ORM má malou vyjadřovací schopnost. Zaprvé ORM typicky pracuje na principu "přečti data" -> "zapiš novou verzi". Tedy něco jako UPDATE ... SET i = i + 1 jde proti principům ORM (i když to tam většinou jde nějak udělat). Navíc se pak pracuje s jednotlivými záznamy a hromadné operace jsou velmi neefektivní a pomalé (resp. zase to lze typicky obejít, ale jde to proti ORM).

ORM prostě mají nějaké výhody a nějaké nevýhody. U aplikace, která masivně zatěžuje DB a je třeba hodně optimalizovat, bych do ORM nešel. Naopak u aplikace, kde je složitá aplikační logika, ale zátěž DB minimální, mi ORM dává dobrý smysl. Ale samozřejmě to nelze říct takto obecně, záleží na konkrétním případu.

Komentáře

  • programator.net_1 : Mam DB ako tupe ulozisko dat. Aplikacana logika je v aplikacii. Momentalne mam aplikaciu kde nie je ziaden ORM maper, ale priamo selecty nad tabulkami a vyuziva sa datareadery. Nad jednou tabulkou mam niekolko selectov ktore sa lisia napr v podmienke, group by, sumamy, joinovanymi tabulkami a teraz som pridal stlpec do tabulky. Momentalne musim prechadzat vsetky selecty, v ktorych sa odkazuje na danu tabulku a upravit ich. Tak isto potrebujem upravit CRUD operacie. Ako toto riesit bez ORM. Ked som mal ORM, pridal som stlpec do tabulky, dal pregenerovat ORM a mal som ten stlpec kde som ho potreboval — 28.11.2014
  • Kit : @programator.net_1: Je nutné mít ty SQL dotazy seskupené do domén. Oprava v jedné doméně je pak mnohem jednodušší. — 28.11.2014
  • programator.net_1 : Momentalne to urobene tak, ze mam ku kazdej tabulke vytvorenu triedu a v nej jednotlive funkcie ktore mi priamo pracuju nad danou tabulkou. Vykonvaju selecty a robia CRUD operacie. Len cela ta udrzba toho systemu sa mi zda taka pomala a pracna. Furt si hovorim, ze niekde musim robit chybu aby som musel mat 10, 15 selectov nad jednou tabulkov a potom ich pracne udrziavat. Musi to ist aj inac :-) . — 28.11.2014
  • Kit : @programator.net_1: Kolik má ta tvoje tabulka sloupců? Pokud je to číslo dvouciferné, měl by ses zamyslet nad strukturou databáze. — 28.11.2014
  • Michal Zahradníček : Ja som ORMu nikdy na chuť neprišiel. Mám rád, keď viem, čo sa kde deje a keď sú veci optimalizované. Čo sa týka selectov, ktoré sa sú na rovnakú tabuľku s inými parametrami, tak to riešim tak že v Modely mám metódu napr. getList($params=array()). Potom zavolám napr: $model->getList([ 'category_id'=>4, 'search'=>'klobasa', 'limit'=>5, 'group'=>'section_id' ]); Podľa parametrov potom funkcia vygeneruje query, ktoré je optimalizované(môže obsahovať rôzne JOINy a pod) a pošle na DB... V prípade záujmu, možem postnúť ako to vyzerá vo vnútri funkcie... — 28.11.2014
  • Jirka Chmiel : @Kit: Proč je dvouciferný počet sloupců v tabulce špatně? — 30.11.2014
  • Kit : @BbyjbMF4LH: Napsal jsem "měl by ses zamyslet". Ne předělat. Víc než 30 sloupců je už podle mne příznakem chybného návrhu, který by se předělat měl. — 30.11.2014
  • programator.net_1 : Kit > prezrad mi, ktora normalova forma mi hovori, ze viacej ako 30 stlpcov v tabulke je chybny navrh. prezrad mi popripade, ako by si zamyslel nad touto tabulkou co ma 13 stlpcov. Podla teba to uz zavana chybnym navrhom tabulky. V tabulke sa eviduju informacie o fakturacnych dokladoch. [id] LONG NOT NULL PRIMARY KEY [typ_dokladu] VARCHAR(10) [cislo_dokladu] VARCHAR(20) [variabilny_symbol] VARCHAR(20) [datum_evidencie] DATETIME [datum_dodania] DATETIME [datum_splatnosti] DATETIME [popis] VARCHAR(50) [ciastka] DOUBLE [nedoplatok] DOUBLE [dni_po_splatnosti] LONG [vynimka] LONG NOT NULL [idzakaznika] LONG NOT NULL — 2.12.2014
  • diverman : programator.net_1: muzes zustat v klidu, zadna takova normalni forma neni. Je to jako tvrdit, funkce delsi nez 100 radku je spatna. — 2.12.2014
  • Kit : programator.net_1: Například z polí [ciastka] [nedoplatok] [dni_po_splatnosti] by tam nemělo být ani jedno - mají být v další tabulce. Nijak totiž neřešíš, když ti to někdo zaplatí třeba ve třech splátkách. [datum_dodania] také patří spíš k dodacímu listu. [cislo_dokladu] by mělo být v tabulce, ve které je [ciastka]. Zřejmě jsi v rámci zjednodušení udělal denormalizaci. Nic proti, chtěl jsi jen vědět, jak bych se nad tím zamyslel. — 2.12.2014
  • Kit : diverman: Funkce (metoda) delší než 20 řádek je také k zamyšlení, zda není moc dlouhá, 50 řádek už je příliš. — 2.12.2014
  • Honza Břešťan : @Kit: To IMHO zalezi jenom na tom, jak chci ten proces modelovat. Pokud me splatky nezajimaji, nemusim platbu presouvat do separatni tabulky, pokud neporusuje NF a "neprekazi" mi. Dodaci list to same, vubec nemusi byt soucasti modelu, tak proc ho oddelovat, pokud to logika a struktura dat nevyzaduji. Obecne u vazeb 1:1 jenom zalezi, jak moc chci mit granularni ten model. Muze me klidne zajimat kazda polozka formulare dodaciho listu, nebo me taky muze zajimat jenom to, ze to nekdy bylo dodane. — 2.12.2014
  • skliblatik : @Kit: nachytal ses - přece nejde ze struktury tabulky poznat, co je špatně, když nemám informace o aplikaci. Nejsou správné a špatné modely, jen vhodnější a méně vhodný pro daný účel. — 2.12.2014
  • Kit : @Jan Břešťan: Souhlasím. Pokud by to bylo součástí účetnictví, řešil bych to tím svým způsobem. Pokud je to však jen evidenční záležitost, může původní řešení plně vyhovovat. — 2.12.2014
  • Kit : @skliblatik: Nenachytal. Otázka zněla "ako by si zamyslel nad touto tabulkou co ma 13 stlpcov". Tak jsem se zamyslel. — 2.12.2014
  • Taco : @programator.net_1: rada "zamyslet se" není to samé, jako "porušuje to normální formu". Setkal jsem se s tabulkou, která měla 300 sloupců. Mělo to vliv na výkon, a přesto jsme nevymysleli, zda by byla špatně. Ale je to výjimka. Většinou tabulka, která má hodně sloupců stojí za zkontrolování, zda jsem něco nepřehlédl. — 2.12.2014
  • rmaslo : jj platby se normálně řešej (účetnický design pattern) v tabulce saldo. Ale třeba to je čirou náhodou dobře - to bez hlubší analýzy nelze říct. — 2.12.2014
  • onelook : Kde najdu "účetnický design patterns"? Seriózně mě to zajímá. — 2.12.2014
  • skliblatik : @onelook: něco bys mohl najít tady: http://martinfowler.com/books/ap.html — 2.12.2014
  • rmaslo : @onelook: jo tos mě pěkně dostal :-). Měl jsem kliku a někdy kolem 1995 jsem se u několika zákazníků o účetnictví (včetně bankovního) fakt hodně dozvěděl - i s různými programátorskými obraty. Ale žádnou superchytrou knihu ani odkaz nemám. Navíc problematika se samozřejmě vyvíjí, jak vznikají různé zákony a hacky na ně. Obecně doporučuji při návrhu IS schůzku s účetní (či externí uč. firmou) rozhodně nevynechat - na spoustu věcí mají navzájem rozdílný názor. — 2.12.2014
  • skliblatik : @onelook případně pohledat s knihou související články např. http://martinfowler.com/eaaDev/AccountingNarrative.html http://martinfowler.com/eaaDev/AccountingNarrative.html http://martinfowler.com/eaaDev/AccountingTransaction.html Ale je to již staršího data. — 2.12.2014
  • Honza Břešťan : Kus o accountingu z Fowlerovych Analysis Patterns se vali i u nej na webu: http://www.martinfowler.com/apsupp/accounting.pdf (sam jsem necetl a nikdy nic podobneho nenavrhoval, ale vidim na to hodne odkazu - nejen tady od @skiblatik) — 2.12.2014
  • programator.net_1 : Kit > k tvojim namietkam k tabulke. Tabulka sa naplna z externeho ekonomickeho systemu. Tam kde sa dana tabulka vyuziva , vobec nepotrebujem vediet, na kolko splatok bola uhradena. Zaujima ma len to, len kolko mal uhradit a kolko uhradil. Vobec nemam informaciu o uhradach. Datum dodania by mal byt na dodacom liste, ale tam kde sa pouziva tato tabulka, dodaci list neexistuje. Len chcem vediet ci a kedy to bolo dodane. Jan Břešťan to odhadol dobre. Takze mam 13 stlpcovu tabulku. Je vobec v takomto pripade potrebne rozbijat tu tabulku, ak ano tak preco ? — 3.12.2014
  • Kit : @programator.net_1: To bylo tak těžké tu specifikaci napsat rovnou? Zbytek viz @Taco. — 3.12.2014
  • Jirka Chmiel : Myslím, že příměr délky funkce k normalizaci DB tabulek není nejštastnější. Funkce se udržují krátké kvůli čitelnosti a znovupoužitelnosti. Tabulky se normalizují kvůli odstranění redundance. Uznávám, že vyšší počet sloupců v tabulce může sloužit jako jakýsi indikátor, ale rozhodně bych kategoricky netvrdil, že 30 sloupců už nesplňuje NF, to s tím přece nemá co dělat. — 3.12.2014
  • programator.net_1 : @kit > citujem "Pokud je to číslo dvouciferné, měl by ses zamyslet nad strukturou databáze". Kde si tu spominal specifikaciu ? Dal som ti realnu tabulku, na ktorej si mohol ukazat, ze dvojciferne cislo poctu stlpcov je zle. Len zrazu to nie je take jednoznacne, ako si to tvrdil ty. — 3.12.2014
  • Kit : BbyjbMF4LH: Kdyby sis to pořádně přečetl, tak jsem napsal: "Víc než 30 sloupců je už podle mne příznakem chybného návrhu". Ukaž mi, kde jsem něco psal o porušení NF. — 3.12.2014
  • Kit : @programator.net_1: Slyšel jsi někdy něco o fuzzy logice? Proč děláš z mých výroků kategorická tvrzení, že je to špatně? Přečti si http://www.ietf.org/rfc/rfc2119.txt Použil jsem některý z výrazů "musí" nebo "nesmí"? — 3.12.2014
  • pavel.stehule : Vyšší počet sloupců může mít i hodně negativní vliv na výkon - ještě stále většina databází ukládá po řádcích - vždy se čtou všechny sloupce tabulky z disku. Pokud vždy potřebujete všechny sloupce, tak je to ok, ale pokud ne, tak sloupce navíc mohou znamenat výrazný balast .. kterého se nezbavíte. 10 sloupečků nemusí být úplně tragických, 100 už 100% ano. — 3.12.2014
  • jan.flos : @pavel.stehule. Pozor při normálním selectu se databázový engine podívá jesti sloupečky, které selektím nejsou obsaženy přímo v indexu, pokud ano, tak je čte odtamtud. Ale v podstatě by si mohl mít pravdu. Tipicky při použití ORM se selektí trapně celá entita i s nepodstatnými technologickými daty a to vede k zbytečně velkému I/O traffic. — 4.12.2014
  • jan.flos : Poznámka k normalizaci dat: Trocha redundance nevadí, pokud člověk zajistí, že nedojde k nějaké chybě v datech. Např pomocí různých db-constraintů nebo triggerů. V dnešní době není problém kapacita ssd disků, ale rychlost serverového cpu, takže normalizace není třeba brát doslova. Jinak tabulka s více než 30 sloupečkama je opravdu podezdřelá. Pokud si člověk uvědomí, že datový model většinou odpovídá reálným objektům. Nicméně samozřejmě svoje opodstatnění může mít i Tabulka s 200 sloupečkama. Např při importech, který musí makat pekelně rychle a denormalizace je řešena až v druhém kroku. — 4.12.2014
  • pavel.stehule : @jan.flos: Ne kazda databaze pouziva index only scan, ne na kazdem sloupecku je index, a pokud je, tak kazdy index 1x zpomaluje DML operace (musi se udrzovat) — 4.12.2014
  • programator.net_1 : Napr. pri MS SQL sa daju navesat include column na indexy. Takze pokial potrebujem selectovat stlpce, ktore nie su sucastou indexu, tak sa to da riesit aj takto. — 4.12.2014
  • Kit : @jan.flos: Typickým příkladem užitečných redundantních dat jsou právě indexy. — 4.12.2014

Pro zobrazení všech 8 odpovědí se prosím přihlaste:

Rychlé přihlášení přes sociální sítě:

Nebo se přihlaste jménem a heslem:

Zadejte prosím svou e-mailovou adresu.
Zadejte své heslo.

Aktuální otázky v rubrice Programování: Java

Otázky uživatele jan.flos