Přejít k navigační liště

Zdroják » Databáze » ORM je antipattern

ORM je antipattern

Články Databáze, Různé

Do diskusí o ORM, NotORM, SQL, noSQL a dalších tentokrát přidáme jeden poměrně radikální názor na ORM. Jeho autor vzbudil tímto článkem poměrně silnou a ostře polarizovanou diskusi mezi vývojáři. Přesto jeho argumenty stojí minimálně za přečtení a zamyšlení. Souhlasíte s nimi? Nesouhlasíte?

Článek je volně přeložen z anglického originálu ORM is an anti-pattern, který napsal Laurie Voss (technický vedoucí awe.sm, dříve např. Yahoo! Widgets) a vydal ho na svém blogu pod licencí CC-BY-NC-SA. Vydáváme ho zde se souhlasem autora a pod stejnou licencí.

Minulý týden jsem tweetnul o ORM, a od té doby se mě několik lidí ptalo, jak jsem to myslel. Já jsem sice o ORM už psal, ale to bylo v kontextu větší diskuse o SQL a já bych to nerad míchal dohromady. Takže v tomto textu se budu držet pouze problematiky ORM. Vynasnažím se být stručný, protože z předchozích článků o SQL vím, že lidé mívají sklon po první větě, která je naštve, přestat číst a rovnou komentovat (i kdyby třeba dál v textu bylo tvrzení vysvětleno).

Co je to antipattern?

Potěšilo mě, když jsem našel na Wikipedii obsáhlý seznam antipatternů, jak ze světa programování, tak i mimo něj. Proč považuju ORM za antipattern? Protože splňuje hned dvě kritéria, která podle autora knihy AntiPatterns odlišují antipatterny od špatných návyků. Konkrétně:

  1. Na začátku se jeví jako přínosné, ale postupem času se objevuje víc špatných důsledků, než těch dobrých
  2. Existuje alternativní řešení, které je ověřené a znovunasaditelné

Právě ten první faktor vedl, podle mého, k obrovské popularitě ORM: na začátku to vypadá jako dobrý nápad, a když se postupem času objevují problémy, už je pozdě něco měnit.

Co označuji jako ORM?

Hlavní cíl mé kritiky je ActiveRecord, zpopularizovaný v Ruby on Rails a portovaný do půltuctu dalších jazyků. Ale stejně tak lze většinu výhrad vztáhnout i na jiné ORM, jako Hibernate v Javě a Doctrine v PHP.

Výhody ORM

  • Jednoduchost: některé ORM nástroje vám budou tvrdit, že „odstraní nutnost znát SQL“. To je slib, který žádný z těch, co jsem viděl, nesplnil. Jiné jsou realističtější a prohlásí, že redukují množství SQL, ale dovolí vám jej používat, když bude potřeba. S jednoduchým modelem a s projektem v počátcích je to rozhodně výhoda: s ORM budete vyvíjet rychleji a efektivněji, o tom nepochybujte. Dost možná si ale zaděláte na problémy v budoucnu.
  • Generování kódu: odstraněním uživatelského kódu z modelů pomocí ORM otevřelo cestu generování kódu, „scaffoldingu“, které vám dá funkční rozhraní ke všem tabulkám na základě jednoduchého popisu schématu. Navíc můžete schéma změnit a vygenerovat kód nový. Zase – funguje to perfektně na začátku.
  • Efektivita je „good enough“: žádný z ORM, které jsem viděl, neprohlašuje, že zvýší efektivitu. Všechny říkají, že upřednostňují jednodušší kód před výkonem. A když náhodou začne být výkon nedostatečný, můžete přece nahradit pomalé volání ORM ručně napsaným SQL, není-liž pravda?

Problémy s ORM

Neodpovídající abstrakce

Nejzjevnější problém u ORM je, že jde o abstrakci, která nedostatečně abstrahuje od implementačních detailů. Dokumentace všech velkých ORM knihoven je běžně plná odkazů na koncepty z SQL. Někdy jsou představeny, aniž by bylo řečeno, že mají ekvivalent v SQL, jindy jsou zase představovány jako funkce pro generování SQL.

Celý vtip abstrakce spočívá v tom, že by měla zjednodušovat. Abstraktní vrstva nad SQL, která předpokládá, že znáte SQL, vlastně zdvojnásobuje množství věcí k naučení: musíte umět SQL, abyste chápali, jak položit dotaz, a musíte umět přimět svoje ORM, aby ho za vás položilo. Například v Hibernate se ještě učíte třetí jazyk, HQL, což je téměř-úplně-ale-ne-naprosto SQL, a to se pak do SQL překládá.

Zastánci ORM řeknou, že to neplatí pro každý projekt, že ne každý potřebuje složité JOINy, že ORM je řešení „80/20“, protože 80 procent uživatelů potřebuje pouhých 20 procent možností SQL, a právě to ORM zařídí. Ze své patnáctileté praxe vývojáře databázových projektů mohu říct, že tohle u mne neplatilo. Pouze na samotném začátku vývoje se můžete obejít bez JOINů nebo s naivními JOINy. Později se dostanete k tomu, že je nutné dotazy konsolidovat a vyladit. I kdyby 80 % uživatelů potřebovalo 30 procent schopností SQL, tak 100 % uživatelů nakonec bude muset ORM abstrakci obejít, aby jim to nakonec fungovalo.

Nesprávná abstrakce

ORM vám bude skvěle fungovat v případě, že opravdu nepotřebujete žádné relačně-datové funkce, ale v takovém případě máte jiný problém: používáte špatné datové úložiště. Režie RDBMS je enormní; to je jeden z nejdůležitějších faktorů, proč jsou  NoSQL úložiště o tolik rychlejší. Pokud jsou vaše data relační, tak se tahle režie vyplatí: vaše databáze nejen ukládá data, ona je reprezentuje a dokáže odpovědět na otázky ohledně těchto dat, a dokáže to díky zachycení vztahů mnohem efektivněji než procedurální kód.

Pokud vaše data relační nejsou, pak jen přidáváte spoustu nepotřebného zpomalení – v první řadě je pomalá RDBMS, a nad ní ještě postavíte další zpomalující vrstvu v podobě ORM.

Na druhou stranu pokud vaše data relační JSOU, tak se nakonec mapování na objekty rozbije. SQL je založené na relační algebře: výstupem SQL není objekt, ale odpověď na dotaz. Pokud váš objekt „je“ instancí X a „má“ několik Y, a každé Y „patří“ Z, jaká je správná reprezentace takového objektu v paměti? Měly by to být jen vlastnosti X, nebo by měly obsahovat i Y a/nebo i všechna Z? Pokud budete mít pouze vlastnosti X, kdy se dotážete na Y? A budete potřebovat jedno Y, nebo všechna? Ve skutečnosti to záleží na okolnostech – to je to, co mám na mysli, když píšu, že SQL odpovídá na otázky. Reprezentace objektu v paměti záleží na tom, co se s ním chystáte dělat. OO design nenabízí nic jako „kontextově senzitivní reprezentaci“. Zkrátka: Relace nejsou objekty. Objekty nejsou relace.

Zabitý tisícem dotazů

Důsledkem je další problém ORM: neefektivita. Když si vyzvednete objekt, které z jeho vlastností (sloupců tabulky) budete potřebovat? ORM to neví, tak si řekne o všechny (nebo požaduje, abyste specifikovali sami, čímž rozbíjí abstrakci). Na začátku to není problém, ale když začnete načítat tisíce záznamů najednou, každý s 30 sloupci, z nichž potřebujete jen tři, máte smrtelný zdroj neefektivity. Mnoho ORM nástrojů je také výrazně slabých ve vytváření JOINů a raději pokládají tucet dotazů k jednomu objektu. Jak jsem už psal výše, mnohé ORM výslovně říkají, že nejsou zaměřené na efektivitu, a některé nabízejí způsob, jak problémové dotazy vyladit. Problém, který jsem v praxi pozoroval, je ten, že málokdy najdete jediný dotaz, „stříbrnou kulku“, kterou stačí optimalizovat. Smrtící pro databázové aplikace není efektivita jednoho konkrétního dotazu, ale množství dotazů. ORM chybí kontext, takže nedokáže dotazy správně konsolidovat a musí se uchylovat ke kešování a dalším mechanismům, které mohou tento nedostatek kompenzovat.

Jaké jsou alternativy?

Doufám, že se mi podařilo předvést některé případy, kde mají ORM zásadní návrhové nedostatky. Ale k tomu, aby byly antipatternem, potřebují mít alternativu. Ve skutečnosti mají hned dvě:

Používejte objekty

Jestliže jsou vaše data objektová, přestaňte používat relační databázi. IT je v současnosti zaplavené různými key-value úložišti, které umožňují uchovávat elegantní datové struktury ve velkých počtech a přistupovat k nim rychlostí světla. Není žádný programátorský zákon, který by říkal: „Krok č. 1 při psaní webové aplikace je nainstalovat MySQL“. Masivní nadužívání relačních databází na každou situaci, kdy je potřeba uložit data, je jedním z důvodů, proč si SQL získává v posledních letech tak špatnou pověst. Ve skutečnosti je příčinou líný návrhář, který nehledal vhodné úložiště, ale použil RDBMS.

Použití SQL v modelu

V programování je extrémně nebezpečné prohlašovat, že k něčemu existuje Jediná Správná Cesta™ jak to udělat. Podle mých zkušeností je nejlepším způsobem, jak reprezentovat relační data v objektově orientovaném kódu, stále pomocí modelu: zapouzdření datové reprezentace do jediného místa v kódu je dobrý nápad. Ale pamatujte, že úkolem vaší modelové vrstvy není reprezentovat objekty, ale odpovídat na otázky. Vytvořte si API, které odpovídá na otázky, co mu pokládá aplikace, a udělejte to tak jednoduché a efektivní, jak je potřeba. Někdy budou odpovědi svérázné, takovým způsobem, který i novopečený OO vývojář označí za „špatný“, ale postupem času budete nalézat stále lepší průsečíky obou světů, což vám dovolí refaktorovat dotazy do efektivní podoby.

Někdy bude výstupem jednoduchý objekt X, který je snadné reprezentovat. Ale jindy může být výstupem matice agregovaných dat, nebo naopak jediné celé číslo. Odolejte pokušení zabalit všechno tohle do mnoha vrstev abstrakce, a přistupujte k datům podle jejich vlastní přirozenosti. Především odolejte klamu OO, že dokáže reprezentovat naprosto cokoli a všechno. OO samotné je abstrakcí, hezkou a velmi ohebnou, ale právě relační data jsou jednou z hranic OO. Předstírání, že objekty mohou dělat něco, co dělat nedokážou, je základní problém v každém ORM.

Shrnutí (TL;DR)

  • ORM je na začátku snadný k pochopení a vývoj s ním je rychlejší než psaní modelů se SQL
  • Jeho efektivita je na počátku dostatečná
  • Naneštěstí se s růstem komplexnosti projektu projeví nedostatky: abstrakce je rozbitá a nutí vývojáře používat pokročilé SQL
  • V nadsázce tvrdím, že se abstrakce ORM rozbije ne ve 20 % projektů, ale skoro ve všech.
  • Objekty nejsou správná cesta, jak vyjádřit výsledky relačního dotazu
  • Nemožnost jednoznačného mapování dotazů na objekty vede k zásadním neefektivitám v aplikacích, které používají ORM. Tyto neefektivity prostupují celý projekt, jsou distribuované a proto nemohou být odstraněny ani napraveny jinak, než kompletním opuštěním ORM.
  • Zkuste se pořádně zamyslet nad designem aplikace dřív, než mechanicky nasadíte relační databázi a ORM
  • Pokud jsou vaše data přirozeně objektová, tak použijte objektová úložiště („NoSQL“). Budou mnohem rychlejší než SQL s ORM.
  • Pokud jsou vaše data z podstaty relační, pak se zvýšená režie RDBMS vyplatí.
  • Zapouzdřete SQL dotazy do modelové vrstvy, ale navrhněte svoje API tak, aby vracelo data, potřebná pro vaši aplikaci; nepodlehněte pokušení příliš generalizovat.
  • Objektově orientovaný design nedokáže reprezentovat relační data efektivním způsobem; to je zásadní omezení OO designu a ORM ho nedokáže napravit.

(Podobný pohled nabízí i článek The Vietnam of Computer Science, kde je použití ORM svým průběhem přirovnáváno k Vietnamské válce. – pozn. překl.)

Komentáře

Subscribe
Upozornit na
guest
150 Komentářů
Nejstarší
Nejnovější Most Voted
Inline Feedbacks
View all comments
VM

Díky za hezký článek – přesně stejný dojem jsem měl ze všech těch frameworků, o kterých mi tvrdili že jsou moderní. Nakonec jedu na několika jednoduchých funkcích typu „vem dotaz, přiřaď proměnné, vrať tabulku“, a jsem spokojený. Žádný prales objektů, žádné učení se zbytečné mezivrstvy, když už umím SQL.

blizz
Jean
Já

aneb jak být papežtější než papež. Zbytečnou práci na CRUDech rád ušetřím, strojovej čas je levnější než ten můj.

fuzzy

