Být databázovým strojem, nemám ORM rád (diskuse)

[Ladicek]

The Vietnam of Computer Science, co na to říct víc.

[paskma]

Tenhle post je o budu čtyři ze závěru zmiňovaného článku:

Acceptance of O/R-M limitations

[JS]

Podle me je "Vietnamem CS" samotna myslenka, ze datove struktury lze reprezentovat jako sit samostatnych nezavislych objektu. Nechci zcela shazovat prinos OOP, ale myslim, ze casto vede na tento druh programovani.

[Ladicek]

samotna myslenka, ze datove struktury lze reprezentovat jako sit samostatnych nezavislych objektu

Což lze, že jo. Stačí mít persistentní heap, ne nějakou přiblblou SQL databázi

[Ivan]

Takovymhle systemum asi patri budoucnost. Ty priblble SQL databaze jeste porad vedou v parametrech jako: kapacita, zalohovani, performance a replikace. Objektove databaze maji jedinou vyhodu, ktera se jim neda uprit, setri cas programatoru.

[Ladicek]

Když na to přijde, to jsou všechno řešitelné problémy. V diskusích tady na Ábíčku by se daly dohledat Kyosukeho zmínky o "velkých" objektových databázích nad Lispem; já osobně o tom nic nevím, ale nevidím důvod, proč by to nemělo jít. Výhody relačních databází jsou asi spíš implementační. A vezměte třeba "sloupcové" databáze (BigTable a spol.), tak úžasně vám relační databáze neškálujou ani náhodou

[Deleted [8409]]

Používám SQLAlchemy a mám podobný problém s ORM. V plánu je přepsat aplikaci do budoucna tak, aby se nikde nepoužíval ORM.

Na druhou stranu je fakt jednoduché s tím dělat. Člověk napíše to co potřebuje opravdu relativně rychle a nehrozí třeba SQL Injection a další blbosti.

[mkoubik]

Jak z toho ven?

Kešovat. Při načtení objektu tento uchovat pro případ, že budou potřeba i ostatní atributy a při update/delete/insertu cache zneplatnit.

[paskma]

Vždyť ten převod na hashmapu vlastně takovým cachováním je.

Pořádné cachování by se muselo domastit přímo do djanga.

[heracek]

Tento clanek je pomerne zcestny. Uz v dobe kdy byl psan byl nepresny az nepravdivy.

Django umoznuje v jedinem SQL dotazu pomoci metody  select_related() instance tridy QuerySet ziskat pozadovane objekty i s objekty vztazenymi (tj. PopiskaZbozi i prislusne Zbozi). Staci zapsat:

popisky = PopiskaZbozi.objects.filter(<vyhledavaci_podminky>).select_related('zbozi')

Pote kod v sablone {{ nějaká_popiska.zboží.počet_na_skladu }} i zvoleny zpusob razeni nevyvolaji dalsi SQL dotazy.

Popripade lze zapsat select_related(), nebo select_related(depth=1). Viz dokumentace QuerySet API reference. (dalsi reseni by bylo pouziti metod values() nebo values_list() instance QuerySet)

 

Dale autor operuje s nevyslovenym predpokladem, ze jeden velky dotaz do SQL databaze je vzdy rychlejsi, nez mnoho malych. Tento predpoklad nemusi vzdy platit (obvzlast u MySQL) a je ho treba podlozit merenim (ostatne jako kazdou spravnou optimalizaci)

 

Dale popsane razeni:

def porovnej_popisky(a, b):
    return cmp(a.zboží.počet_na_skladu, b.zboží.počet_na_skladu)

seznam_popisek.sort(porovnej_popisky)

bych pouzil jen v opravdu jenkrajsim pripade (napriklad - chci ziskat prvnich 10 objektu PopiskaZbozi serazenych abecedne podle popis, ale vysledek chci nakonec seradit podle pocet_na_sklade).

Django pro serazeni na urovni SQL pouziva metodu order_by() instance QuerySet.

Vysledny kod by mohl vypadat takto:

popisky = PopiskaZbozi.objects.filter(<vyhledavaci_podminky>).select_related('zbozi').order_by('zbozi__pocet_na_sklade')

Vysledkem je jediny SQL dotaz (i kdyz pritupuji ke zbozi) a objekty jsou jiz z SQL serveru poslany serazeny.