Mají tabulkové databáze v dnešní době smysl?

[Ondrej Nemecek]

Akorát se tu trochu zapomíná na to, že reálná ORM umožňují psát SQL nebo mají API, které SQL věrně kopíruje. Pak si může člověk vybrat a pořád má výhodu mapování na objekty. Otázka je, kolik práce si tím ve výsledku ušetří a kolik přidělá, což se ale bude lišit projekt od projektu.

Já myslel, že se tady bavíme o ORM jako o programovací technice, ne o tom, že v reálu si ORM frameworky jen s ORM přístupem nevystačí a musí k tomu přilepit funkčnost, která už nemá s ORM prakticky nic společného a která zcela zásadně narušuje tu úroveň abstrakce, na které pracuje ORM.

OK, jako čistý koncept je ORM dost omezené. Ale v praxi to lze docela snadno řešit, takže to moc nevadí.

[Reklama]

[O]

Akorát se tu trochu zapomíná na to, že reálná ORM umožňují psát SQL nebo mají API, které SQL věrně kopíruje. Pak si může člověk vybrat a pořád má výhodu mapování na objekty. Otázka je, kolik práce si tím ve výsledku ušetří a kolik přidělá, což se ale bude lišit projekt od projektu.

Já myslel, že se tady bavíme o ORM jako o programovací technice, ne o tom, že v reálu si ORM frameworky jen s ORM přístupem nevystačí a musí k tomu přilepit funkčnost, která už nemá s ORM prakticky nic společného a která zcela zásadně narušuje tu úroveň abstrakce, na které pracuje ORM.

OK, jako čistý koncept je ORM dost omezené. Ale v praxi to lze docela snadno řešit, takže to moc nevadí.

Jo, v praxi se to ojebává právě tím, že se tomu pořád říká ORM framework, ale půlka ho není ORM, ale nějaké přibastlené extra API, aby se přes to dalo s tou databází jakž takž pracovat jako s databází.

[Kamil Podlešák]

Jo, v praxi se to ojebává právě tím, že se tomu pořád říká ORM framework, ale půlka ho není ORM, ale nějaké přibastlené extra API, aby se přes to dalo s tou databází jakž takž pracovat jako s databází.

Pro tento abstraktní koncept existuje dokonce i termín, ale bohužel dnes velmi politicky nekorektní:

kompromis

A teď to schytám, tak jdu raději spát.

[Kit]

Jo, v praxi se to ojebává právě tím, že se tomu pořád říká ORM framework, ale půlka ho není ORM, ale nějaké přibastlené extra API, aby se přes to dalo s tou databází jakž takž pracovat jako s databází.

Na ORM je tedy nejlepší to, co není součástí ORM.

[JS]

Jo, v praxi se to ojebává právě tím, že se tomu pořád říká ORM framework, ale půlka ho není ORM, ale nějaké přibastlené extra API, aby se přes to dalo s tou databází jakž takž pracovat jako s databází.

Na ORM je tedy nejlepší to, co není součástí ORM.

Je to skoro tak. Driv jsem byl fanousek ORM, ale spalil jsem si na tom prsty (omylem jsem provedl neco, co melo byt jako jedna transakce pomoci vice transakci v ORM, a zpusobilo to samozrejme chybu pri selhani).

ORM se lidi casto uci s tim, ze jim to usnadni pristup do DB oproti SQL. Bohuzel to tak neni, ve vysledku se budete muset to SQL (a hlavne relacni mysleni, jak pise pan Stehule, ja bych k tomu dodal jeste transakcni mysleni) stejne naucit, takze ORM vam v tom uceni bude jen prekazet. Predstava, ze se snaz naucite databaze prostrednictvim ORM, pokud uz umite OOP, je proste velky omyl.

[Reklama]

[Kit]

ORM však může být užitečné tam, kde chci (já tedy ne) narychlo splácat nějaký nenáročný web.

[SB]

Nejde jen o optimální SQL, jde také o strukturu dat. Jinak budete reálný svět modelovat pomocí grafu objektů a jinak pomocí relací.

Jasně, ale pak přichází otázka, jestli je vhodné reálný svět ukládat do RDB, když budu muset nutně někde udělat docela komplikovaný překlad.

[SB]