Ovšem ORM není jenom o CRUD operacích, to je naopak jenom zcela zcela zanedbatelná část slibované funkčnosti. Otázka je jestli to co např. v Hibernate ušetříte na psaní CRUD nepropálíte na bitvě s HQL apod. A je otázka jestli toto dokážete odhalit a včas ORM zahodit (což je předmětem toho článku Vietnam of computer science).

A ano, strojovej čas je levnější – bohužel to platí jenom pokud ORM nezačne baštit exponencielně mnoho CPU (např. pokud 2x větší databáze -> 8x delší zpracování). To pak abyste tam ty nové servery vozil kamiónem.

Já

Jak to víte, že je to zanedbatelná část slibované funkčnosti? Většina aplikací na internetech(CMS?) si vystačí se základním CRUDem a tu a tam s nějakým joinem (na který v případě staré doctriny potřeba další jazyk nebyl). Že udělá jeden dva dotazy na request navíc je každému pragmaticky jedno.

Vyjmenované ORMy nejsou úplně hloupé aby při správném použití dělali to co píšete. To, že je programátor blb příp. mu manuál nic neříká, od toho mu nepomůže ORM ani SQL.

Pokud máte firmu, kde Vám poskoci SQLka a obsluhu naťukají tak potom žádná. Pokud děláte aplikace sám pro sebe je každá ušetřená sekunda vývoje dobrá, optimalizuje se až je to potřeba.

fuzzy

Vycházím z toho jak je to na projektech na kterých pracuji a nemyslím že by byly „netypické,“ spíše naopak. Ale samozřejmě asi jsou projekty které jsou silně CRUD a další funkcionality je minimum.

Nicméně vyjadřoval jsem se k tomu co ORM slibuje, a tam jsou CRUD operace skutečně jenom zlomek celku …

Napsat SQL pro základní CRUD je minimum práce, není problém to i vygenerovat. A dotazy ve výsledku stejně musíte napsat, je celkem jedno jestli to je SQL, HQL nebo cosi dalšího.

Palo

> Napsat SQL pro základní CRUD je minimum práce
Tak toto je nezmysel. Vacsi graf vyzaduje ladenie ktore my poskytuje ORM bez toho aby som sa zababral do detailov. Uz len hlupa relacia z jednej entity na dalsich N vyzaduje pri vasom pristupe N*N dotazov ktore my dokaze pri spravnom pouziti ORM framework vytvorit za chodu.

> silně CRUD a další funkcionality je minimum
A tie nie su vhodne pre pouzitie ORM? Jedine s cim viem suhlasit su davkove operacie tipu, jeden update cez viac riadkov inac aj davkove spracovanie sa da urobit v Jave cez ORM efektivne.

JS

Ono tyhle argumenty neplati jen pro databaze, svym zpusobem je „antipattern“ i OOP. Ne kazdy system je vhodne modelovat jako sit objektu, kde kazdy z nich zna jen malou cast vzajemne strutury.

Prijde mi, ze v jadru je to spor centralizace vs. distribuovanost. Oboji ma svoje vyhody a nevyhody.

Allstar

+1
Jsem rád, že na onom světě existuje ještě někdo kromě mě, kdo si to taky myslí.

talpa

nevhodne pouzite OOP… nakonec paradoxne zjistite ze pri slozitych vazbach na jednoduche veci pisete vic nez bez OOP

okbob

ORM je přežitek – pro serializaci objektů jsou to NoSQL KV databáze, a pro datově orientované aplikace postavené nad relační databází je výhodnější procesní přístup.

logik

To je myslím postaveno příliš černobíle. Uživatelé +- přemýšlí v objektově („todle je stůl, todle je třída, todle jsou učitelé), takže např. pro webovej frontend jsou objekty a whodný.

Jenže často pak aplikace potřebuje např. statistiky, nějaký dávkový zpracování apod., kam se zas hodí „procesní přístup“ a kde s jednoduchým ORM si člověk zavede víc problémů, než užitku.

fuzzy

Také bych to neviděl tak černobíle, Pavel má ale pravdu že koncepty objektového a relačního světa se dost zásadně liší, a optimální je používat technologie které k sobě pasují. Tj. relační databázi a procedurální programování nebo OOP a vhodný storage (KV store, objektovou databázi apod.).

Ve chvíli kdy se kombinují různé světy (např. OOP aplikace ukládající data do RDBMS), plynou z toho potíže.

Otázkou je co dělat v situacích kdy z OOP programu prostě potřebujete interagovat s RDBMS … buď můžete znásilnit jednu nebo druhou stranu, ale vždycky to bude haprovat.

logik

No, v RDBMS jde také psát dosti „objektově“. Jistě se shodneme, že objektovost nespočívá primárně v tom, že se věci musí dědit (což bývá v DB problém) nebo že se píše tečkovou syntaxí.

Zatím jsem ve své praxi došel k tomu, že lepší než silnej ORM (kterej většinou dosti zabije DB) je kód v DB. Ideální by m,i přišel nějakej překladač nějakýho rozumnýho jazyka (třeba i s tečkovou syntaxí) do SQL.

v6ak

„se věci musí dědit (což bývá v DB problém)“
PostgreSQL to zvládá, ale jinak to problém více nebo méně je.

logik

No postgresql má inherited tables, ale ty se na to až tak nehoděj, nefungujou pak cizí klíče a unique věci tak, jak by člověk čekal (a bylo potřeba). Ale třeba časem…

fuzzy

No, inheritance v PostgreSQL bylo původně skutečně míněno jako objektová vlastnost – vzniklo to v rámci hrátek s objektově-relačními databázemi. Ale to řeší jenom minimum problémů které se vyskytují na rozhraní objektového a relačního světa.

Dnes se přes to řeší v podstatě jenom partitioning, a je otázka jestli se too nakonec nezahodí a partitioning se nevyřeší nějak úplně jinak.

Jirka Hradil

ORM byla myslim nutna cesta k pochopeni, jak nevypada budoucnost. Dobra myslenka se zvtrla v naprosty overkill. Jsou ORM, ktere jsou z meho pohledu docela pouzitelne (Active Record) a dalsi, ktere jsou extrem (Hibernate). Je to ale vzdy o spravnem pouziti. ORM v rukou nezkuseneho cloveka napacha velke skody. Generace dotazu funguje dobre, pokud clovek vi, na co si ma dat bacha (lazy vs eager loading, batch updates). ORM potrebuje mentoring a zkusenosti, v default pouzivani vzroste pocet dotazu do databaze nekolikanasobne a ladit to za behu je pekeles.

Jinak samozrejme souhlas, budoucnost pro serializaci objektu jsou KV. I v cloudu (amazon, rackspace) se to podstatne lepe horizontalne skaluje.

fuzzy

Tak on někdo prostě musí zkusit ten cigaretový kouř vyfukovat do odtoku umyvadla aby zjistil že tímto postupem zlato nevznikne …

Základním problémem ORM myslím je že to navrhují OOP lidi pro OOP lidi a slibují jim abstrakci od RDBMS. Což vesměs končí dost smutně, například znovuobjevováním dotazovacího jazyka (HQL apod.). Jedinou světlou výjimkou je podle mého iBatis – když už potřebujete ORM, tak něco takového.

T

1. Ziadna nova tema a bola uz spracovana mnohokrat ovela lepsie

2. Scenar takychto clankov a uvah je takyto. Zabudnime na fakty a vecne argumenty. Zabudnime, ze kazda aplikacia je specificka a ze specifika su to najdolezitejsie, co treba zohladnit pri volbe patternov, pristupov, frameworkov. Majme hypotetciku osobu, ktora tvrdi ze ORM je nieco univerzalne, vsade a vzdy vhodne uplatnitelne, ze patterny implementovane pri ORM frameworkoch sa hodia na vsetko. Podme sa pohravat so slovkami vhodna a nevhodna abstrakcia, akoby toto niekto rozumny prehlasoval za hlavny ciel ORM. A flame clanok je na svete.
Uz ma unavuju taketo clanky a uvahy.

Zjednusene, dobry ORM framework je aplikaciou niekolkych patternov, ktore si predtym ludia implementovali sami(podla specifik projektu). Kazdy pattern ma svoje uplatnenie (kedy je ho vyhodne pouzit) ale aj situacie, kedy jeho aplikacia kontraproduktiv­na(kto cita Fowlera, tak to vzdy najde). Aj samotny fmwk ako NH umoznuje obrovske mnozstvo pristupov. Jedno z nich je napr. rozhodnutie, do AKEJ MIERY chcem a mozem abstrahovat od vlastnosti konkretnej DB (a v tom pripade musim ratat s obmedzeniami a problemami ak pouzivam ORM) ale to musim pocitat s konkretnymi vlastnostami RDBMS pod zadkom, tak to neznamena ze ORM je problem.(ak je to samozrejme vyspely ORM ako NH)

Cierna alebo biela. Go NoSQL, RDBMS+ORM je prezitok. Hlupost. Existuje mnozstvo pristupov, ktore pri konkretnom projektovom setupe/specifkach umoznuju pekne sa vysporiadat s roznymi problemami(napr. v suvislosti s ORM) a zaroven profitovat zo silnych stranok.

Podla mojich skusenosti je kritika ORM zalozena dost casto na zlej skusenosti s ORM, niekto vykapal na velkom objektovom grafe. Well. Ale existuju alternativne pristupy napr. CQRS. Naco znasilnovat ORM na to, na co vymysleny nebol, na query dotazy?

Btw. cast patternov aplikovanych pri ORM je implementovana aj pri NoSQL API, typicky napr. UoW. Ale to len tak btw.

fuzzy

Žádného ideálního nepřítele si nevytvářím – nemám nic proti RDBMS, NoSQL a v podstatě ani ORM jako takovému. Skutečně nevím co bych tím získal, snad vyjma falešného pocitu že moje cesta je ta jediná správná.

Ano, je to nekonečná debata, a IMHO jen tak neskončí. Pokud vás unavuje, není nic jednoduššího než ji ignorovat.

Máte pravdu v tom že ORM je víceméně sada návrhových vzorů s cílem řešit problémy s ukládáním objektů do relačních tabulek. Ano, u každého patternu by měla být věnována velká pozornost nejen tomu k čemu se hodí, ale zejména kdy to hapruje. Problém je že tyto nevýhody nejsou známy, resp. jsou zlehčovány atd.

Pokud tento článek, resp. diskuse která se pod ním rozpoutala, zvýší povědomí o úskalích a limitech ORM, leda dobře.

T

Viacmenej k tomuto prispevku vyhrady nemam. Snad len poznamenam, ze rovnako nie su stale zname dostatocne vyhody (vid. clanok). Lepsie diskutovat kedy(aky scenar) ORM pouzit/nepouzit ako pisat clanky s nadpisom „ORM = anitpattern“ bez akejkolvek hodnoty pre rozhodovanie niekoho, kto ma menej skusenosti a hlada odpovede. Posobi to presne opacne.

Nevyhody patternov popisuje pekne napr. Fowler.(napr.v PoEAA je vacsina tych ktore vyuzivaju sofistikovanejsie ORM spolu s nevyhodami)
Tiez je vhodne poznamenat, ze na niektore akoze uskalia existuju aj odpovede, ale trochu ine ako – „ORM je antipattern a podme pisat inline selecty alebo procky alebo pouzime NoSQL“.

fuzzy

Nerozumím tomu proč by neměly být známy výhody ORM? Myslíte že jsou nějaké dosud neznámé výhody které ORM přináší? Nebo tak že jedna strana nezná výhody ORM a tudíž ORM zatracuje, zatímco druhá strana nezná nevýhody a tudíž ho používá i na místech kde se to nehodí? No, tak to prostě je …

As NoSQL – troufám si tvrdit že nikdo soudný nepovažuje NoSQL za náhradu relačních databází. Rozhodně je ale mnoho situací kde je použití relačního úložiště nevhodné z toho prostého důvodu že data nejsou relační povahy, a sem vesměs patří i situace kdy je třeba ukládat objekty. Je-li někdo nucen používat relační databázi (např. proto že to zákazník chce nebo proto že je masochista), použije ORM. Ostatní použijí vhodnější uložiště které nějak lépe vyhovuje danému typu dat.

Nehledě na to že mnoho z nás bylo učeno „myslet relačně“ – jsme učeni od začátku na vyvíjený systém pohlížet jako na relační, často nám úplně uniká že to třeba jde namodelovat i jinak.

T

Ta druha interpretacia. Suhlasim, ale urcite sa to neda zovseobecnit tak, ze by neexistovali technologovia, ktori citlivo vedia volit spravny pristup v kontexte poziadaviek kontretneho projektu. Je tu vsak skupina ludi, ktori nemaju dost skusenosti a cakaju radu skusenejsich. Bohuzial, ako to pozorujem, flame clanky ako je bohuzial aj tento zacinaju valcovat tie vecne a ludia sa skor rozhoduju skor na zaklade toho ako byt „cool“ a nie na zaklade jasnej vizie prinosu pre ich projekty.

Ja osobne si myslim, ze „tvrdo“ relacne databazy alebo skor pristupy su nahraditelne na vacsine projektov, aspon od cias co som zacal uvazovat o aggregatoch pri navrhu domain modelu.
Druha vec, NoSQL – prilis siroka oblast. Aj existujuce RDBMS maju velke mnozstvo „NoSQL“ vlastnosti. Dalej…jedna vec je diskusia o mapovani a perzistencii, druha vec o moznostiach skalovania pri queryovani. Toto je fakt diskusia na dlho a svoj nazor sem nedokazem vtesnat, ale mam pocit z tychto prispevkov, ze by sme nasli v mnohom spolocnu rec.

Ano. Mysliet nerelacne a mat pod zadkom relacnu db znama(lo) vela trapenia, nastastie existuju mudri ludia, od ktori sa s tym vedeli vysporiadat.(a ta odpoved nemusi byt nutne NoSQL)

georgiksk

Pekný článok a dobrý námet na úvahu.

Nemyslím si, že by sa jednalo o antipattern.

Antipatterny sú podľa mňa prípady ako: nadužívanie singletonov, nesprávne použitie ORM, zapečenie 20x vnoreného innerjoinu do stredu aplikácie, synchrónne čakanie na odpoveď zo servera v JavaScriptovej aplikácii.

ORM samo o sebe nie je dobré ani zlé. Prináša výhody a za tie sa platí. To aj v prípade, že máte softvér zadarmo.

Vývojár by sa nemal báť SQL. Mal by dokázať preveriť, či ORM pracuje správne a podľa jeho predstáv. V aute sa tiež občas kontroluje, či má olej a či z podvozku neodpadávajú kusy plechu.

Vývoj treba sledovať. Svet ORM a not ORM sa od seba učí. A hlavne neexistuje nič ako jedno správne ORM. Dokonca niekedy je vhodné vymeniť ORM vrstvu za inú.

fuzzy

No, ano i ne. Ten základní problém je že ORM slibuje bezbolestné propojení dvou koncepčně zcela odlišných světů (relačního a objektového), a to prostě udělat nejde. Bohužel OOP vývojáři si toto neuvědomují a namísto volby vhodné nerelační storage se nechají šikanovat ORM.

Z tohoto pohledu je ORM samo o sobě antipattern – vývojáři by se jeho použití měli spíše vyhýbat a používat ho jenom když je skutečně vhodné.

T

„ORM slibuje bezbolestné propojení dvou koncepčně zcela odlišných světů (relačního a objektového)“

kto toto tvrdi alebo este inak, je vhodne vobec na takomto tvrdeni stavat kritiku ORM? Asi nie, aspon pokial to ma zostat vo vecnej rovine.

„Z tohoto pohledu je ORM samo o sobě antipattern – vývojáři by se jeho použití měli spíše vyhýbat a používat ho jenom když je skutečně vhodné.“

Vyborne. Potom je antipattern kazdy pattern by default, lebo kazdy pattern ma svoje miesto pre pouzitie a hranice, kedy je ho nevhodne pouzit.
A ano, vtedy sa stava pattern anitpatternom. Ale to uz je trosku ine tvrdenie, vsak?.

fuzzy

Ano, máte pravdu že jsou případy kdy je použití ORM zcela validní a na místě. S tím jsem ale nepolemizoval a nezastávám názor že by se ORM mělo zakázat zákonem nebo tak něco.

Tvrdím jen že ORM je třeba používat uváženě (a průběžně sledovat jestli projektu stále prospívá, a pokud ne tak bez milosti zahodit). Problém je že většina vývojářů po ORM sahá bez reálné zkušenosti s DB a slibuje si od toho že se nebude muset „patlat“ s databází. A dokumentace a knihy k ORM je v tom bohužel podporují a mažou jim „med kolem huby.“

To má za důsledek že ORM se používá i na místech kde prostě smysl nedává, naopak má za následek více práce v pozdějších fázích vývoje.

T

Suhlasim, tu je problem pomenovany vystizne.

Abstrahovat od DB mozem, ale ak hovorime o abstrahovani mam na mysli napr. jazyk SQL resp. jeho klon. Ale zakladnym konceptom ako napr. concurrency/loc­kovanie/transac­tion isolation musim rozumiet a mat ich v malicku, musim vediet co sa deje ORM pod zadkom a kazdy skusenejsi programator tieto odpovede hlada.

Na obhajobu ORM knih. Nemyslim si, ze dobra kniha o dobrom ORM maze nieco okolo pusy, lebo ju zvacsa pisali kvalitni ludia, ktori vedia preco NH je a EF nie je pouzitelny na enterprise aplikacie. Na vyucovanie zakladnej DB problematiky tam nie je miesto.

Pravda je podla mna niekde uprostred. Najvacsi problem na ktorom si ludia vylamu zuby pri ORM a stoji ich najviac dodatocnych MD s narastajucim projektom je objektovy graf pri query dotazoch, ktory im zabija aplikaciu. Tomu sa vsak da predist. Odpovedou nie je ani hanenie ORM, ani tvrdenie, ze nevadi, ani glorifikovanie inych pristupov, ale praobycajne uvedmenie si faktu, ze Reporting a Domenova logika su dve oblasti so specifickymi poziadavkami a ze uplne v poriadku zvolit pre kazdu z tychto oblasti iny pristup a/alebo inu technologiu ci framework.
Takze popri ORM cez ktory sa riesia commandy mozem spokojne prevadzkovat NoSQL alebo SQL+View+Mapper alebo … na queryovanie. Tato vec je tu uz x rokov. V poslednych rokoch bola spopularizovana pod skratkou CQRS(query&command responsibility segregation)

fuzzy

Standardní kniha o ORM (ale netýká se to samozřejmě jen knih o ORM) má plus minus tuto myšlenkovou strukturu:

1) ukážeme relační model
2) demonstrujeme jak se k němu pracovalo postaru (ručně psané SQL přes JDBC)
3) popíšeme rozdíly mezi relačním a objektovým světem (nepovinná část)
4) popíšeme daný ORM nástroj
5) ukážeme jak krásně řeší problémy uvedené v bodech 1 až 3

Všimněte si že tam nikde není bod ve kterém by se vysvětlovalo jaké limity daný ORM nástroj nebo ORM obecně má. Pokud taková kniha existuje, nebo pokud to třeba někde v dokumentaci k Hibernate je, prosím o link.

Každopádně to je IMHO jedna z příčin problémů …

PS: Nerozumím jak jste myslel to „Takze popri ORM cez ktory sa riesia commandy mozem spokojne prevadzkovat NoSQL“? To jako že mám dvě databáze – jednu relační a jednu NoSQL se stejnými daty? Není to trochu perverze?

T

„limity ORM“

to zazlievam aj microsoftu v suvislosti s EF, ze tie podstatne limity, ktore su tam napr. oproti NH nekomunikuju. Druha vec, ze vacsina ludi to ani nezisti, pretoze ich niektore veci netrapili ani pri vyvoji priamo na RDBMS.

co sa tyka linky, myslim, ze napr. tato je uplne OK.
http://www.amazon.com/NHibernate-3-0-Cookbook-Jason-Dentler/dp/184951304X

A.d. PS: Ano, presne tak. (rovnaku filozofiu mozem aplikovat ale aj pri jednej napr. relacnej DB).
Perverznost je to na malych projektoch. Na velkych je to jediny sposob ako okabatit CAP theoremu teda napr. nemusiet mavnut rukou nad C a zaroven moct profitovat z NoSQL pri reportingu.

vid. napr.
http://cqrsinfo.com/video/
(tu ide naozaj ale najvyssiu formu CQRS, existuju aj medzistupne, ktore sa daju prisposobit specifikam projektu)

Jirka Hradil

Tomasi, naprosto souhlasim. ORM je vrstva NAD SQL, nikoli jeji nahrada. Moje zkusenost bohuzel ukazuji, ze kdo chce pouzivat ORM efektivne a na bezne slozite, dlouho udrzitelne projekty, proste musi znat SQL a to tak, ze velmi dobre. ORM efektivni dotazy nenavrhne. Dobre mu jde treba SELECT * FROM table WHERE id=1, ale vice joinu, subselecty, apod. jsou casto potiz. Casto se to dohani v mnozstvi dotazu – na kazdy objekt samostatny dotaz a pak to ORM spojuje vnitrne dohromady. A je sakra rozdil, jestli na jednu web stranku poslu do DB 1 nebo 30 dotazu. Pri 1 userovi se rozdil nepozna, ale stovky podobnych uzivatelu a server jde do kytek. Aby taky ne.

Perfektni znalost SQL da vyvojari obrovskou silu. Zamknuti se nad 1 konkretni ORM implementaci je moc riskantni a omezene. SQL pouzijete vzdy, kdyz je projekt nad relacni databazi. ORM obcas, kdyz ma smysl. Nikoli vzdy. Pro me bude ORM „nice-to-have“, pokud ma smysl, nikoli „must-have“.

Osobne se mi z Javy libi treba iBatis nebo proste JDBC template Springu, tam je vse pod kontrolou. JPA povazuji za prilis slozite a treba systemy rizeni transakci jsou v nem peklo.

Shnuti: kdo chce dobre pouzit ORM, necht zacne studiem SQL :)

Jinak diky za prispevky, clovek se i v techto diskuzich stava lepsim a premysli jinak.

Jirka Hradil

A jeste bych chtel dodat, ze treba Hibernate je slozitej jako prase :).

Opravdový odborník :-)

:-D na webiki to holt není

Jiří Knesl

Přijde mi úsměvně tvrdit: „protože ukládáme celé objekty, je dobré použít key-value storage“. To je přeci nesmysl, když chci uložit OBJEKT, měl bych použít OBJEKTovou databázi, ne DOKUMENTovou databázi (která z principu není o nic vhodnější a trpí stejnými neduhy, jako SQL realizované Active Recordem).

Jinak si troufnu říct, že objektově-relační mapování v případě použití relační databáze smysl má. A od Data Mapperu výše odpadá velké množství argumentů proti – kromě úspornosti SQL dotazů

Filip Procházka

Což jde všechno optimalizovat, jenom si člověk musí trošku vyhrnout rukávy a optimalizovat si dotazy na databázi :)

Ivan

Popravde receno management velkych firem vubec nezajima jakou databazi a jaky pristup pouzijete. Pro ne jsou dulezitejsi „data“ nez samotna databaze. Znate nejakou objektovou, key-value nebo NoSQL databazi, ktera ma ochranu dat na stejne urovni jako ty klasicke „stare“ SQL databaze?
A to je duvod proc tu mame ORM. Programatori chteji myslet objektove, ale zatim tu neni zadna duveryhodna objektova databaze.

PS: vyvedte me z omylu jestli jsem vedle.

anon

couchdb je append only, crash-safe a s offline replikaci.

ma to samozrejme drasticky dopad na vykon (db nevhodna k mnozstvi zapisu) ale troufam si tvrdit ze toto je jediny mozny pristup jak zajistit totalni integritu, narozdil od schemat kde se pri update mohou nejaka data prepsat.

psani dotazu v couch je naprosty ulet takze takova db je opravdu vhodna jen tam kde se vyuzije vyse uvedene.

T

Kazda z NoSQL databaz ma svoje specifika. Ale vo vseobecnosti sa da myslim povedat, ze sila NoSQL je hlavne v Queryovani(a v skalovatelnostou s nim spojenou) a „statickych dotazoch“.(vopred sa da stanovit deterministicka mnozina indexovych paramterov).
Samozrejme aj tu existuju rozne moznosti, ktore jednotlive NoSQL DB ponukaju.
A este dalsia vec je CAP, ktora sa da okabatit jedinym moznym sposobom, separaciou casti aplikacie: C+(P a A) vs. P+A

Palo

Len aby bolo jasne, suhlasim s tym co si napisal. Existuje ale jedna velmi slusna objektova databaza. http://www.versant.com/
Pouziva sa to rozne, od embedded po velke systemy. My sme na tom stavali burzovy system. Ma to vela vtipnych vlastnosti.

fuzzy

Těch použitelných objektových databází je víc, např. Caché nebo Matisse.

blizz

vačšina OODBMS podporuje aj dotazovanie pomocou SQL

jay

Autor sice používá termín ORM, ale ve skutečnosti píše o nějakém framworku, který ORM implementuje.
Pak se mu lehce stane, že jeho předposlední doporučení jak to dělat jinak, je vlastně ORM. Sice ad-hoc a vlastními silami, ale je to mapování objektů na relace.

estonto

…když začnete načítat tisíce záznamů najednou, každý _S_ 30 sloupci…

lzap

Pěkný článek, dobře shrnuto.

Jen malý dodatek. Pro jeden RoR projekt jsme zvolili NoSQL databázi (MongoDB) a použili plugin pro mapování ActiveRecordu do této databáze. Ukázalo se to jako velmi nešťastné, či přímo tragické. Někdy v pátem sprintu jsme to celé přepsali do SQL. Mapování NoSQL databází přes ORM je ještě horší, než to co tady Martin popisuje. Spoustu omezení, dvě naprosto odlišné architektury (např. NoSQL obvykle neřeší závislosti).

Takže k těm pravidlům bych přidal toto:

1) Dobře se rozmyslete, pokud vám SQL opravdu stačit nebude. Přechod k NoSQL bolí a přijdete o mnoho funkcí. Třeba je nepotřebujete, ale dobře se zamyslete!