Připadá mi, že ORM svádí k programování ve stylu:

Kód: [Vybrat]

sum = 0
foreach a = collection_of_a()
  if test(a) then
    b = collection_of_b(a.b_id)
    if test(b) then
      sum += b.val
return sum
Není mi jasné, jak tohle dobré ORM zoptimalizuje, i když je jasné, že se to dá přepsat do jednoho SELECTu s JOINem dvou tabulek.

Nikde není napsáno, že součásí ORM nemůžou být vaše ručně psané, optimalizované operace (a nejspíš budou). Ale to platí pro VŠECHNY typy databází - mícháte dohromady 2 věci - nutnost překladu mezi formáty dat a výběr strany zpracování operací.

[Kit]

Nejde jen o optimální SQL, jde také o strukturu dat. Jinak budete reálný svět modelovat pomocí grafu objektů a jinak pomocí relací.

Jasně, ale pak přichází otázka, jestli je vhodné reálný svět ukládat do RDB, když budu muset nutně někde udělat docela komplikovaný překlad.

Ty překlady do relační databáze bývají jednodušší, než se na první pohled zdá.

[SB]

Myslel jsem, že ORM má skrývat fakt, že data jsou v relační databází a prezentovat mu je, jako by byly v nějakém úložišti objektů.

To jste myslel dobře.

Pak mi ale připadá přirozené, že programátor s objekty pracuje po jednom a explicitně přechází mezi nimi pomocí vzájemných odkazů a při tom neřeší, že každý krok znamená dotaz do databáze.

To nemusí být vůbec pravda, to záleží na provedení ORM.

Není mi moc jasné, jak by mělo ORM vypadat, aby navádělo k efektivní práci s databází a zároveň nevypadalo jako SQL přebalené do jiné syntaxe.

Pro výkonově náročné operace vytvoříte extra funkce ORM, které v DB úpravy provedou a případné změny sesynchronizují s objektovým modelem.

[SB]

Mě na SQL přijde revoluční právě ten deklarativní zápis. Pošleš engine algoritmus, a on ti vyplivne výsledky. Něco podobné je možné pozorovat u LINQ, nebo GraphQL. Díky tomu se opravdu můžu oprostit od detailů práce s databází (na druhou stranu mi přijde zase škoda vzdát se pokročilejších možností) aniž by to začalo být brutálně neefektivní.

Nechápu, co tenhle odstavec měl vyjadřovat. Jestli "oprostit od detailů práce z databází" znamená, že s databází komunikuju pomocí SQL, tak to nemá s ORM nic společného. Jestli to má znamenat, že díky deklarativnímu SQL se můžu oprostit od detailů použitím ORM, tak to není pravda.

Pokud si dobře pamatuju, tak Linq bylo jen převlečené SQL, které se sice nezapisuje řetězcem, ale syntaxí C#, ale pořád popisuje tu samou strukturu tabulek v DB. To není ORM.

V některých svých hračkách, co jsem dělal jsem měl specializovaný DSLko, kterým jsem se dotazoval na objekty, a pokoušel jsem se to mé pseudoORM přinutit, aby generovalo SQLka, která bych napsal stejně. Celkem to šlo.

U DSL specializovaného pro nějakou konkrétní aplikaci jsem ochoten věřit, že to může generovat rozumné SQL. Ale pak to asi nebude obecně použitelné ORM.

Překlad mezi objekty a relacemi se dá dělat několika způsoby. Jedním z nich je mapování jednotlivých položek objektů na položky relací. Osobně považuju tento způsob za zbytečně pracný. Upřednostňuju mapování celého (celistvého!) objektu na jednu tabulku (v jednoduchém případě) až smršť tabulek (v nejhorším případě). Vedle toho několik ručně optimalizovaných hromrdných operací.

Nebo jiný způsobem. Nette/Database to dělá tak, že dokáže zoptimalizovat i ten tvůj kód. Při prvním průchodu to provede všechny dotazy, to si nakešuje, a při dalších už to načítá hromadně. Mě ten způsob není moc sympatický, ale funguje to.

I když pominu, že ten první průchod může trvat nechutně dlouho, tak jestli při dalších průchodech už nekomunikuje s databází a čte z keše, tak to bude mít minimálně dvě další nevýhody: 1. Keš může být hodně velká; 2. Bude to fungovat správně, jen když se data v databázi nebudou měnit.