2) Pokud NoSQL, tak pouze „čistou“ formou. Tzn. žádné ORM pluginy, ale čistá komunikace s databází (např. přes JSON). Připravte se na to, že spoustu věcí si budete „dělat sami“.

tiso

Takéto „moudra“ z praxe sú veľmi prínosné, nechcete to rozpísať? Myslím, že zdroják by taký článok bral všetkými desiatimi.

Opravdový odborník :-)

Ad „Dobře se rozmyslete, pokud vám SQL opravdu stačit nebude. Přechod k NoSQL bolí a přijdete o mnoho funkcí. Třeba je nepotřebujete, ale dobře se zamyslete!“

Bingo. Konečně to lidem začíná docházet a místo fanatického obdivování noSQL začínají přemýšlet. Jen si nekteří musí nejdřív nabít kokos :-)

Čelo

Jen fanatický odpůrce NoSQL či „Opravdový odborník“ neviděl, že téměř u každého článku o NoSQL psali, že není pro každého a všelék na každou situaci.

Karel Minařík

A není možné, že jste si jen neudělali dostatečný průzkum, a že to, hrubě řečeno, prostě jen dost neumíte?

Protože např. s MongoDB v Rails je _hodně_ lidí na světě naprosto spokojeno.

Technická poznámka: věřím, že jste použili „plugin“ pro „mapování“ _ActiveModel_ do „této databáze“, tedy MongoMapper nebo MongoID.

Přechod k NoSQL samozřejmě „bolí“, stejně jako bolí jakýkoliv jiný přechod k nové technologii, stěhování do nového bytu, apod. Nechápu, proč je nutné tato „moudra“ pořád do zblbnutí opakovat.

Opravdový odborník :-)

A proč je nutné jim do zblbnutí opakovat, ať jdou do cloudu a do noSQL?

Koukáte na to ze špatné strany. Lidi halt mají tu vlastnost, že když objeví něco co se jim líbí a řeší jim to problémy, tak o tom vykládají ostatním.

To _pochopitelně_ neznamená, že Cloud/NoSQL/Ra­ils/Node.js/Atd je nějaká spása lidstva a stříbrná kulka. To nikdo soudný neříká. Jen jsou podobné věci prostě o několik délek napřed.

Debata jestli „jít do cloudu a do noSQL“ je každopádně bezpředmětná — spousta lidí už tam prostě „je“ a vůbec se s vámi na téhle úrovni bavit nebude.

Palo

To je tiez pekne, nech si chvalia svoje. Preco ale citatia potrebu ocikat susedove (ORM). Alebo si cital iny clanok ako ja?

Jirka Hradil

Protoze my, webovi vyvojari budeme casem v cloudu vsichni a hezky na nejake KV databazi :). Tohle neni buzz, to je proste jasny trend. Rozumni uz migruji ted, zbytek je zamceny v chaloupce a libuje si, jak neslysi auta venku. Staci si precist neco o nosql, nejlepe primo od autoru, dobre jsou diskuze treba couchdb vs mongo db, pak reseni, ktere ma rackspace, amazon, heroku, jejich pluginy pro nosql. Staci otevrit oci, budoucnost je jasne videt.

Prekazky nasazeni relacni db do cloudu jsou jasne, vyhody/nevyhody nosql databazi take. To tady snad nemusime omylat. Jak tady ale nekde uvedl Karel Minarik, spousta lidi to proste uz dnes pouziva a ti sem psat nebudou, protoze jim tyto diskuze musi pripadat naprosto smesne. Oni vi, oni znaji a nemaji potrebu to prosazovat. Souhlasim s Karlem, ja sam zasnu, jak mala vzdelanostni uroven se tady vystavuje na obdiv. Vyvojar musi studovat a nasavat trendy jako houba. Vsechny.

blizz

súhlasím s palom.

a hovor za seba nie za webových vývojarov. tomu čo ty nazývaš trend tomu sa ľudovo hovorí ľudská hlúposť. niektorým ľuďom evidentne chýba kritické myslenie, niektorí webový „vývojari“ stále nechápu že sú len obete marketingu veľkých firiem.

v6ak

Rozumní použijí to, co se na daný úkol hodí lépe. Jakkoli NoSQL přináší svoje výhody, ne ve všech případech převáží nad nevýhodama.

Jinak, ono jde za určitých podmínek škálovat i s relačními DB, jen ne tolik automaticky. Ale v některých specifických případech se to může hodit.

T

Cely problem je v tom, ze ludia sa nechaju strnut vlnou NoSQL skor, ako pochopia na co a kedy je vhodne, naucia sa uvazovat inak ako relacne a potom vznikaju taketo rozcarovania.

BurgetR

Zajímavý názor, ale takhle je to jenom nepodložený názor. Nebo pokud je podložený, tak nevíme čím. Například by bylo zajímavé vědět, v jakém konkrétním případě si autor myslí, že mu ORM nestačí a že musí „sestoupit“ dolů k SQL. Nemůže to být špatným návrhem? Nezhoršuje tím výkonnost tím, že nenechá ORM framework dělat pořádně jeho práci?

Seriózní frameworky jako Hibernate nebo DataNucleus (a snad i další) mají na webu benchmarky, které ukazují, že za určitých okolností může výkonnost oproti SQL vzrůst (framework může cachovat, optimalizovat, atd.) Je tam napsáno kdy a co je proto třeba udělat. Nastudoval to autor? Pokud ano, proč nám neřekne, v čem je problém? Lžou snad ty benchmarky?

Takových nepodložených tvrzení je tam spousta. Dalo by se polemizovat s každým odstavcem. Takový článek ve stylu „já si myslím, že je to takhle“ může napsat každý. Otázka je proč se zrovna tímto pánem zabývat :-)

Palo

Suhlasim. Nerozumiem ako sa nieco taketo moze dostat medzi clanky. Prinasa nazor takze asi by to malo ist na BLOG a naviac jeho nazory nie su nicim podlozene mozno az na hrane jednoduchej vyvratitelnosti faktami.

logik

Benchmarky jsou často postavený tak, aby vyzdvyhly to, co dělá framework dobře. Cacheování může výkon přinýst, ale pokud člověk nepotřebuje jeden objekt několikrát, je to jen další zpomalení navíc.

Největším neduhem ORM modelů je to, že skládaj dotazy „jedním způsobem“, kterej nemusí bejt vždy efektivní. Jsou dobré, pokud potřebuješ objekt daného ID apod. Horší už, pokud potřebuješ hromadu objektů vyhovující nějakému složitějšímu kritériu.

Opravdový odborník :-)

V opravdovém ORM si můžete v případě potřeby definovat vlastní SQL dotazy a použít je místo těch výchozích, pokud vám nevyhovují — ale když vám stačí „default“ (což většinou je) tak ORM ušetří celkem dost práce.

Palo

> Největším neduhem ORM modelů je to, že skládaj dotazy „jedním způsobem“
Tak neviem co pouzivate vy ale v hibernate si to dokazem celkom slusne nastavit a optimalizovat, aj pre AD-HOC dotazy. Samozrejme NamedQuery mate vzdy po ruke ked citite potrebu „super“ optimalizacie.

fuzzy

No, moje zkušenost je že většina SQL dotazů které padají z ORM jsou výrazně koplikovaněji formulované než dotazy které bych napsal ručně. Což ve svém důsledku výrazně komplikuje práci plánovači v databázi, a nezřídka to vede k dost strašidelným exekučním plánům.

NamedQuery samozřejmě k dispozici je, ale to už od vývojářů vyžadujete obcházení abstrakce kterou jim ORM slibuje.

T

„ale pokud člověk nepotřebuje jeden objekt několikrát“

Spravna otazka je, ci su situacie, kedy moze byt 2nd cache zbytocna / kontraproduktivna. Samozrejme. Napr. pri reportingu v pripade, ak mame jedno silne zelezo s RDBMS a nevieme s tym nic robit a na 2nd cache farmu nam dalsie zeleza nikto neda.
Vtedy je vacsina infrastruktury okrem mapovania z ORM zbytocna(v pripade query dotazov). Ale to neznamena, ze tato cast funkcionality ORM sa neda pekne pouzit a ulahcit si zivot.
Rovnako je zbytocna 2nd cachce ak si vytvorim samostatnu reportovaciu DB postavenu napr. na NoSQL a nadupanej rdbms riesim stav s dorazom na consistancy.

fuzzy

No, jedná se o zajímavý post člověka který o dané problematice dost ví (i když s ním nemusíte souhlasit). A nikde není psáno že v článcích na rootu nemohou být publikovány texty s nějakým názorem.

BurgetR

Moje kritika ale právě směřovala k tomu, že ten názor má být podložený. Většina toho, co ten pán tvrdí je pravda jen za určitých okolností, o těch ale taktně mlčí. Takže je možné, že o tom dost ví, ale neříká nám všechno, nebo o tom moc neví a o to víc píše. Ale pokud má být sdělením, že pan Voss je z použití ORM ve svém projektu zklamaný, pak v pořádku, dobře podáno :-)

fuzzy

To máte určitě pravdu, já také nesouhlasím s některými jeho tvrzeními, nicméně on tam uvádí proč je ten článek záměrně tak stručný. Já jen nesouhlasím s tím že by v článcích neměly být

Jirka Hradil

On je totiz Palo velky rozdíl sednout si a napsat takovej clanek nebo jenom remcat v diskuzi a divit se „jak to muze vzniknout“. Nic jako objektivita neexistuje. Nikde.

Autorovi clanku dekuji, dobry a kvalitni pohled na vec.

Opravdový odborník :-)

+1

ORM není všelék, mnohde jeho použití nedává smysl. Ale takhle obecně ho zavrhovat je hlupáctví (a/nebo bulvár).

fuzzy

Tak polemizovat se o tvrzeních určitě dá, také nesouhlasím 100% se vším co je tam napsáno. Každopádně benchmarky uváděné na stránkách jednotlivých frameworků jsou asi stejně spolehlivé jako statistiky prezentované politiky v Otázkách Václava Moravce.

Ondra

Asi nejjednodušším příkladem, kdy se ORM naprosto nehodí, jsou hromadné aktualizace dat nebo hromadné operace nad daty vůbec. Představme si jednoduchou tabulku o stovkách tisíc záznamů, kde máme u všech záznamů zvýšit hodnotu jediné položky o 1. Dělat to přes ORM, tak i samotná komunikace klient-server bude mít za následek mnohonásobně větší výkonovou režii (na obou stranách) než prostý „update tabulka set hodnota=hodnota+1“. A to jsem tu velikost tabulky nadsadil, ve spoustě případů by se ten rozdíl nejspíš viditelně projevil už na pouhých několika stech záznamů. Různé ORM frameworky se toto snaží optimalizovat např. pomocí dávkového zpracování, ale to je pouhá berlička, která na principiální neefektivitě takového přístupu nic nemění.

Problém ORM je v tom, že se často používá i v silně datově nebo dokonce statisticky orientovaných aplikacích, místo aby sloužil pouze jako vrstva zajišťující persistenci objektů. Bohužel v celé řadě aplikací se hodí obojí přístup, takže pak vznikají různá hybridní řešení, která pochopitelně bývají velmi křehká a špatně udržovatelná.

Trochu to tady nakousl už někdo jiný, toto totiž není jen problém ORM, ale problém objektového přístupu obecně. Pro systémy, ve kterých se primárně řeší netriviální chování nějakých objektů ve vzájemné interakci, je objektový přístup skutečně optimální. Ovšem v různých evidenčních systémech, kde hraje zásadní roli statická (datová) složka, nikoli dynamické chování, je použití objektů spíše k zlosti. Ovšem jak už jsem uvedl výše, svět není černobílý a většina systémů se pohybuje někde mezi těmito extrémy.

Jaro

Veď hibernate/jpa má takisto HQL/JPQL Update query. Ten sa vám rovno vygeneruje ekvivalentný SQL dotaz, tak aká réžia navyše?

Ondra

Hm, problém je v tom, že JPQL je spíše přílepek ke koncepci ORM, který se snaží řešit jmenované nedostatky ORM. Fakticky je tahle potřeba vytvářet jazyk obdobný SQL spíše demonstrací nedostatečnosti ORM.

Palo

Toto je clanok plny absolutnych nezmyslov. Co by sme si mali objekty serializovat rovno na disk? Naco nam je databaza?

– NoSQL zabudnite, to iste viete urobit aj v SQL, ci si natahujete vsetky stlpce aj tie ktore nepotrebujete z SQL alebo NoSQL nema to ziadne vyhody/nevyhody. Vacsina NoSQL databaz ma problemy z transakciami. Ak je dat malo a databaza mala tak mozte pouzit SQL ak je velka robite si zbytocne problemy. Ako raz niekto napisal, vymenite sadu znamych problemov za sadu neznamych problemov.

– Kazdy pokrocily framework podporuje lazy/eager fetch, dokonca sa da nastavit pre kazdy pripad dotazu inac

– Hromadne operacie sa samozrejme daju robit aj OR framework ale na co. Vtedy treba pouzit hromadny update. Na to skutocne OR frameworky neboli vymyslene

– Framework vas ochrani od SQL injection.

– Pokrocile ORM frameworky su velmi efektivne pri vyberani a ukladani udajov do SQL

– Pre velke aplikacie mozete pouzit 2nd level object cache (aj clustrovanu)

– Framework vam zefektivni pracu. Ak to neviete pouzivat je lepsie naucit sa to poriadne ako robit to rucne. Usetrite si mnozstvo prace neskor napriklad pri implementovani security pripadne inych ‚cross‘ aspektov (AOP).

– Naucit sa zopar trikov ako entita nad view, viacero entit nad rovnakou tabulkou, paging, lazy loading, …, treba si najst ten spravny framework a generator.

Vsetko je otazka pohladu ale takto hnusne ovracat ORM frameworky som fakt este nevidel. Niektore nazory su OK. Pouzitie objektovych databaz by bolo fajn keby nas neobmedzovali zakaznici (oni uz kupili Oracle, Informix, …). Aj ja by som si rad vsetko vytunil a pisal dotazy a updaty rucne ale zakaznik to chce „rychle a levne“. Pritom to musi splnat vsetky kriteria pre enterprise – clustering, load-balancing, 24×7, 99.9% dostupnost, … a pritom konkurujete vselijakym potmehutom z PHPckom ktory slubia hocico za hocikolko. Preto potrebujeme frameworky, generatory, ORM aby sme boli EFEKTIVNEJSI pri zvyseni narokov na znalosti. Ak ale tie znalosti a prax nemate framework vam nepomoze iba vas bude brzdit.

Palo

A este som zabudol na jeden VELMI dolezity fakt. ORM framework vam umozni prakticky s nulovym usilim zmenit cielovu databazu. Z MySQL na PostgreSQL, Oracle alebo MS-SQL podla toho co zakaznik ma alebo na co ma. Dalsi level slobody a kludu pre architekta.
Vase vytunene dotazy pre MySQL moc dobre nad Oracle asi nepobezia.

logik

Pokud někdo používá mysql, tak to může rovnou nosql (noflame). Kompatibilita Oracle a postgresu je poměrně dosti dobrá.

Ale hlavně: pokud se při vývoji produktu neumíš kvalifikovaně rozhodnout, kterou db použít…

„Multiplatfor­mností“ musíš oželet veškeré takové věci jako CTE apod, který někdy dokážou s minimem práce to, co na aplikační úrovni zabere hafo času, o
triggerech, stored procedurách atd. nemluvě. Multiplatformita je dobrá věc, ale jako každá dobrá věc něco stojí.

Palo

Myslim ze medzi NoSQL a MySQL je stale DOOOST velky rozdiel. A ak nie je preco potom NoSQL vznikli.

Ale preco nepouzit to co je treba? Pouzivame ORM, pouziva batchove davky, ulozene procedury, objektove databazy, report engine bezi priamo cez SQL do DB nie cez ORM vrstvu, … . Miliony nastrojov, miliony vyhod, miliony nevyhod. Treba sa naucit chut kazdej ingrediencie a da sa z toho urobit skvela polievka. Ja som reagoval na to ze vyhodit ORM ako nechutnu prichut je uplna hlupost. Ma to svoje miesto a dost podstatne a velke.

logik

Tady ale tvrdíš něco jinýho, než v předchozim postu: tam jsi tvrdil např, že používání ORM Ti dovolí změnit databázi. Nedovolí, když tam máš vedle uložený procedury.

Samozřejmě, na konkrétní přístup (zobrazení objektu z db) se ORM přístup hodí. Jenže v okamžikum, kdy danou funkci voláš ještě z dávky, budeš ji psát dvakrát? No asi ne. Takže kontroly a podobný věci stejně implementuješ na DB úrovni.
Takže ve výsledku Ti takhle ze silného ORM zbyde vrstva na čtení a ukládání dat, jako je třeba Vránova NotORM….

Já netvrdím, že ORM je na nic – má své místo jako každá jiná technologie. Jen ale většina argumentů, které jste pro ORM uvedl má své silné zápory a tedy ORM se hodí daleko méně, než na první pohled vypadá. A i o tom byl právě tendle článek. Možná trochu kontroverzněji napsaný, ale v jádru pravdivý.

fuzzy

Jednodušší změna databáze je v drtivé většině případů (99.999999%) zcela k ničemu. Databáze je vesměs jasně daná na začátku vývoje a zákazník produkt chápe jako celek a rozhodně nechce otestovaný systém migrovat mezi databázemi.

Výjimkou jsou balíkové produkty vyvíjené pro nasazení na více databázích.

Opravdový odborník :-)

Ona to není výjimka, ale spíš pravidlo ;-) Navíc spousta softwaru „na míru“ staví na nečem už hotovém — dodavatel má nějaký společný základ nebo framework a přizpůsobuje ho jednotlivým zákazníkům. Takže ta možnost běžet nad různými DBMS není vůbec od věci — někde mají Oracle, jinde DB/2 nebo PostgreSQL… a to jim člověk nerozmluví (museli by platit dalšího admina na jiný druh databáze, nemluvě o tom, že někdy jsou ty databáze draze licencované).

fuzzy

No, ono to dost závisí na tom v jaké oblasti se pohybujete. Pokud máte systém který jen customizujete jednotlivým zákazníkům, tak to samozřejmě spadá pod tu výjimku.

Ale pokud vyvíjíte sw „na klíč“ pro konkrétního zákazníka, tak aby to odpovídalo jeho infrastruktuře, DB kterou už má koupenou apod. tak je „portabilita na jinou DB“ nesmysl.

Jirka Hradil

Jo bratre, jakmile budes prechazet do cloudu, tak s relacnima db narazis :). Blbe se totiz horizontalne skaluji. No-sql je nejenom trend, ale must-have. BTW dostupnost 3 devitky je nic moc :).

Opravdový odborník :-)

LOL, tahle věta mne dostala:

„Jo bratre, jakmile budes prechazet do cloudu“

Palo

Cely cloud je ftakovina, aplikacii ktore to realne potrebuju je v nasom svete MINIMUM ale nechajme to tak.
Aku aplikaciu prave vyvijate ktora si vyzaduje horizontalne skalovanu DB? Taku tu ze ferko napisal anicke? My musime aj kontrolovat zavislosti, auditovat, spustat ulozene procedury. A to v limitovanom prostredi. Cloud DB nie je svaty gral uloziska. V oblasti aplikacii s tebou suhlasim.

Jirka Hradil

Nez se k necemu vyjadrim, tak si to alespon nastuduju ;). Zacni treba timto a vrat se za tyden: http://www.manning.com/rosenberg/

Palo

Dalsi magor co si precita knihu a mysli si ze je v nej mudro sveta. Daj fakty, poucky si nechaj pre kamaratov.

Jirka Hradil

Kdyby to byla jen jedna. Bratri, nejste tady dneska nejaci drzi a agresivni? :)

Palo

Na takych samozvanych geniov co nevedia diskutovat a ked nemaju co povedat zacnu utocit na diskutujuceho namiesto prednasania faktov a vysvetlovania?
Na takych ja mam zrychlenie 0 na 100 do 0.004 sekundy.

fuzzy

No, já zase „nemusím“ diskutující kteří si o všem s čím nesouhlasí myslí že je to prákovina …

Ondra
fuzzy

+1

Tak nevím jestli ten co dělá „blah blah blah“ jsem já, nicméně Dilberta mám rád takže díky.

fuzzy

Jasně, celý svět se mýlí jenom vy máte pravdu. Neříkám že cloud do velké míry není hype (která technologie nebyla?), nicméně svou logiku v mnoha případech má.

Ne, cloud skutečně není potřeba pro všechny aplikace – to ale p. Hradil nenapsal takže polemizujete s něčím co nikdo netvrdil. Jediné co padlo bylo „pokud budete potřebovat přejít do cloudu, s relačními DB narazíte,“ a to je prostě pravda.

Ale samozřejmě si můžete vertikálně škálovat a škálovat svůj server, až jednou budete mít největší server ve vesmíru.

Palo

Fajn takze sa zhodneme ze je to hype. Kde je podla vas hranica ze sa oplati robit aplikaciu pre cloud pretoze dnes to znamena zvyseny effort na strane programatora.
Od akeho objemu dat uz nestaci relacna databaza?
Aky druh cloudu? Relacna databaza nemoze bezat v cloude?

> jednou budete mít největší server ve vesmíru
A co vlastnit najvacsi cloud je lepsie? Su proste data ktore do public cloudu dat nemozte. Neviem cim to je ale ja ine data ani nepoznam, aplikacie ferko napisal anicke netvorim.

fuzzy

Psal jsem že aktuálně kolem cloudu hype, nikoliv že cloud nemá opodstatnění. A už vůbec jsem nepsal že by citlivá firemní data patřila na public cloud. Pro dakové účely existuje i cosi jako private cloud.

> Od akeho objemu dat uz nestaci relacna databaza?
Rozhodovat zda relační databáze „stačí či nestačí“ podle objemu dat je dost nesmysl. Záleží na kombinaci dalších faktorů jako je počet uživatelů, jak se s daty pracuje apod. Můžu mít na disku 1TB dat a v pohodě to zvládne desktop, můžu mít 10 GB dat a nezvládne to ani nabušený server.

> Relacna databaza nemoze bezat v cloude?
Relační databáze v cloudu samozřejmě běžet může, ovšem nic moc vám to nepřinese. Problém je v tom že jedním z důvodů přechodu do cloudu je jednodušší provoz více mašin a možnost distribuce zátěže. Bohužel relační databáze na to nejsou stavěny (drží se silné konzistence, takže by se musely vzdát dostupnosti nebo výkonu – viz. CAP). No a právě tady přichází NoSQL databáze které naopak uvolňují konzistenci a snaží se držet výkon a dostupnost.

> A co vlastnit najvacsi cloud je lepsie?
Platí standardní pravidlo že cena hardwaru roste exponencielně s výkonem. Tj. když chci 2x výkonnější server, zaplatím např. 4x víc. Distribucí na menší mašiny můžete ušetřit nemalé peníze, no a cloud vám provoz těchto menších mašin výrazně zjednodušuje. Takže to že půjdete do cloudu neznamená že tam máte budovat jednu obří virtuální mašinu (ostatně i tam platí že cena roste exponencielně, i když ne tak dramaticky).

Palo

> můžu mít 10 GB dat a nezvládne to ani nabušený server
Nie je to podla objemu ale 10GB snad neeeeee. To sa potom stala chyba niekde inde.

> Relační databáze v cloudu samozřejmě běžet může, ovšem nic moc vám to nepřinese
Takze cloud nijako nesuvisi s ORM, NoSQL, … je to uplne iny topic. A preco by som tim nic neziskal? Ziskam vyhody cloudu.

> Distribucí na menší mašiny můžete ušetřit nemalé peníze
ORM typicky bezi na aplikacnej vrstve, to sa da do cloudu pekne nasadit. DB mozete mat viac, mame techniky ako message bus, EDA, CQRS ktore budu bezat aj v cloude nad relacnou DB.

Mame miliony problemov a miliony rieseni. Neviem preco sa stale miesa cloud, NoSQL, efektivita. Kazde z tohto je separatny topic a daju sa navzajom kombinovat.
Zvlastne ako menite nazor. Este pred chvilou to bolo ze s relacnou databazou v cloude narazim teraz ze to nema vyhody tipujem ze za chvilu nejake najdeme.
A tipujem ze najdeme aj pripady kedy NoSQL databaza beziaca v cloude je velmi solidny overkill. Obzvlast v privatnom cloude.

Nic nove som sa akosi nedozvedel. Aky velky projekt sa oplati vyvijat a udriavat na privatnom cloude na NoSQL databaze? Je vramci Slovenska, Ciech, Madarska, … taky? Verim ze Google by si s tym inac neporadil ale to je UUUPLNE nieco ine nez co bezne robime.

fuzzy

> Nie je to podla objemu ale 10GB snad neeeeee. To sa potom stala chyba niekde inde.
Ale to přeci hrozně závisí na tom co s těmi daty děláte. Můžete mít bottleneck na disku, na CPU, na paměti, … to fakt nejde říct tak že zpracovat 10GB dat není problém. Když to trochu přeženu, je to jako tvrdit že faktorizaci čísla s 1.000.000 číslic zvládne každý, protože to je jenom 2302585 bitů (280kB). Jasně, faktorizaci v DB asi moc neřešíte ale i tak jsou někdy nároky na CPU značné.

> Takze cloud nijako nesuvisi s ORM, NoSQL, … je to uplne iny topic. A preco by som tim nic neziskal? Ziskam vyhody cloudu.
To jsem ale netvrdil. To hlavní totiž bylo v druhé půlce věty resp. odstavce, kterou jste umazal. Tím že přenesete stroje do cloudu 1:1 skutečně nic moc nezískáte. Možná ušetříte za provoz, možná budete moci jednodušeji vertikálně škálovat. To co bodete moci dělat jen velmi obtížně je dynamické horizontální škálování, tj. distribuce zátěže na více strojů.

Ano, existují produkty které vám toto do jisté míry umožní i s RDBMS (např. různé formy replikace, clusterová řešení, statement-based proxy apod.) ale vesměs mají různá omezení. Např. dynamické přidávání nodů často není možné (tj. musíte restartnout celý cluster), apod.