Zní to jako řešení na hovno - platí, že čím víc toho čtu a držím navíc, tím je to 1. náročnější na zdroje, 2. musím řešit více synchronizace.

[bck]

ORM se lidi casto uci s tim, ze jim to usnadni pristup do DB oproti SQL. Bohuzel to tak neni, ve vysledku se budete muset to SQL (a hlavne relacni mysleni, jak pise pan Stehule, ja bych k tomu dodal jeste transakcni mysleni) stejne naucit, takze ORM vam v tom uceni bude jen prekazet. Predstava, ze se snaz naucite databaze prostrednictvim ORM, pokud uz umite OOP, je proste velky omyl.

a není to náhodou chyba toho přístupu (rel+SQL)? Proč se mají lidé věčně učit myslet jinak, než jak je to od přírody dáno?
A jaké jsou výsledky:

- programátoři by měli myslet objekt-orientovaně ...vysledkem jsou procedurální programy ve kterých jsou struktury zaměněny za třídy

- programátoři by měli myslet relačně ... výsledkem jsou programy, kde se čte záznam po záznamu

Zajímavá je otázka, co se děje, když nekdo přistoupí na vaše doporučení a naučí se myslet jak požadujete a programuje v nejakém OO jazyce za použití rel.databaze s SQL. Podle mých zkušeností je nejlepší dopoledne psát ten program a odpoledne k tomu dodělat ty selecty. A samozrejmě je třeba po pracovní době přepnout do toho procedurálního myšlení, aby člověk nazapomněl vystoupit na správné stanici z tramvaje.
 

[SB]

Mě se docela líbí taková ta úplně lehká ORM jako třeba http://javalite.io/activejdbc#design-principles, akorát mě tam štve ten zápis sloupců jako string (dá se řešit tím, že si člověk napíše gettery a settery ručně).

Sloučení funkcionality modelu a úložiště do jedné třídy (zde Model, což určitě není POJO, jak tvrdí dokumentace) není dobrým nápadem - jak se řeší výměna typu databáze na pozadí či získávání objektů z více zdrojů? Mimoto rychlé čtení a zápis objektů, které se vejdou do jednoho řádku tabulky (zdejší primitivní příklad), umí každé ORM. Problém je rozklad objektu do více tabulek (což je v praxi zcela běžnou situací).

[SB]

A jak cache v aplikaci zjisti, ze data ktera si nacachovala jsou stale platna?

Samozřejmě zápis musí přistupovat přes API zahrnující tu keš. Do DB napřímo zápis jen při shozené aplikaci...

Máme takto udělané poměrně komplikované kešující ORM a funguje už 15 let OK. Samozřejmě všechno má své pro i proti.

Co když do té databáze zapisuje spousta aplikací zároveň? Pro mne je to velmi častý případ a nějaké zámky by mohly skončit i deadlockem.

Umožňuje-li DB oddělené zpracování jednotlivých transakcí, deadlock nenastane. Řežou-li se transakce přes sebe, nedá se deadlock vyloučit.
Na to se právě hodí aplikační server, který nejenom řeší nezávislost klientů na úložišti, ale může sám řešit řazení transakcí a cacheování.

[SB]

ORM se lidi casto uci s tim, ze jim to usnadni pristup do DB oproti SQL. Bohuzel to tak neni, ve vysledku se budete muset to SQL (a hlavne relacni mysleni, jak pise pan Stehule, ja bych k tomu dodal jeste transakcni mysleni) stejne naucit, takze ORM vam v tom uceni bude jen prekazet. Predstava, ze se snaz naucite databaze prostrednictvim ORM, pokud uz umite OOP, je proste velky omyl.

Já se obávám, že zde mnoho přítomných stále nepochopilo, že mít objektový model a relační DB bez ORM jaksi z podstaty nejde - někak se ty relace musejí měnit na objekty a naopak, a to bez ohledu na realizaci. Ano, nemusíte používat knihovní ORM, pak si překlady musíte udělat sami, ale to je právě to ORM. A nebo se na ORM vyserete a povedete model v aplikaci v n-ticích či samostatných hodnotách, to ale nemá s OOP nic společného.