Oproti tomu mnohé NoSQL databáze jsou na toto připraveny a přímo pro takovéto použití jsou navrženy (Cassandra, MongoDB, …). Ano, mají zase jiná omezení, to je pravda.

Netvrdím a nikdy jsem netvrdil že cloud nebo NoSQL jsou jediné správné řešení. Poněkud mi ale uniká proč bych měl živit komplexní řešení (aplikační vrstvu s ORM, message buses atd.) jenom proto abych simuloval něco co mi NoSQL databáze může poskytnout zdarma. A co samozřejmě přináší další nové problém – např. vertikální partitioning do více databází skutečně nechci dělat pokud to nebude nutné (mimo jiné se tím ztrácí silná konzistence, což je jedna ze silných stránek RDBMS).

Můj názor je že uložiště by se mělo vybírat na základě povahy dat. RDBMS pro relační data, KV stores a objektové DB pro objekty. Bohužel je to často tak že objekty se zbytečně cedí skrz ORM do relační databáze.

> Zvlastne ako menite nazor. Este pred chvilou to bolo ze s relacnou databazou v cloude narazim teraz ze to nema vyhody tipujem ze za chvilu nejake najdeme.

Prosím, nepodsouvejte mi něco co jsem neřekl. Od začátku tvrdím že RDBMS sice v cloudu běhat můžete, ale nebudete moci využít jeho výhody. Skutečně nevím co je na tom tak záhadného.

> Nic nove som sa akosi nedozvedel. Aky velky projekt sa oplati vyvijat a udriavat na privatnom cloude na NoSQL databaze? Je vramci Slovenska, Ciech, Madarska, … taky? Verim ze Google by si s tym inac neporadil ale to je UUUPLNE nieco ine nez co bezne robime.

Privátní cloud si může budovat i firma která má pár serverů, možná spíš pár desítek. Čímž se kvalifikuje většina bank, telco firem, apod.

Ladislav Thon

> drží se silné konzistence, takže by se musely vzdát dostupnosti nebo výkonu – viz. CAP

P není Performance, ale Partition tolerance. Děláte panu Brewerovi medvědí službu, víte o tom?

Opravdový odborník :-)

O tom to přeci je — lidi si chtějí přečíst nějakou jednoduchou poučku a bez přemýšlení ji pak opakovat v diskusích a vypadat hustě — je to přece cool a cloudy a vůbec fikulínské nosql a tak vůbec…

fuzzy

No, to jsou zajímavé konstrukce na základě jednoho, v rychlosti psaného, příspěvku, resp. chyby v něm …

fuzzy

Oooops, samozřejmě máte pravdu, má to být Partition Tolerance. Chybička se vloudila …

logik

Ne, tvuj příspěvek je plnej nesmyslů :-) (sory, nedalo mi to).

– ano, NoSQL má spoustu mínusů. Má jen jedno plus: oproti SQL je řádově rychlejší.

– pokud na hromadný update nepoužiješ ORM ale něco jiného, tak musíš hromadu věcí psát dvojnásobně (kontroly, různé závislosti atd…). Sám píšeš, že ORM ušetří práci při security atd – a proto ho obejdeš?

– second level cache je skvělá věc, když potřebuješ záznamy by id. Horší, když je potřebuješ dle různých kritérií.

– Pro ochranu od SQL injection potřebuji ORM? Uff

– existují i jiné „automatizované“ systémy než ORM (různé automatizované skládání dotazů apod), takže Tvé dilema ORM nebo ručně je mimo.

– last but not least: to, že někdo, kdo má jinej názor než ty ještě neznamená, že neumí používat ty všechny věci, cos psal. Jen třeba narozdíl od Tebe zjistil, že ne vždy jsou dostatečné…

Palo

> Má jen jedno plus: oproti SQL je řádově rychlejší
Ak potrebujes rychlost na ukor transakcnosti tak mozno ano. Niektore NoSQL databazy bezia nad SQL jadrami (MySQL), rychlejsie asi nebudu. Vyhoda bude skor niekde inde. MySQL sa da bezat bez transakcii a bude porovnatelne rychla ako NoSQL.

> pokud na hromadný update nepoužiješ ORM
To je reakcia na clanok, ak je to nevyhnutne tak to tak treba spravit updatovat miliony zaznamov jeden po druhom namiesto jedneho update je nezmysel. Ale aj to sa musi urobit spravne na konkretnom mieste.

> Pro ochranu od SQL injection potřebuji
Nie, mozes pouzit aj prezervativ, toto ale dostanes k ORM „zadarmo“, obzvlast vyhodne pre lamky ktore prave zacali kodovat

> Jen třeba narozdíl od Tebe zjistil, že ne vždy jsou dostatečné
Ale ja to viem a aj to tam pisem len to nechces vidiet. Otazka je coho je viac? Ci radsej pouzijem nieco co my pokryje 90% potrieb a ostatne urobim inac co znamena celkovo nizsie naklady na vyvoj alebo si budem aj tak robit vsetko rucne, krasne vytunujem ale za viac casu a penazi. Poviem len jedno, za poslednych N rokov sme nenapisali aplikaciu ktora by vyzadovala optimalizaciu lebo HW nestihal. Mozno nebola optimalne napisana, ale na dnesnom HW nebola ani pomala a bola lahko udrziavatelna.

Jirka Hradil

> Má jen jedno plus: oproti SQL je řádově rychlejší
Ak potrebujes rychlost na ukor transakcnosti tak mozno ano. Niektore NoSQL databazy bezia nad SQL jadrami (MySQL), rychlejsie asi nebudu. Vyhoda bude skor niekde inde. MySQL sa da bezat bez transakcii a bude porovnatelne rychla ako NoSQL.

JH: Ona se KV databaze a transakce vylucuji? Pripadne je takovy problem napsat aplikaci tak, aby ukladala vse potrebne jen jednim prikazem a pak transakcnost nepotrebujes? Podivej se, jak treba funguje zpracovani transakci v paypalu.

> Pro ochranu od SQL injection potřebuji
Nie, mozes pouzit aj prezervativ, toto ale dostanes k ORM „zadarmo“, obzvlast vyhodne pre lamky ktore prave zacali kodovat

JH: Kecy, Hibernate, Toplink nebo Active Record to podporuji, ale nikoli zadarmo. Musis presne vedet, co to sql-injection je a co znamena ona „ochrana“.

> Jen třeba narozdíl od Tebe zjistil, že ne vždy jsou dostatečné
Ale ja to viem a aj to tam pisem len to nechces vidiet. Otazka je coho je viac? Ci radsej pouzijem nieco co my pokryje 90% potrieb a ostatne urobim inac co znamena celkovo nizsie naklady na vyvoj alebo si budem aj tak robit vsetko rucne, krasne vytunujem ale za viac casu a penazi. Poviem len jedno, za poslednych N rokov sme nenapisali aplikaciu ktora by vyzadovala optimalizaciu lebo HW nestihal. Mozno nebola optimalne napisana, ale na dnesnom HW nebola ani pomala a bola lahko udrziavatelna.

JH: Jste dobri. Ale pokud pocet vasich uzivatelu prekroci 10, tak se tomu nevyhnete ;).

Palo

> JH: Ona se KV databaze a transakce vylucuji.
Nie len potom zrazu zacnu byt magicky pomale ako SQL co sa povazuje za ich hlavnu vyhodu. Pritom sa zabuda ze hlavnou vyhodou je ukladanie „nestrukturovanych“ udajov. To je samozrejme obcas treba ale obvykle nie. To je ten problem s NoSQL tak ako kedysi bolo s XML. Ludia si myslia ze je to dobre na vsetko.

> ukladala vse potrebne jen jednim prikazem a pak transakcnost nepotrebujes
Pokial viem tak ani len toto ti NoSQL povacsinou negarantuju.

> Musis presne vedet, co to sql-injection je a co znamena ona „ochrana“
Nemusis vediet nic. Poprosim o priklad niecoho v Hibernate alebo TopLink-u co by mohlo viest k SQL Injection.

> Ale pokud pocet vasich uzivatelu prekroci 10
My prevadzkujeme aplikacie kde je bezne 1.200 – 1.700 sessions.

Jirka Hradil

„Poprosim o priklad niecoho v Hibernate…“

Cokoli, co nepredas jako parametr, ale primo do dotazu:

http://www.google.cz/search?sourceid=chrome&ie=UTF-8&q=hibernate+sql+injection

Pak treba:

http://blog.harpoontech.com/2008/10/how-to-avoid-sql-injection-in-hibernate.html

Kazdopadne tim „nemusis vedet nic“ jsi to korunoval :).

Pouceni pro ostatni z komunikace s bratrem: „vzdy si zjistete, v cem programujete a nespolehejte se na nic. Ani na automatiku sql injection.“ :)

Palo

Presne toto som cakal a to je presne to kde sa vyhybas ORM. To ze si pouzil hibernate session na zavolanie JDBC query nie je ORM. A prave preto je lepsie pouzivat ORM a mapovanie lebo ked si to ludia robia sami tak to presne takto sprasia.

Jirka Hradil

ORM je mapovani objektu do relacni tabulek. Nic jineho. Zrejme mas na mysli nejaky QL, ktery tam je. Mrkni na Hibernate, co tam vsechno mas za metody a co musis brat v potaz. Hibernate neni silver bullet a nelze napsat „nemusis vedet nic“. Lama nepatra, lama pouzije prvni, co ji funguje a co je pravda pro tebe, je pro nekoho jineho strasne nebezpecne. Ty jsi borec, ale po precteni tveho prispevku nabyvam pocitu „v Hibernate neni nebezpecni sql injection“. Coz neni pravda. Je to o volani spravnych metod, nikoli o frameworku jako celku. Kazdopadne nezpochybnuji tvou velikost, zkusenosti, ani silu uderu ;).

Palo

Ano ale ty si ziadne ORM ktore umoznuje SQL injection neuviedol, alebo mi prosim uved kde v tom linkovanom texte to je lebo ja som to tam nenasiel. Ty si iba pouzil metodu z frameworku ktora ale z ORM nesuvisi. Uz sa zbytocne krutis. Slusny generator ti vygeneruje vsetko podla DDD paternov takze sa k hibernate session ani nedostanes. Nie to este nejaka lamka ako pises.
To co pises je presne prve co lamka urobi ked jej ORM neukazes a das jej iba JDBC. Takze je to presne naopak ako pises.

Opravdový odborník :-)

Ad „Cokoli, co nepredas jako parametr, ale primo do dotazu“

Pěkná demagogie. Když budu dotaz (ať už SQL nebo JPQL) lepit z textů od uživatele (útočníka), tak prostě mám zaděláno na problém — je to jako kdybych od uživatele přijal kód v libovolném jazyce a udělal na něm „eval“. Tímhle stylem můžete shodit jakoukoli technologii… Stejně tak lze říct, že JSON je shit…

logik

Problém je v tom, že ORM nabízí to nebo ono: Buďto jednoduchej přístup, nebo výkon (vlastní dotazy). Buďto přístup vždy stejnej, nebo je to bez ochrany na SQL injection. Buďto je dávka dosti pomalá, nebo použiju něco jiného než ORM.
Klasickej příklad je třeba reakce na smazání objektu. Ano, můžu ji implementovat jako event nad ORM. A přišel jsem o možnost volat hromadný akce mimo ORM. Nebo ji napíšu v databázi: pak to ale už není pravej ORM design pattern. Mohu v databázi udělat foreign key on delete update. Pak se ale nemohu spolehnout na žádnou cache, kterou mi ORM poskytuje atd…

Ve výsledku pak buďto věci píšu dvakrát (jednou nad ORM), jednou vedle, nebo to stejně napíšu vedle ORM a z ORM defakto nepoužívám, jen DB prezentační vrstvu, která narozdíl od většiny vrstev vracející pole vrací objekt. To ale je od plného ORM, tak jak se běžně chápe (objekty a veškerá logika je nad ORM vrstvou) dosti daleko.

v6ak

„Buďto přístup vždy stejnej, nebo je to bez ochrany na SQL injection.“
Ehh, cožeto?

fuzzy

To tvrzení ohledně SQL injection není úplně pravdivé – ty custom SQL dotazy se neskládají jako jeden velký string ale hodnoty se předávají jako parametry. Představit si to můžete např. jako prepared statements, kde se hodnoty parametrů v okamžiku parsování ještě nepoužívají, nebo jako dotaz s automatickým escapováním hodnot parametrů.

MD

Nech si toho bratra

fuzzy

Sorry, ale toto je fakt výstřel mimo. To že člověk může obejít ORM a přes custom SQL dotazy napsat zranitelný dotaz, to fakt není chyba toho ORM.

Na druhou stranu není pravda že by vývojář nemusel vědět co to SQL injection je, protože custom SQL dotazům se často vyhnout nejde a je potřeba je napsat bezpečně. Tím že si to trapně složím ze stringů si kopu jámu.

Jirka Hradil

Tomasi, pokud reagujete na me, tak to dovysvetlim – ma reakce byla k tvrzeni, ze „ORM automaticky resi SQL injection a vyvojar o SQL injection ani nemusi vedet“. Ta automatika je pravda, ovsem musi se vedet, jak ona ochrana funguje a jak se maji spravne predavat parametry (coz jste taky uvedl spravne v jinem prispevku). Pri spravnem pouziti je ochrana „zadara“, ovsem treba rozsahlost Hibernate ci Active Record je obrovska a pouziti blbe metody v kontextu toho ORM je velmi snadne a muze vytvaret klamny dojem, ze „cokoli projde pres ORM, tak je je chraneno“. Coz neni pravda a je velmi nebezpecne se na to spolehat. Napriklad v ActiveRecord muzu predat do metody, ktera je jeho soucasti bez problemu neosetreny parametr – pak sice pouzivam ORM, ale blbe a mam sql injection jako vysity. V Hibernate je to to same.

Nelze vsak tvrdit „Nemusis vediet nic.“. Je strasne nebezpecne tohle v diskuzich psat, pak se toho nekdo chytne a pruser je na svete.

fuzzy

Ano, byla to reakce na vás. Absolutně souhlasím s tím že „nemusis vediet nic“ je omyl. Je třeba vědět jak SQL injection funguje, aby se tomu šlo vyhnout. Mám ale trochu problém s tím dávat to za vinu ORM nástroji.

Kdybych to měl přirovnat ke škrabce na brambory … ta má jasně daný účel a způsob použití. Ovšem ve chvíli kdy ji vezmete a pobodáte s ní někoho v parku, tak problém asi nebyl v té škrabce.

Jirka Hradil

Jasne, sql injection neni vina ORM, je to problem jakekoli vrstvy, ktera komunikuje s db. Ovsem i pres ORM je sql injection mozny, to je cele. Myslim, ze jsme zajedno :). Diky.

T

suhlas

Karel Minařík

> ano, NoSQL má spoustu mínusů. Má jen jedno plus: oproti SQL je řádově rychlejší.

Ale nepovídejte. Některé „NoSQL“ jsou třeba i řádově _pomalejší_. Pokud tuhle větu myslíte vážně, bylo by lepší se nadále držet jen tématu SQL. Takhle to _opravdu_ není.

Důvod existence NoSQL databází je _nedostatečnost tradičních úložišť_ pro spoustu úloh a problémů, které se _v praxi_ nakupily za posledních pár let.

„Rychlost“ je jen jedna z nich. Ta charakterizuje např. Redis, který ale obsahuje mnohem, mnohem více, než rychlost (ze všechny množiny a množinové operace). Smrsknout jeho charakteristiku na rychlost znamená zásadní neporozumnění světu.

Další z těch úloh a problémů jsou například multi-master replikace (CouchDB), bezeschémovost (CouchDB, MongoDB), shardování (Cassandra, ElasticSearch), atd atd atd.

To, že se pořád někdo v Čechách ptá „a hele jako dobrý ale použil to někdo v praxi jako jó?!“ dokládá jedině přetrvávající vzdělanostní dluh v této oblasti. Zbytek lidí „to“ prostě normálně v praxi používá a na tyhle debaty konsternovaně zírá.

Michal Illich

Tak uděláme další NoSQL workshop, ať ten vzdělanostní dluh trochu smáznem?

Mluvil jsem o tom Josefem Šlerkou a ten čeká s odpovědí právě na vás :)

fuzzy

V mnohém máte jistě pravdu (resp. mnohé je otázka názoru), ale vyčítat NoSQL databázím že neumí transakce v té podobě jako tradiční RDBMS, to je trochu zvláštní. Ono je to totiž důsledkem CAP věty, je to zcela vědomý tradeoff mezi konzistencí a výkonem/dostup­ností. Ano, je třeba o tom vědět ale chyba to není.

Nebo to že vás framework ochrání před SQL injections … to mi přijde jako vybírat si auto podle barvy. Když chci ORM, chci aby to dobře mapovalo. Ochranu před SQL injection mi zajistí i obyčejné JDBC, pokud nebudu dotazy tupě skládat jako stringy.

A to jestli vám ORM práci (zejména v pozdějších fázích projektu) skutečně zefektivňuje, to je velká otázka. V příspěvku o kus níže jsi vystartoval na Jirku Hradila ve stylu „Daj fakty, poucky si nechaj pre kamaratov,“ tak mi dej nějaký hmatatelný důkaz.

Palo

> je třeba o tom vědět ale chyba to není
Ale o tom malokto vie. A kazdy kto propaguje NoSQL to obvykle opomenie (lebo to je predsa jasne?). Pre mnohych to znamena absolutny showstopper.

> vás framework ochrání před SQL injections
Ja ho podla toho nevyberam ale je to dost velka vyhoda ktoru „zdarma“ ziskavam. Co myslite ako to robia ti vsetci ktory nepouzivaju ORM. V 50% pripadov to budu skladat ako stringy. Ze by napriklad v Sony?

> tak mi dej nějaký hmatatelný důkaz
Hmatatelnych dokazov mam vela. Niekolko projektov, vsetky vyuzivajuce generator, DDD, MDA, paterny. Vsetky boli success, nasadene na cas a v pozadovanej kvalite.
A poznam vela dalsich projektov ktore pouzivaju ORM frameworky a su uspesne.
Ak mam pravdu povedat nepoznam ziadny kde by to v Jave niekto robil bez ORM, vytunenymi SQL prikazmi sam – to je cista strata casu.

T

1. su NoSQL databaze, ktore tranzakcie zvladaju(samoz­rejme, je to tradeoff)
2. existuju pristupy, ktore CAP theoremu pri budovani aplikacie vedia okabatit, ak treba
3. P – ak su moje query dotazy z velkej miery dynamicke a neviem ich pokryt indexami ale potrebujem volnost napr. koly aplikacnemu rozhraniu, tak z hladiska P mi je NoSQL na dve veci … (existuju uz aj pri NoSQL pristupy, ktore sa s tymto snazia vysporiadat, ale vysledkom je samozrejme dalsi tradeoff)
4. „A to jestli vám ORM práci (zejména v pozdějších fázích projektu)“
Nie kazdy sa necha prevalcovat velkym objektovym grafom pri queryovani aby potom z tejto skusenosti vyvodil zle zavery, ze inak to byt nemoze

Mintaka

Jestli jsem článek dobře pochopil, tak doporučení zní: „ORM nemusí být ta nejlepší cesta“. S tím nemám problém souhlasit.

Při jednom projektu, který obnášel desítky milionů záznamů, Python, MySQL (PosgreSQL bohužel ne), jsem také zkoušel vybrat vhodné nástroje. Mohl jsem si dovolit věnovat čas simulaci a testování výkonnosti slibných řešení. (Je s čím si hrát např.: http://wiki.python.org/moin/WebFrameworks).
Dost času padlo na vyladění návrhu databáze. (Cca 60 tabulek).

A jak to dopadlo?
V tomto případě jsem zavrhnul Django https://www.djangoproject.com/ (i když jinak ho mám velmi rád), zavrhnul jsem Alchemy http://www.sqlalchemy.org/ Pro zrychlení začátku jsem vyrobil vlastní jednoduché ORM se základními funkcemi nad daty. Od začátku bylo vytvořené jen jako pomocné řešení, obsahuje pouze zlomek možností SQL. (časová náročnost, do 20 hodin práce)

Z testů mi vyšlo, že v tomto případě bude pro velké tabulky nejlepší řešení snažit se co nejlépe využít engine MySQL, sledovat prováděcí plány, sledovat RAM, CPU, diskové operace a optimalizovat parametry MySQL a OS. Pro menší frekventované tabulky s minimem změn, že se vyplatí je načítat celé do RAM do datových struktur Pythonu. U menších tabulek, ze kterých se často čte se vyplatila serializace JSONem (2D seznamy) a marshem (slovníky).

Dvě menší tabulky (do 1M záznamů) jsou lehce na pomezí relačních databází. Obsahují atypické atributy objektů, přístup k nim je řešen přes jednu vrstvu navíc, která je ošetřena aplikační logikou.


Co případ, to unikát. Asi nejlepší by bylo znát všechny použitelné možnosti a umět si vybrat ty vhodné. Přitom „vhodný“ se může skrývat za velmi různorodou směsicí pro a proti.

Pavel

Stačí se podívat, čím se autor článku zabývá (http://totally.awe.sm/) a hned je vidět odkud vítr vane. Dolování dat z databáze rozhodně není úloha, kterou se obvykle zabývá aplikační programátor. Je to hodně specifická úloha a má úplně jiné požadavky na databázi než běžné aplikace.

voj-tech

To je jasna vec, ze mapovani SQL na objekty neni 100% proveditelne a dochazi ke ztrate efektivity, ale s tim se musi pri nasazovani ORM pocitat. ORM prinasi jine klady a to v citelnosti a udrzovani kodu a k rozsirovani aplikace. A toto hraje pro business obvykle vetsi roli. Jenom pridani takoveho sloupecku do tabulky znamena pri pouzivani ORM mnohem mene nez kdybych mel vsude po kodu rozhazene SQL odkazujici se na tu tabulku.
Nevim jak jsou na tom ruzna objektova uloziste, ale relacni databaze maji vyhodu v tom, ze mame k datum pohodlny a komfortni pristup i bez aplikace.

okbob

Nepoužívání ORM nemusí nutně znamenat, že máte v aplikaci volně poházené SQL příkazy – zrovna tak, změna struktury tabulek nemusí znamenat žádné změny v aplikaci – pokud používáte pohledy a uložené procedury.

Primární nevýhoda ORM je, že relační db se přizpůsobuje OOP požadavkům. Některá ORM se přizpůsobí db, jiná nikoliv. To způsobuje, že ručně se pak s takovou databází velice špatně pracuje. Další nevýhodou ORM je, že generují hrůzné SQL příkazy (což většinou souvisí se špatně navrženou db) – během vývoje vývojáři vůbec netuší a neřeší, jaké SQL příkazy se generují a na problémy se přijde až po roce, dvou letech provozu, kdy se dost špatně upravuje kód, kdy prakticky nelze změnit db strukturu, kdy se špatně mění dodavatel. ORM vás vede po nějaké cestě – dál a dál, a pak narazíte a zjistíte, že to na čem jste pracovali 5 let je z db perspektivy nevyhovující.

Je řada jednoduchých projektů, kde ORM nezpůsobí škody – a to ať komplexností nebo objemem dat. Nevěřím tomu, že by ORM dokázal efektivně používat někdo, kdo velice dobře nezná SQL.

Jirka Hradil

Selecty se v orm optimalizuji fakt blbe. Zajimava je ale kombinace vlastnich selectu a vyuziti orm jen pro inserty, updaty a delete. Jednou jsme to delali a vysledky dobre. Hibernatovske find jsme pouzivali snad jen pro find dle primarniho klice, to takove hruzy negenerovalo.

Ivan

ORM setri praci vyvojarum, ale zase pridava praci adminum. Veci jako hibernate jsou nocni murou kazdyho DBA.
Pokud mate nastarosti infrastrukturu (a ne aplikaci) tak je SQL prirozena hranice mezi vami a vyvojari. Problemy s vykonem nemusi nutne znamenat jen ladeni SQL. To jsou i problemy s konkurentnim pristupem se zamky a treba taky
s vyuzivanim ruznych internich struktur databaze nebo s mnozstvim DB konexi.
Pokud vyvojari pouziji ORM tak mate jako admin svazene ruce a nemuzete presne rict co, kdo a proc v databazi dela. Nikdo netusi odkud a proc vypadlo ktery SQL a kam do zdrojaku se podivat.
Dalsi problem je ze ORM frameworky se tvari, ze jsou zadarmo a neznam nikoho kdo by za ne platil support.

Jakub Linhart

Zajímal by mě názor a zkušenosti při řešení situace, kdy je kombinováno použití Domain Modelu s požadavkem generování reportů z tohoto modelu. Pro realizaci reportů se mi jeví jako přirozené použít relační databázi. Tam je pak také výhodné Domain Model perzistovat. A v takové situaci se použití dobrého ORM vyplatí, protože řeší spoustu nepříjemných problémů – hlavně Lazy Loading, Identity Cache a Unit of Work.
Jak se řeší generování reportů z noSql databází?

J.A.V.

Už to tu zaznělo. ORM je technologie jako každá jiná. Není to holly grail ani silver bullet. Na něco se hodí, na něco ne. Ale jako názor k zamyšlení není článek špatný.

PCHe

S clankem v podstate souhlasim, nicmene muj nazor je jeste extremnejsi. ORM je archetypalne spatny pristup k designu aplikace pracujici s daty ulozenymi v SQL databazi.

ORM podporuje spatne navyky, prenasi logiku, ktera ma byt v dtb na aplikacni uroven (coz je jednoznacne spatne u apliakci, kde na datech zalezi), kompletne rusi bezpecnost, vyvojar zasadnim zpusobem ztraci kontrolu na vykonem apliakce.

Pokud mam apliakci kde zalezi na bezpecnosti dat, vykonu a kde potrebuji uloziste ktere zaruci v kazdem okamziku konzistenci dat – toho s ORM nelze principielne dosahnout.

Druha vec jsou aplikace, kde se pouziva relacni databaze jenom jako uloziste dat bez jakekoliv pridane hodnoty (neresi bezpecnost, konzistenci) a struktura dat je elementarni. Tam je potom otazka, jestli relacni dtb je spravna volba.

Mimochodem s modou ORM se den za dnem casteji na pohovorech potkavam s vyvojari, kteri prestavaji relacnim databazim uplne rozumet. Nejenom, ze maji jenom VELMI zakladni predstavu o SQL, ale hlavne nemaji vubec poneti jakou ma datova vrstva reziji, co se v dtb deje.

Pavel Tisnovsky

S tou neznalosti SQL a zpusobu optimalizace dotazu je to skutecne problem, hlavne ve firmach, kde se vyviji a testuje nad „malou“ databazi (dejme tomu radove desitky tisic zaznamu per tabulka) a ORM se tedy tvari jako ta spravna cesta. Ovsem v realnem provozu s tabulkami mnohdy 1000x objemnejsimi se mnohdy zacnou objevovat dost zasadni problemy a DB admini si potom u piva ukazuji naprosto silene ORM-generovane dotazy, ktere databazi klidne na par minut uplne zahlti.

Ondřej Mirtes

…a spočítat si, co se vám vyplatí víc.

ORM ušetří spoustu práce a reprezentace dat v aplikaci pomocí objektů zlepší přehlednost, udržovatelnost a znovupoužitelnost. Při jeho používání bude databáze nejspíše více zatížená, ale pokud vás nový/silnější server vyjde levněji, než programátorův čas, který by strávil přepisováním či optimalizací aplikace, je ORM dobrá volba.

Ve světě Javy je JPA/Hibernate standardem.

okbob

Kromě investic do hw musíte k nákladům na ORM připočíst čast strávený optimalizací ORM, přepisováním z ORM do SQL, čas strávený DBA při snaze vyladit výkon databáze atd … Pro dodavatele může být ORM dobrá volba – možná i zlatý důl, ale pro provozovatele už to může být to může být na pováženou.

Větší zátěž db znamená pomalejší odezvu db, potažmo pomalejší odezvu systému, potažmo menší efektivitu práce zaměstnanců – což jsou další náklady na ORM, které se ovšem nekalkulují.

fuzzy

Souhlasím že tyto skruté náklady se většinou bohužel ani neuvažují, ale ono je pravda že je to hrozně těžké. Jak spočítáš zisk z toho že aplikaci urychlíš o X procent? Nějaké odhady se asi vyplodit dají, ale nakonec to skončí ve smyslu „hodíme na to výkonnější HW.“ A když už máš vyvinutou pomalou aplikaci, těžko s tím něco dělat (přepis je další investice).

Navíc – kolik dodavatelů se skutečně zodpovědně zabývá laděním SQL dotazů? Často se to horečně učí až ve chvíli kdy padá produkce …

okbob

Jasně, že vícenáklady se odhadují těžko – jenže to neznamená, že nejsou.

Bohužel s laděním SQL dotazů máš pravdu – je stále dost vývojářů, kteří vůbec netuší, jak SQL databáze funguje, a kteří si myslí, že nasazením ORM to ani vědět nemusí – což je samo sebou hloupost. Jinak něco utlučeš hw, ať s vyšším výkonem nebo množstvím – ale dost razantně ti rostou provozní náklady (a v případě Oraclu třeba i náklady na licence). Takže v případě větších projektů je ORM dost riziková záležitost.

Ivan

Jeste bych pridal jeden tezko meritelny naklad. Potencilne delsi doba na vyreseni incidentu. Vzpominam, ze jsem byl namoceny do reseni jedno problemu se kterym nikdo nechtel nic mit. Nazacatku se k tomu nikdo(DBA ani vyvojari) nedokazal postavit a nikdo nevedel jak to vubec investigovat.
Cca po roce a pul se ukazalo ze existuje nejaka race-condition v ORM produktu TopLink(soucast OFM).

Opravdový odborník :-)

To máte ale se vším — vždycky je potřeba si vybírat kvalitní komponenty (nejde tedy o spor ORM nebo ne-ORM). To by taky člověk mohl dojít k tomu, že si bude psát všechno sám, protože v každé cizí knihovně může být chyba… jenže ona může stejně tak být i v té vlasnoručně napsané :-)

okbob

ano i ne. Pokud se obejdete bez ORM, tak se obejdete bez několik set kb potenciálně chybného kódu – přijde na to, jak se na ORM díváte – jako něco, co musí být v aplikaci nebo jako něco, co v aplikaci být nemusí.

Opravdový odborník :-)

Ano, ale to platí třeba i pro různé frameworky pro GUI (ať už webové nebo desktopové), nebo aplikační server, interpret skriptovacího jazyka… a konec konců i pro relační databázi — to je taky spousta kódu, ve kterém může být chyba. Akorát ty relační databáze jsou na tom asi nejlíp a kvalitou převyšují ty ostatní jmenované. Ale také existují dobré ORM a dobré frameworky, které ušetří práci při tvorbě uživatelského rozhraní.

Souhlasím s tím, že ORM má někdy příliš velkou režii a může nám víc brát než dávat, ale z některých lidí tady (nemyslím vás) bohužel mám pocit, že ORM fanaticky odmítají a přitom vyzkoušeli jen nějaký nekvalitní bastl, náhražku, která si nechá říkat ORM a zobecnili to na všechny ORM implementace.

fuzzy

Ono jde IMHO hlavně o to zda v konkrétním případě je ORM potřeba nebo ne, resp. zda se pro ukládání objektů musí používat relační databáze. Pokud ne, je to prostě vrstva která systém jen zbytečně komplikuje se všemi negativními důsledky.

Pokud už aplikace má frontend, není to většinou „nadbytečná vrstva“ ale funkční požadavek. Na rozdíl od ORM, to zákazníka vesměs vůbec nezajímá a je to otázkou volby dodavatele …

okbob

Zrovna já osobně ORM nemusím a myslím si, že jejich používání ve větších projektech neštastné – nejde o režii ORM, jde o to, že vývojáře odstíní od databáze, čímž pak vývojář mnohdy netuší, co se mu tam děje. Přičemž databáze je natolik důležitá komponenta, a fakticky zásadní úzké hrdlo (protože se přistupuje na disk), že tato nevědomost znamená ohromné riziko. Mít další wrapper nad databází mi přijde špatné. Chyba je v univerzálnosti ORM – když si napíši konkrétní implementaci, konkrétního modelu, tak se zbavím desítek tisíc řádků kódu – a hlavně přesně vím, co se mi tam děje. ORM mne nezbavuje nutnosti dobře znát SQL, dobře znát transakce – při sebemenším problému se s těmito problémy setkávám – takže přínos pro datově orientované aplikace opravdu nevidím. Můžete si dovolit určitou neefektivitu v generování HTML, můžete si dovolit neefektivní kód při vykreslování formuláře – tam jsou rezervy, dobře se paralyzuje, z disku čtete relativně málo, takže můžete mít potřebný kód v cache. Skoro nic z toho neplatí v zatížené relační databázi – tam potřebujete vědět, co se Vám tam děje a navíc se Vám tam sejdou všichni uživatelé.

Na druhou stranu chápu, že ne všechny aplikace jsou datově orientované, ne všechny aplikace obsluhují stovky uživatelů, řada aplikací jsou různé prezentace, kde se vyplní pár formulářů, a donedávna jiné db než SQL nebyly tak dosažitelné – tudíž různá ORM šetřila vývojářům práci.

fuzzy

Ale to odstínění je tak nějak vlastnost a asi i cíl každé abstrakce resp. v případě ORM spíš asi mapování z jednoho světa do druhého (relačního do objektového). To bych ORM ani tak nezazlíval, to prostě není bug ale feature.

Dalo by se asi dlouze diskutovat jak je který ORM produkt efektivní, jak moc absurdní SQL dotazy generuje atd. Ale obchod „abstrakce za efektivitu“ tak nějak patří k věci – jinak bychom pořád psali v assembleru.

Z mého pohledu je zásadní problém že vývojáři považují stack RDBMS+ORM+OOP za jaksi apriori správný a vůbec o tom dále neuvažují, takže jim nepřijde nijak perverzní násilně cedit objekty z business vrstvy do RDBMS. To je ten hlavní problém, a problémy s výkonem jsou jenom součást spravedlivého božího trestu.

BTW ne každé ORM na to trpí – například můj oblíbený ibatis za tebe žádné SQL neposkládá, musíš si je napsat sám a on za tebe jenom bude provádět vatu okolo (mapování resultsetů na doménové objekty apod., identity cache apod.). Ale i tak je to prostě řešení jen pokus skutečně z nějakých důvodů musím objekty ukládat do relační DB.

okbob

Pokud ORM „nemyslí“ za programátora, tak nic nenamítám. Mám výhrady proti tomu, když ORM zcela abstrahuje datovou vrstvu.

Všiml jsem si poměrně typického chování – vývojáři díky ORM se pokouší napasovat dědičnost už v relační db – což vede k tomu, že mají několikanásobně víc tabulek než by bylo při klasickém návrhu. Jelikož nepíší SELECTy v ruce, tak je jim to šumák. V okamžiku, kdy se trochu naplní db a začnou mít problémy s db, tak už předělat db nemohou, tak začnou denormalizovat (minimálně vazby) jak o život (a totálně chaoticky – podle toho, kterou zrovna rutinu potřebují optimalizovat). A potom a) mají dost nečitelnou strukturu databáze, b) spousta výkonu se spálí údržbou integrity v denormalizované databázi.

Ještě tak před 2 roky jsem se v diskuzích ohledně ORM setkával s názorem, že použítí ORM je efektivní, poněvadž umožňuje nasadit juniory, kteří nezvládají SQL – to je to riziko ORM – že svádí k falešným závěrům – naopak musíte mít někoho, kdo dobře zvládá SQL a kdo ještě dobře zvládá to či ono ORM.

Zrovna takové emoce jako ORM může vyvolávat javascript, Python, Bash – řada dalších prostředí – opravdu jde o to, aby se (a třeba i díky této diskuzi) používání začal ten či onen jazyk, knihovna používat tam, kde je produktivní a nikoliv kontraproduktivní – kam jej na třeba začátku směřuje marketing, management.

balki

Ach jo, zasa bulvar. Prestante pisat zaslepene debiliny a radsej sa venujte niecomu serioznejsiemu.

BenBella

Pěkný článek, příde mi že pro objektově orientováné programování se hodí plně objektové databáze a OQL, měla by pak odpadnout režie při převodu entit na objekty. Nehledě na to že s objekty se ukládají i jejich metody resp. dynamická data. „Bohužel“ na trhu dominuji hrači kteří tvoří své zjisky hlavně z prodeje relačních SŘBD a do objektů se jim moc nechce resp. obohacuji své relační SŘBD směrem k objektum ale je to spíš takový kočkopes.

uf

Proč se neustále opakujete? Základní otázka je „Proč vzniklo ORM?“. Protože data byla ve formě rekordů na médiích. Postupně se rekordy zapisovaly místo více souborů do jednoho – do tabulek databáze. Mezitím přišlo objektové programování a člověk si musel zařídit načtení a uložení objektů. A načítal je růčo. Pak udělal mezivrstvu.

Nyní každý machruje s objekty, ale data jsou stále uložena relačně. Ona totiž většina evidenčních dat svou povahou relační je. Někde zaznělo, že uživatel vidí objekty. Ne. Uživatel vidí seznam klientů, k jednomu klientovi seznam smluv atd. Cítíte to? Ne objekt Klient a agregaci smluv produktů.

ORM má stále svůj původní úkol: UŠETŘIT RUČNÍ PRÁCI S PSANÍM DATOVÉ VRSTVY. Abych nemusel vypisovat SQL příkazy a jen měnit tabulky. Abych si nemusel psát generátor příkazů. Pro jednoduché neustále podobné načti, změň, ulož, najdi filtrovaný seznam. U struktury objektů / tabulek v relaci za nás pohlídá při CRUD pořadí.

Složitější věci je třeba promyslet a udělat ručně, i když si mohu trochu pomoci. Proto se mi líbí iBatis – je to framework někde mezi JDBC a JPA-Hibernate-atd. Pomůže mi, ale vím, co dělám.

Jako vždy moje heslo: Analytik a programátor je soudný člověk a ví, co dělá. Pokud ne, přijde na to a udělá to lépe. Pokud ani to ne, má dělat pojišťováka nebo poslance.

kostelnik

…ale když jsem vylezl před deseti lety ze školy tak bylo přeci jasný že data se dávají do databáze a z databáze se čte tím SQL. Když jsem pak začal dělat, tak jsem sice viděl, jak je to složitý, nepraktický – ale měl jsem hřejivý pocit že tak je to SPRÁVNĚ. Dnes bych spoustu věcí udělal jinak.

Enum a statická analýza kódu

Mám jednu univerzální radu pro začínající programátorty. V učení sice neexistují rychlé zkratky, ovšem tuhle radu můžete snadno začít používat a zrychlit tak tempo učení. Tou tajemnou ingrediencí je statická analýza kódu. Ukážeme si to na příkladu enum.

Pocta C64

Za prvopočátek své programátorské kariéry vděčím počítači Commodore 64. Tehdy jsem genialitu návrhu nemohl docenit. Dnes dokážu lehce nahlédnout pod pokličku. Chtěl bych se o to s vámi podělit a vzdát mu hold.