Hlavní navigace

Vlákno názorů k článku Na co si dát pozor při návrhu databáze? od SB - Proč název článku mluví obecně o databázích, ale...

  • Článek je starý, nové názory již nelze přidávat.
  • 16. 11. 2016 12:09

    SB (neregistrovaný)

    Proč název článku mluví obecně o databázích, ale řeší jen relační?
    Proč prvním pravidlem návrhu není výběr typu databáze podle typu zpracovávaných dat?
    Uvědomuje si autor, že ukládání objektových dat (zřejmé z příkladu) do relační databáze je jeden z nejsložitějších způsobů vzhledem k užití ORM?

  • 16. 11. 2016 16:17

    Pavel Stěhule

    Ano, máte pravdu - článek měl mít v nadpisu slovo "relační". Jsou situace, kdy se NoSQL databáze mohou hodit. Ano, uvědomuji si, že ORM je komplikovaná záležitost, a osobně ji beru jako jeden z největších omylů IT.

  • 16. 11. 2016 17:05

    j (neregistrovaný)

    ORM je predevsim o tom, ze tvurce nemusi premejslet, protoze se to udela "samo". Ze to bude (pri prekroceni nejakeho mnoztvi dat/zatezi) pomale, pripadne zcela nepouzitelne, neni prevazne v okamziku kdy to dela podstatne. Je dokonce dost pravdepodobne, ze ten problem ktery on vyrobi, bude nasledne muset resit nekdo uplne jiny. Takze proc by se tim mel zabyvat.

    BTW: Vubec nejlepsi vec se kterou sem se setkal je mit jednu centralni tabulku IDcek ... a davat do ni i logy. Ono to sice teoreticky je krasne v tom, ze ID je unikatni v ramci cely databaze ... ale taky v tom, ze jen to logovani s naprostym klidem pri prekroceni nejaky kriticky hranice celej system uplne odstavi.

  • 16. 11. 2016 17:15

    Palo (neregistrovaný)

    "jednu centralni tabulku IDcek", akoze niekto nepozna sequence alebo autogenerate ID? Za to ORM nemoze.

  • 16. 11. 2016 17:12

    Palo (neregistrovaný)

    "ORM je komplikovaná záležitost, a osobně ji beru jako jeden z největších omylů IT", uff. Ale ved ORM je nastroj, dost silny a pre niekoho mozno komplikovany ale OMYL moze byt iba zverit ho nekompetentnemu cloveku. Nastroj ako taky je to vyborny, dnes dokonca v mnohom standardizovany (pre Javu JPA) a robi to co ma, riesi mnohe chyby ktorych by sa programatori dopustali bez neho a vytvara abstrakciu nad rozne DB systemy.
    Objektove a NoSQL databazy neriesia mnohe z toho co relacne databazy zvladaju s lahkostou.

  • 16. 11. 2016 17:28

    Pavel Stěhule

    ORM je naprosto zbytečná vrstva - ta úspora času jen obtížně nahradí pak další potíže s výkonem - u databázově orientovaných aplikací.
    Pokud programátor nerozumí databázi, pak ho ORMko nezachrání. Ve výsledku jsou pak větší aplikace stejně paskvil - mix ORMka a dost nečitelných ručně psaných SQL.

  • 16. 11. 2016 22:19

    Ondrej Nemecek

    Já bych neházel všechna ORM do jednoho pytle. Jsou přeci i různá odlehčené ORM.

    Taky nevím, proč by měl vadit mix generovaných a ručně psaných dotazů (pokud to bude přehledně strukturované). Triviální dotazy mi vygeneruje ORM a netriviální nebo výkonově kritické si napíšu sám.

    Problém s ORM vidím spíš tam, kde není zajištěna konzistence na úrovni databáze a spoléhá se jen na ORM nebo aplikační úroveň. Pak není možno přistupovat k databázi přímo, protože to snadno rozbiju, není možné z databáze zjistit kardinalitu, validace atd.

  • 18. 11. 2016 11:03

    SB (neregistrovaný)

    Ale tak to přece obvykle dopadne - buďto vyrobím obrovské ORM, které se bude snažit vyčarovat složité, rychlé dotazy do RDB (stejně se mu to nepovede), nebo se na to vyseru, ORM udělám mrňavé a několik náročných dotazů vyřeším ručně, což je daň za použití RDB. Mimochodem proto si dělám ORM sám, protože zatím jsem viděl jen ty obrovské, univerzální molochy.

    Buďto je váš systém databázocentrický (což považuju z mnoha důvodů za chybu), pak se budete muset v spolehnout na prostředky oné DB k zajištění konzistence (a SQL v RDB je hodně primitivním prostředkem), nebo máte aplikačněvrstvo­centrický systém, kdy zapracování (i částečně) konzistence ještě do DB je 1. zmenšením pravděpodobnosti chyby, 2. přiděláním práce, 3. porušením DRY.

  • 18. 11. 2016 12:45

    Heron

    Buďto je váš systém databázocentrický (což považuju z mnoha důvodů za chybu)

    Proč za chybu? Já to považuji už v podstatě za něco jako framework kolem kterého můžu aplikaci postavit a nemusím řešit věci, které chytří lidé vymysleli daleko lépe a efektivněji.

    k zajištění konzistence (a SQL v RDB je hodně primitivním prostředkem)

    No upřímně, polovina diskuse se tady točí kolem toho co dokážou vývojáři zprasit a za takové situace házet na ně ještě odpovědnost za něco tak náročného, jako je konzistence dat, je trochu úlet. Viděl jsem mnoho programů, které chtěli řešit konzistenci sami a totálně selhávaly. Proč? Protože ti autoři se ani neobtěžovali si něco zjistit o prostředcích, které používají. Lidi, kteří se neobtěžují si zjistit ani základy db, tak stejně tak kašlou na věci jako konzistence fs apod. Takže řešit konzistenci v aplikaci je cesta do pekel a místo toho je lepší používat systém, který už tu konzistenci má pár desítek let vyřešenou.

  • 18. 11. 2016 13:10

    SB (neregistrovaný)

    Protože musíte kompletní konzistenci realizovat v DB (relačně nad objektovými daty v relacích), přičemž ORM stejně budete asi řešit v aplikační vrstvě, takže to máte rozstrkané na 2 místech. Stejně se nevyhnete duplicitám (porušení DRY), mimoto prostředky PL/SQL jsou mizivé proti Javě. Dále jste se připravil o možnost jednoduše prohazovat nejen různé typy DB pod aplikační vrstvou, ale často i jen různé RDB, protože každý výrobce si (PL)SQL mastí po svém.

    Konzistence dat je součástí každého doménového modelu (ať je umístěn kdekoli), ta se v DB sama od sebe neudělá. A nepředstavujte si, že to spočívá pouze v existujících záznamech k cizím klíčům! Často jsou to rozsahy hodnot, formáty řetězců, počty záznamů či celé výpočty přes mnoho entit (opět složitě nad rozloženými objekty!). SQL na toto nebylo původně navrženo, šlo o jednoduchý dotazovací jazyk, který se dolepoval!

  • 18. 11. 2016 13:25

    Heron

    Můžete prosím do odpovědí dávat i citace z komentáře na který reagujete? Místní systém neodsazuje komentáře a často tak není poznat na koho reagujete.

    Protože musíte kompletní konzistenci realizovat v DB (relačně nad objektovými daty v relacích), přičemž ORM stejně budete asi řešit v aplikační vrstvě, takže to máte rozstrkané na 2 místech.

    Datovou strukturu si definuju v databázovém schématu, včetně datových typů a jejich omezení (je to třeba celé číslo, ale v daném modelu se vyskytují pouze čísla od do, takže si tam vrazím CHECK) a potom s tím appka pracuje. Nemusím to řešit podruhé v app (ale jistě můžu), protože db mi data neodpovídající schematu stejně nepřijme.

    Konzistence dat je součástí každého doménového modelu (ať je umístěn kdekoli), ta se v DB sama od sebe neudělá. A nepředstavujte si, že to spočívá pouze v existujících záznamech k cizím klíčům! Často jsou to rozsahy hodnot, formáty řetězců, počty záznamů či celé výpočty přes mnoho entit (opět složitě nad rozloženými objekty!).

    No já si to tak nepředstavuju, viz výše. Ano, db mi nezajistí úplně vše, ale to co jsem viděl v praxi, tedy přístup: to pořešíme v aplikaci a db použijeme jen jako úložiště záznamů, tak to vždy vedlo do pekel. Pro mě je dobré schema se všemi omezeními naprostý základ.

  • 21. 11. 2016 15:49

    SB (neregistrovaný)

    „...citace...“
    Někteří nadávají, že citace zabordelují diskusi. Lepší by bylo borce, který kdysi funkční odsazování zkurvil, párkrát kopnout do zadku, aby se zbráboral.

    CHECK je primitivní kontrola. Jak vytvoříte např. kontrolu dokladu, zda součty několika údajů jeho položek jsou sumárně na dokladu v pořádku? V obj. modelu je to trivialita na řádek, v SQL je to na dotaz, v horším případě na proceduru.
    V aplikaci to *musíte* řešit podruhé. Jak byste kontrolovat validitu objektu během zpracování (výpočty, plnění uživatelem, ...)? Extra procedurou nebo funkcí (těmi to většinou nejde) v DB? Nebo to najebal do tabule a když se to vyjebe, tak je to špatně, když ne, použijete ROLLBACK? Nebo jak?
    Peklo pro mě byly projekty, kde se vše jebalo do RDB a za ukrutných časových nároků se to ladilo a upravovalo a případně zpětně promítalo do aplikace.

  • 22. 11. 2016 9:27

    Heron

    Někteří nadávají, že citace zabordelují diskusi. Lepší by bylo borce, který kdysi funkční odsazování zkurvil, párkrát kopnout do zadku, aby se zbráboral.

    Ano, to by bylo jistě lepší, ale s tím my nic neuděláme.

    CHECK je primitivní kontrola. Jak vytvoříte např. kontrolu dokladu, zda součty několika údajů jeho položek jsou sumárně na dokladu v pořádku?

    Třeba tak, že k datům v DB budu přistupovat pouze přes procedury. Tím mám zajištěnou konzistenci, datový model i spolehlivé ukládání dat. Na jedné vrstvě.

    Nebo to najebal do tabule a když se to vyjebe, tak je to špatně, když ne, použijete ROLLBACK? Nebo jak?

    S tím, že se transakce nepovede, stejně musí program počítat. Nevidím nic špatného na tom tento prostředek (obecně řízení transakcí) přímo jako součást frameworku, na kterém program stavím.

  • 18. 11. 2016 13:56

    Ivan (neregistrovaný)

    . Dále jste se připravil o možnost jednoduše prohazovat nejen různé typy DB pod aplikační vrstvou, ale často i jen různé RDB, protože každý výrobce si (PL)SQL mastí po svém

    Tohle zni hezky. V realu je to chimera. V praxi se nic takoveho nedeje. Muze se stat, ze vymenite OS. Napr Unix => Linux. Muze se stat, ze zmenite nekolikrat aplikacni framework, homemade ORM => MyBatis => Hibernate => EclipseLink. V realnem svete u funkcni aplikace se rozhodne nechcete zmenit databazi.
    Tak mozna po 10ti letech a vetsinou je to soucasti kompletniho prepsani cele aplikace.

    ORM vas ani zdaleka neodstini ode vsech specifik Db engine.

  • 21. 11. 2016 10:58

    Karel (neregistrovaný)

    Některé velké ERP systémy umí běžet proti více databázím. Takže i když si kupříkladu koupíte od Oracle JDE E1, tak provozovat ho můžete proti konkurenční DB. Je to obchodní strategie, dát zákazníkovi na výběr aby se tolik nebál. Ale cena za to je obrovská, z vlastností DB se použijí tak akorát primární klíče. Nemá to ani Foreign key a vše musí řešit vrstva těsně nad databází, která se stará o transakce a integritu dat. Na druhou stranu to opravdu funguje.

  • 21. 11. 2016 16:03

    SB (neregistrovaný)

    Nikdo to nedělá ne proto, že by to nebylo třeba, ale že systém je vytvořený tak, že to NEJDE. To je podstatný rozdíl. A přesně o tom mluvím. Potřeba vyměnit databázi (z jakéhokoliv důvodu), nebo rozdělit data do více DB dle způsobu zpracování, to není nic zvláštního (pro někoho). Samozřejmě, že když je apl. logika v DB, tak to skončí nákladným přepracováním celého systému. Sám píšete, jak prohazujete OS (nejspodnější SW vrstva) či frameworky pro persistenci (které bývají prorostlejší do modelu více, než by bylo zdrávo; hned nad DB), ale výměna DB je z nějakého důvodu špatně? Proč?

  • 21. 11. 2016 20:59

    Filip Jirsák

    Potřeba vyměnit databázi […] není nic zvláštního (pro někoho).
    Mně to teda docela zvláštní připadá. Protože relační databáze je technicky vzato sice samostatná služba, ale často je velmi úzce s aplikací svázána, je to fakticky součást aplikace. A velké databáze jsou různé, nejsou to jen různé implementace téhož standardu. Takže změna databáze neznamená jenom třeba trochu jiný zápis SQL příkazů, ale znamená to i tu a tam změnit logiku aplikace, někde třeba změnit strukturu ukládaných dat atd. Pokud máte aplikaci napsanou univerzálně, musíte použít nejmenší společný jmenovatel dostupných funkcí, a tím se zbytečně ochuzujete o všechno to, co mají jednotlivé databáze navíc. Pokud aplikaci převedete z Oraclu na MySQL, je otázka, proč ji vůbec provozovat na Oraclu.

    Na operačním systému tyhle aplikace nebývají zdaleka tolik závislé, jako na databázi, protože od OS toho obvykle požadují minimum – aby uměl spustit proces, uměl ukládat soubory (a i tomu se dnes aplikace vyhýbají), a zprostředkoval síťovou komunikaci.

  • 24. 11. 2016 15:11

    SB (neregistrovaný)

    „...často je velmi úzce s aplikací svázána, je to fakticky součást aplikace...“
    To může být právě ta chyba. Jedinou vazbou mezi aplikací (s dom. modelem) a DB má být onen mapovač, který je jiný pro každý typ DB, přechod na jinou DB je pak právě věcí pouze výměny mapovače.

    „Takže změna databáze neznamená jenom třeba trochu jiný zápis SQL příkazů, ale znamená to i tu a tam změnit logiku aplikace, někde třeba změnit strukturu ukládaných dat atd.“
    Tak to určitě ne, struktura a logika dom. modelu je dána, jeho přepis do DB je práce mapovače. To samozřejmě nevylučuje, že mapovač obvykle má několik speciálních funkcí pro několik specifických operací pro dosažení optimalizace. Aplikaci (dom. model) nezajímá, jaký šunt visí pod ním. Upravil-li jste dom. model dle omezení DB, chcete po něm práci mapovače.

  • 18. 11. 2016 13:16

    j (neregistrovaný)

    Ad konzistence, vyvojari nejsou schopni zaridit ani daleko primitivnejsi pozadavek - unikatni cislo dokladu. Natoz konzistenci dat. Transakce je pak pro ne velmi casto spis sprosty slovo. Bud vubec netusi, ze neco takovyho existuje, nebo nemaji poneti, k cemu by to jako melo bejt dobry.

    Takze pak ta "aplikacni konzistence" dopadne presne jak dopadnout musi. Trebas ze soudruzi aktualizujou stav skladu ... zbozi ze skladu zmizi ... ale na dokladu vydejky se neco nepovede, takze zadna nevznikne. A protoze skladnik je zviratko cinorode, tak to zkusi jeste 10x .... aby mu nakonec system zahlasil, ze zadne dalsi zbozi v tom plnem regale neni.

  • 19. 11. 2016 14:25

    Palo (neregistrovaný)

    >Mimochodem proto si dělám ORM sám
    A to je presne ten blby krok. Aj tie velke molochy zacinali ako vase jednoduche ORM, preco asi su z nich tie molochy? Lebo sa poucili a ze robit to spravne nie je jednoduche. Namiesto toho doucit sa nieco si radsej napisam sam na houby.

  • 17. 11. 2016 9:28

    Palo (neregistrovaný)

    Ale to je asi nepochopenie ORM. Prvy ucel je ABSTRAKCIA nad DB. Pokial pouzivam Criteria a HQL je mi jedno s akou DB robim. Mozem si to prepnut na Oracle, PostgreSQL, MS-SQL a vsetko funguje. Za dalsie to OPTIMALIZUJE pristup k udajom pomocou Lazy loading, Eager fetch, Flushing, ... . Ak od biznis logiky zavisi ci potrebujem dalsie udaje pri spracovani nemusim robit zbytocne komplikacie a framework sa postara v pripade potreby o dotiahnutie udajov pripadne optimalizuje updaty v DB, neviditelne a tak aby vsetko fungovalo. No a uplne najviac je to BEST PRACTICE takze postupne ked sa zisti ze existuje optimalnejsi postup na fetch alebo mapovanie udajov z objektu alebo do objektu tak nemusim prerobit celu aplikaciu ale iba dam novsiu verziu frameworku. Je to presne ten isty princip ako Garbage Collector. Super programator to nepotrebuje ale vsetci vo vasom teame su Super programatori? Radsej tam budem mat tento framework ktory vsetci pouzivaju a mozem ako architekt kludnejsie spavat a mozem ist iba po tych vynimkach kedy sa nepouziva a zistit ci je to naozaj potrebne.
    No a samozrejme existuju aj specialne 'rucne' robene selecty/updaty pre specialne pripady ale vzdy treba dodrzovat pravidlo 80/20 cize na 80% pripadov by mal stacit framework, 20 urobit rucne. Ak mam pravdu povedat za posledne roky je to u nas asi 95% vsetkeho ciste Criteria a HQL.

  • 17. 11. 2016 10:40

    Filip Jirsák

    Právě že je to pochopení ORM, a vámi uváděné příklady jsou přesně to, co je špatně. Abstrakce nad DB, používání univerzálních prostředků – to znamená, že nepoužíváte specifické prostředky databáze, které umožňují přístup optimalizovat. „Optimalizace“ přístupu pomocí lazy loading, eager fetch, flushing – to optimalizuje z hlediska ORM, ale z hlediska relační databáze to často je pravý opak, načítají se zbytečná data, připojují zbytečné tabulky. Ale hlavní problém je v samotném principu ORM – data se neukládají tak, jak by měla být uložena v relační databázi, ale je to jenom hloupá serializace objektů.

    Jak už bylo řečeno, s ORM není problém, když je dat málo, to databáze zvládne hrubou silou. Problém je, když je těch dat hodně a potřebujete to optimalizovat tak, aby s nimi databáze mohla pracovat efektivně. Nepomůže vám, když budete psát 20 % dotazů ručně, když je problém ve struktuře databáze.

  • 17. 11. 2016 11:15

    Palo (neregistrovaný)

    "používání univerzálních prostředků" - presne naopak pouzivaju sa optimalne prostriedky danej databazy o to sa stara ta prekladova vrstva, ja si o nieco poziadam a vykona sa to optimalne tak ako to ta konkretna DB umoznuje. Napriklad strankovanie, ak DB umoznuje seek (cez limit alebo rownum) tak to ta prekladova vrstva urobi ak nie tak to urobi inac optimalne pre danu DB.
    "z hlediska relační databáze to často je pravý opak" zase zle - je to optimalne pretoze to su presne tie blbe optimalizacie, z disku nacitavate cely sektor je uplne jedno kolko stlpcov pokial sa to do stranky vojde (co sa na 99% pripadov vojde) tak je to optimalne, zly priklad.
    "jenom hloupá serializace objektů" - to ste asi este nevideli 'hlupu' serializaciu objektu.
    "když je problém ve struktuře databáze" - ale ved struktura je uplne rovnaka v com je struktura DB ina ci robim priamo v SQL alebo cez ORM? Nie raz sme mapovali existuju aplikaciu fungujucu cez ulozene procedury do ORM bez zmeny, maximalne boli vynutene zmenou biznisu nie potrebou ORM.

  • 17. 11. 2016 11:34

    Filip Jirsák

    Ne, nepoužívají se optimální prostředky dané databáze. Stránkování je nezajímavá trivialita. Optimální prostředky databáze jsou například analytické funkce, hierarchické dotazy, agregované dotazy atd. Znáte nějaké ORM, které tohle používá?
    Ad načítání celého sektoru – opět uvádíte příklad špatné optimalizace. Za prvé jsem nepsal o zbytečném načítání dalších položek z jednoho řádku, ale o zbytečných joinech. A i tím zbytečným načítáním celého řádku můžete dotaz podstatně pokazit, protože je klidně možné, že ve skutečnosti potřebujete jenom dva údaje, které máte v indexu – a databáze pak nemusí datovou tabulku číst vůbec.
    Ne, struktura databáze nemusí být stejná. Různé ORM nástroje se chlubí tím, že umožňují z objektové reprezentace vytvořit strukturu databáze. A když je databázová struktura navržena samostatně, dělá to zase problém ORM nástrojům.
    To, že vám ORM dobře funguje na menších datech, kde prostě stačí hrubí výkon, neznamená, že to stejně dobře bude fungovat i u velkých dat, kde už potřebujete pracovat s tím, co ta databáze dobře umí – nemůžete jí prostě naložit a doufat, že si s tím nějak poradí.

  • 17. 11. 2016 11:47

    Palo (neregistrovaný)

    Cez HQL pouzivame aj analyticke funkcie, agregovane dotazy a az ked je to ABSOLUTNE nevyhnutne pouzije sa ciste SQL. Dokonca si mozete vybrat aj tie dva stlpce uplne bez problemov cez HQL a ulozit do ineho objektu. Ale kolko percent dotazov to je?
    Struktury mozu byt ine, skuseny programator to urobi dobre v SQL aj v ORM. Neskuseny to cez ORM tak nedomrvi ako cez ciste SQL kedy to na 100% urobi zle. Garantovane to skuseny programator urobi RADOVO rychlejsie DOBRE rovno v ORM.
    Ziadne mensie data, pouzivame ORM nad najvacsou DB v tomto state (Slovensko). Uplne bez problemov. Pouzivame fetch mapy, dlhe vety, ORM nad parametricke view, spustanie procedur, ... dnes vsetko cez standardne JPA.

  • 17. 11. 2016 11:59

    Filip Jirsák

    HQL není ORM. ORM znamená to automatické mapování, tj. ORM frameworku si řeknete o nějaký objekt a framework sám „nějak“ načte potřebná data z databáze – podstatné je právě to, že uživatel ORM neřeší to, jak se ta data načtou. Což při použití HQL není pravda.

  • 17. 11. 2016 12:42

    Palo (neregistrovaný)

    To ste si iba vy nejako vykonstruovali co je a co nie je ORM. ORM je napriklad JPA ktore obsahuje aj JPQL ktore robi tu transparenciu o ktorej pisem. Ta 'hnusna' medzivrstva medzi vami a DB. Ale ak sa vam JPQL nepozdava co toto, to uz je dostatocne 'hnusne' aby ste to prehlasili za ORM?

    CriteriaBuilder cb = em.getCriteri­aBuilder();
    CriteriaQuery<Ob­ject[]> query = cb.createQuery(Ob­ject[].class);
    Root<Department> d = query.from(De­partment.clas­s);
    Join<Departmen­t,Teacher> teachers = d.join(Departmen­t_.teachers);
    query.multise­lect(d.get(De­partment_.name),cb­.count(teacher­s)).groupBy(d­.get(Departmen­t_.name));

    Pre mna 1000 krat lepsie ako nejaky povalujuci sa string v kode pretoze ked niekto refactoruje nazov fieldu tak viem kde sa co pokazilo. To ze potom mame nadstavbu pre programatorov ktorym staci urobit:

    List<Conditio­nalCriteria> conditions = criteriaFor(Per­son.class)
    .select(Person­Properties.na­me().last())
    .select(Person­Properties.sa­lary()).min()
    .withProperty(Per­sonProperties­.sex()).eq(Gen­der.MALE)
    .groupBy(Person­Properties.na­me().last())
    .orderBy(Person­Properties.na­me().last()).as­cending()
    .build();

    A vieme to optimalne bezat nad vsetkymi DB ktore ani neviem vymenovat. Sazmorejme takychto dotazov je minimum ale neznamena ze nepouzivame ORM alebo ze nie su optimalne.

  • 17. 11. 2016 13:32

    Filip Jirsák

    Podle té vaší definice, že ORM je jakékoli mapování z relační databáze do objektů, je ORM i provedení dotazu, ručí vytvoření objektu pro každý řádek a načtení hodnoty z položky řádku a její zápis do nějakého atributu objektu. Nebo-li by se ORM používalo v každé aplikaci napsané v objektovém jazyce a využívající relační databázi. A tak jsem to nemyslel já a zcela jistě to tak nemyslel ani Pavel Stěhule. Problém není v tom mapování dat do objektu, problém je v těch automaticky vytvářených neefektivních dotazech, problém je v přizpůsobování struktury databáze ORM místo přizpůsobování efektivní práci s daty, problém je, že programátor nějak „magicky“ dostane data a ani neví, jaké dotazy se kvůli tomu musely provést, jestli pro ně vůbec má indexy apod.
    Povalující se stringy nejsou jedinou alternativou k ORM. Klidně můžete mít továrny na vytváření SQL dotazů, můžete je mít nějak označené, takže pak v testu dokážete vygenerovat všechny SQL dotazy, které v aplikaci připadají v úvahu, můžete zkontrolovat, zda je databáze dokáže zpracovat (tedy zda jsou syntakticky správně a neodkazují se na neexistující tabulky, sloupce nebo funkce), můžete rovnou zkontrolovat, jaké mají prováděcí plány, zda třeba nechybí nějaký index.
    Problém ORM není v tom, že by se nehodilo na jednoduché věci. Problém je v tom, že tím, že před programátorem skrývá databázi, dozví se programátor, že je něco špatně, až když je daleko za tou hranicí, kdy je ORM ještě vhodné použít.

  • 17. 11. 2016 13:59

    Pavel Stěhule

    Přesně tak. Tím, že je programátor odtržený od databáze, tak nemá ani šanci se databáze naučit - pochopit ji, uchopit.

  • 17. 11. 2016 14:26

    Palo (neregistrovaný)

    "nemá ani šanci se databáze naučit" -> a to musi ked prave riesi zauctovanie polozky ako side efekt biznis procesu pri reakcii na event stielany z messagingu po transformacii cez XML? Kazdy ma predsa svoje starosti. To neznamena ze ORM je zlo. Pomaha riesit programatorovi problem ktory ma. Prave ten specialista ktory sa v ORM a SQL vyzna mu pripravi rozhranie kde on uz dostava objekt a nastavi na nom nejaky field. On je specialista na biznis ma z toho dost velku hlavu a fakt nemusi ovladat najnovsie funkcie novej verzie Oracle DB.

  • 18. 11. 2016 8:51

    j (neregistrovaný)

    "a to musi ked prave riesi zauctovanie polozky"
    No to by kurva mel, protoze pak to dopadne tak, ze az se tu polozku bude snazit zauctovat stovka ucetnich, tak se to cely podela, prave proto, ze programator vubec netusi, co to v ty databazi dela.

    A pokud to nezvlada, at de delat ten biznis k lopate.

  • 19. 11. 2016 14:19

    Palo (neregistrovaný)

    > pak to dopadne tak, ze az se tu polozku bude snazit zauctovat stovka ucetnich, tak se to cely podela
    A vy zas nechapete ze ja ako architekt im tam nanutim tranzakcie a versioning a "pak se to nepodela", lebo kazdu vyniku z tychto pravidiel prezriem a chcem mat poriadne zdovodnenu.

  • 17. 11. 2016 14:14

    Palo (neregistrovaný)

    Ano "jakékoli mapování z relační databáze do objektů" -> definicia ORM - Object Relational Mapping, to nie je moja definicia.
    "automaticky vytvářených neefektivních dotazech" -> vacsina je automaticky efektivna, neefektivne sa daju optimalizovat (ked je treba).
    "přizpůsobování struktury databáze ORM" -> Kedy a co sa prisposobuje ORM, aspon nejaky hmatatelnejsi priklad, ja vam poviem ovela lepsie automaticke prisposobenie sa efektivnej praci nez ORM, surrogate keys, autoincrement, version (kontrola integrity), ... co ziskate okamzite pouzitim ORM frameworku namiesto cisteho SQL.
    Programator sa nijako 'magicky' nedostava k datam. Pyta sa externeho systemu na objekty ktore splnaju nejake podmienky. To nie je ziadna magia a nedostava riadky ale objekty, to je cely rozdiel. V 80% pripadov a viac automaticky efektivne s moznostou optimalizacie nejakym dalsim specialistom v pipeline. Podobne ako v SQL. Ziadny rozdiel. Ak programator nerozumie co robi tak isto vam zabije tu databazu aj v SQL.
    "jaké mají prováděcí plány, zda třeba nechybí nějaký index" - Na to su specialisti co v teame taketo veci riesia, treba ich aj v SQL tak ako aj v ORM, absolutne ziadny rozdiel. To co vy pisete stale dookola ze nejaky zaciatocnik nieco v ORM pokazi, ale to pokazi aj v SQL ked nevie co robi. Potom tam mate specialistu ktory to prejde a mozno upravi indexy alebo dotaz. Opat nic specialne co by bol ORM problem.

  • 17. 11. 2016 14:23

    Pavel Stěhule

    Je hrozně smutný, že na indexy musíte mít specialistu. Java samotná je docela komplexní, s ORM jako je extrémně komplexní - takže člověk, který s tím dokáže dělat nemůže být a není žádný blbec. Pokud by měl přístup k databázi, tak nepochybně indexy správně navrhne.

  • 17. 11. 2016 14:29

    Palo (neregistrovaný)

    "Pokud by měl přístup k databázi, tak nepochybně indexy správně navrhne" -> toto odporuje tomu co sam hovorite kedze vase konzultacie odhaluju tieto problemy aj v pripade cisteho SQL. Preco tito SQL specialisti nenavrhli dotaz a index spravne? Sam pisete ze sa s tym stale stretavate. ORM vam skor pomoze to urobit spravne nez nespravne.

  • 17. 11. 2016 14:46

    Pavel Stěhule

    Buďto je to začátečnická neznalost - nebo ORMka (Java, Python) nebo db komponenty (MS Access, Visual Basic, ..). V podstatě jakýkoliv nástroj, který umožní používat databáze bez znalostí, znamená, že znalosti vývojáře ohledně databáze stagnují - a pokud jeho aplikace roste, a on ne (znalostmi), tak je problém na světě.

  • 18. 11. 2016 9:35

    gll (neregistrovaný)

    ORM umožňuje kratší zápis běžných dotazů, protože definice modelů obsahuje informace navíc. V raw SQL se opakují stále stejné podmínky JOINů a stále stejné poddotazy. Mohu použít pohledy, ale ty nejsou tak flexibilní.

  • 18. 11. 2016 9:52

    Pavel Stěhule

    Což už je pomůcka, která Vám umožňuje se střelit do nohy - toto není jednoznačná výhoda. Pro: uděláte méně chyb, kód je čitelný. Proti - vůbec nevíte o tom, že generujete dotaz, který může být náročný, nebo že generujete jednotky až desítky dotazů. Pro zkušeného programátora je to pomůcka, pro nezkušeného to může být past.

  • 18. 11. 2016 10:10

    gll (neregistrovaný)

    Většinou předem vím, jaký dotaz chci vygenerovat. Jen ho nemusím celý zapisovat. ORM určitě nejde používat bez znalosti SQL. V tom s vámi souhlasím.

  • 17. 11. 2016 14:54

    Filip Jirsák

    vacsina je automaticky efektivna, neefektivne sa daju optimalizovat
    Nikoli, ORM nemá prostředky k tomu vytvářet efektivní dotazy. ORM vytváří dotazy podle struktury objektů – zda ten dotaz bude nebude efektivní je pouze věcí náhody.

    surrogate keys, autoincrement
    To s ORM nijak nesouvisí, umělé klíče jsou věcí návrhu struktury databáze, autoincrement se řeší prostředky databáze.

    version (kontrola integrity)
    Version neřeší kontrolu integrity, je to způsob řešení optimistického zamykání záznamů.

    Pyta sa externeho systemu na objekty ktore splnaju nejake podmienky. To nie je ziadna magia a nedostava riadky ale objekty, to je cely rozdiel.
    No jo, jenže v tom externím systému právě žádné objekty nejsou. Tam jsou data uložená v tabulkách. A „magie“ je právě v tom, jak vybrat ta data splňující určité podmínky. Abyste ta data mohl efektivně vybírat, musíte si je nejprve správně připravit (mít je uložené ve správné struktuře a vytvořit pro ně správné vyhledávací struktury), a pak musíte správně zkonstruovat dotaz (s využitím té struktury a vyhledávacích struktur). Přičemž to první ORM nijak neovlivní, k tomu druhému má jen některé informace (zná pouze vazby objektů, nezná všechny vazby v databázi a nepoužívá informace o existujících indexech).

    Ak programator nerozumie co robi tak isto vam zabije tu databazu aj v SQL.
    Rozdíl je v tom, že když programátor používá SQL a dospěje k dotazu, který napsat neumí, tak ho prostě napsat nemůže a musí to vyřešit někdo jiný. S ORM si jenom řekne, že chce objekty splňující nějaké podmínky, a ORM ten dotaz nějak poskládá. Takže na to, že je to celé úplně špatně, dotyčný programátor ani nemusí přijít.

    Na to su specialisti co v teame taketo veci riesia, treba ich aj v SQL tak ako aj v ORM, absolutne ziadny rozdiel.
    Rozdíl je v tom, jestli se od začátku řeší efektivní přístup k databázi, nebo jestli se všechno hodí na ORM a hrubou sílu databáze, a pak se to začne řešit až když se ukáže, že z ORM lezou šílené neefektivní dotazy.

    To co vy pisete stale dookola ze nejaky zaciatocnik nieco v ORM pokazi, ale to pokazi aj v SQL ked nevie co robi.
    Rozdíl je právě v tom, že v případě SQL to zjistí, že neví, co má dělat, v případě ORM to nezjistí, protože ORM vždycky nějaký dotaz poskládá.

    "Stránkování je nezajímavá trivialita", podobne ako dnes spomenute JOIN, funcie nad stlpcom, autoincrementalne ID, left/full join.
    Stránkování je nezajímavá trivialita, přidáte podmínku na klíč >= začátek stránky a limit. Na tom není co řešit – jediné, co se na tom dá zkazit, je to, že se spolehnete na nějaké automatické mechanismy a místo hledání klíče v indexu použijete offset, čímž donutíte databázi procházet celý index od začátku.
    Naproti tomu když máte spojení dvou velkých tabulek, které ve výsledku vrací 100 záznamů, můžete ho mít udělané tak, že se z jedné tabulky podle indexu vybere 100 záznamů a k nim se podle indexu dotáhne podle indexu 100 záznamů z druhé tabulky. A nebo může to omezení dělat teprve ten join, takže z jedné tabulky vytáhnete (třeba podle indexu) 10 milionů záznamů, z druhé tabulky (třeba podle indexu) 30 milionů záznamů, a teprve jejich průnikem vznikne ta výsledná sada 100 záznamů. Oba jsou to joiny nad tabulkami s desítkami milionů záznamů vracející 100 řádků, ale ten první se provede velmi rychle a efektivně, na provedení toho druhého spotřebuje databáze spoustu zdrojů.

    a to musi ked prave riesi zauctovanie polozky ako side efekt biznis procesu pri reakcii na event stielany z messagingu po transformacii cez XML
    Myslím, že tu nikdo nechtěl tvrdit, že ORM je v jednoduchých případech použitelné. Problém je v tom, že skrývá databázi, takže se zakryje ten zlomový okamžik, kdy ORM přestává být dobrý sluha a začíná být zlý pán, a přijde se na to až mnohem později. A druhý problém je v tom, že když se někde ORM použije, hodně těžko se části nahrazují něčím jiným – protože všechny ty automagické funkce ORM předpokládají, že ORM je pánem nad databází a ono si rozhoduje, kdy bude co načítat nebo ukládat.

  • 17. 11. 2016 15:17

    Palo (neregistrovaný)

    > umělé klíče jsou věcí návrhu struktury databáze, autoincrement se řeší prostředky databáze.
    A kolko zaciatocnikov to pozna a vie spravne pouzivat?
    > který napsat neumí
    Ale umi, jen blbe - dokazom budiz clanok pod ktory piseme komentare
    > hrubou sílu databáze
    Vy mate z toho ORM neprimerane velky strach, pokrocile ORM frameworky su dnes velmi efektivne a dobre a jednoducho optimalizovatelne
    > ORM je v jednoduchých případech použitelné
    Je pouzitelne aj v komplikovanych pripadoch
    > ono si rozhoduje, kdy bude co načítat nebo ukládat
    Nie nerozhoduje, viete to ovplyvnit - flush(), detach(), ...
    Pouzivali ste niekedy na nejako skutocnom projekte napriklad Hibernate? Toto co tu pisete je velke historia a ORM je dnes asi trochu dalej nez ked ste s tym naposledy robili. A tak ako som pisal inde nie VSETKO musi byt absolutne prisposobene efektivnej praci s DB. Treba iba aby to bolo dostatocne rychle a pouzitelne, pripadne lahko optimalizovatelne.

  • 17. 11. 2016 16:02

    Filip Jirsák

    Na projektu snad bude pracovat někdo, kdo umělé klíče zná a naučí začátečníky, jak to mají používat. Pokud tam nikdo takový nebude, neudělají umělé klíče ani s ORM, stejně jako nebudou vědět, že mohou přes ORM pracovat s autoinkrementy nebo sekvencemi.

    Špatně napsané dotazy jsou v článku zmíněné jen u čistých predikátů, a ty lze úplně stejně napsat i v HQL. Navíc zrovna tohle jsou chyby, které jsou většinou vidět na první pohled (pokud to dotyčný zná), přinejhorším to ukáže exekuční plán. A ty chyby se snadno opravují.

    Co znamená, že jsou frameworky velmi efektivní a dobře a jednoduše optimalizovatelné? Znamená to, že nějaký ORM framework umí načíst třeba cizí klíče z databáze a vynechat zbytečný join (pokud třeba tabulky mají vazby A → B → C, ale mají společné klíče, takže je možné spojit přímo A → C)? Nepoužíváme nejnovější verzi Hibernate, ale umí teda aktuální verze alespoň do SQL dostat hinty (třeba alespoň z HQL)? Nebo co si mám představit pod „optimalizova­telné“?

  • 17. 11. 2016 17:33

    Palo (neregistrovaný)

    "úplně stejně napsat i v HQL"
    Ale v HQL povacsinou nepisete, povacsinou pouzivate criteria a standardne mapovanie. Ked mam vsade kusy SQL nebodaj sa mi nejako spajaju v kazdej triede inac inac sa tam mapuju parametre hladajte to tam. Mozno ani nenajdete.
    Vacsinou si KAZDY kto nepouziva ORM lebo sa mu to nepaci (not invented here) po case urobi nejaky jednoduchy mapovy framework, sklada tie query, nejak dava parametre, ... vzdy ZLE. To ORM mi dovoluje kludnejsie spavat. Keby sme mali robit veci bez neho uz si tu trham vlasy. Prave tu sedim za projektom, stredna velkost, servisna vrstva (NO GUI) 420.000 riadkov kodu, 412 entit, par ludi, pol roka roboty. Neviem si predstavit robit to v SQL a rucne mapovat. Optimalizovali sme txLedger v uctovnictve (vela pohybov) a nejake davkove spracovanie, mozno zopar dalsich veci. Inac vsetko ostatne standardne ORM. Takze max 10% rucnych optimalizacii - a to sa stale bavime o HQL. Cisteho SQL (complexny update v uzavierke, ..), zopar vynimocnych pripadov. Kazda entita podporuje Paging, Versioning, Auditing.

    "Nebo co si mám představit" v tomto pripade napriklad fetch plan. Pre danu busines funkciu potrebujem a->c, a->d, a->b->q, pre inu iba a->c.

  • 17. 11. 2016 20:27

    Filip Jirsák

    Už jsem to psal několikrát, takže to napíšu naposledy – ano, pro menší projekty, jaké popisujete, může být ORM v současné době stále ještě přínosné. Problém je, že ORM neškáluje – například proto, že se před programátorem pokouší skrývat databázi, a jak se má někdo naučit používat složitější konstrukce, když jsou před ním skrývány ty jednoduché. Nebo proto, že když musíte opustit automaticky generované příkazy a HQL a potřebujete použít nativní SQL, začnete mít problémy s tím, že ORM nemá moc rádo, když mu něco měníte pod rukama.
    Jinak důvod, proč je ORM divné, je také v tom, že ORM se snaží relační databáze prezentovat jako úložiště objektů. Tak buď se je lepší ukládat objekty, a pak je divné to násilím mapovat do relační databáze a asi by stálo za to úsilí věnované do ORM raději investovat do objektových databází, nebo má ukládání do relačních databází své výhody, a pak je divné je pomocí ORM skrývat.
    O ručním mapování tu píšete jenom vy, samozřejmě existují knihovny na zkopírování hodnot z výsledku dotazu do vlastností objektu nebo z vlastností objektu do parametrů příkazu.
    Rozsáhlé skládání dotazů, které vede na velké množství různých dotazů, je špatné samo o sobě, a nezáleží na tom, zda je skládá ORM nebo někdo ručně. Protože na velké množství dotazů těžko můžete optimalizovat databázi. A navíc to vypovídá o tom, že asi uživatelům neposkytujete ty údaje, které potřebují, takže to musí řešit „vytvářením“ (prostřednictvím aplikace) velkého množství dotazů. Různorodé dotazy mají význam v případě analýzy dat, ale to je trochu jiná disciplína a k použití ORM tam není už vůbec žádný důvod.
    V tom příkladu s fetch plánem nějak nevidím, v čem by se použití ORM mělo lišit od nativních dotazů.

  • 17. 11. 2016 20:40

    Heron

    Proč se vlastně na ORM používají relační databáze (postavené na relační algebře a ne na objektech), když by se daly použít třeba objektové nebo grafové databáze (a uložit tam přímo strukturu objektů z nějakého OOP jazyka)? Zná někdo ten důvod?

  • 17. 11. 2016 20:56

    Pavel Stěhule

    Pak už by to nebylo ORM :) - V korporátním prostředí se pro aplikační programování prosadila Java s čistě objektovým paradigmatem. Objektové databáze se v korporátu skoro neprosadily - pár pokusů se proti IBM, Oraclu a Microsoftu nikdy neprosadilo. Takže tu jsou dvě relativně neslučitelné (ale neprotiřečící si) koncepce, které mělo něco sloučit - pokud možno něco, co bude dobře znít uším managerů - s ORM nepotřebujete drahé experty na Oracle, DB2, ...

  • 17. 11. 2016 21:07

    Heron

    V korporátním prostředí se pro aplikační programování prosadila Java s čistě objektovým paradigmatem.

    Dobře, tak tu otázku můžeme rovnou posunout dál. Proč se relační data nejprve ukládají do objektů a potom opět do relací?

  • 17. 11. 2016 21:27

    Inkvizitor (neregistrovaný)

    Protože Java (a další jazyky) nemají nic lepšího než třídy?

  • 18. 11. 2016 4:49

    Pavel Stěhule

    Ono by OOP nemuselo být apriori špatně - chyba je, že se snaží ohnout práci s relační databází na ISAM postup - iterace nad záznamy. Výchozí úroveň objektu odpovídá záznamu - a programátor dál může programovat iterace, tak jak je zvyklý - a to je na tom to špatné. Kdyby výchozí objekt odpovídal relaci - tak by mapování bylo výrazně jednodušší - některé knihovny jsou takhle postavené - jestli se ještě jedná o ORM nebo nikoliv - to už bude opravdu hodně subjektivní - nicméně i s takovou knihovnou musí vývojář umět používat ten typ databáze, který je použit v projektu samostatně - byť jen proto, aby mohl udělat diagnostiku, aby mohl efektivně řešit problémy, aby se hloupě nenechal databází zatlačit do rohu, odkud není úniku ..

  • 18. 11. 2016 12:49

    ded.kenedy (neregistrovaný)

    Ono by OOP nemuselo být apriori špatně - chyba je, že se snaží ohnout práci s relační databází na ISAM postup - iterace nad záznamy. Výchozí úroveň objektu odpovídá záznamu - a programátor dál může programovat iterace, tak jak je zvyklý

    Rad bych jen dodal, ze ORM nejen ohyba praci s DB, ale i celkove mrvi objektovy navrh. Napr. vyzaduje neparametricky konstruktor (tj. je mozne vytvorit neinicializovany objekt) a nuti vytvaret gettery/settery pro vsechny atributy. U cehoz to obvykle take casto skonci. Takze ve skutecnosti takto namapovane objekty neobsahuji zadnou vlastni logiku a prisne vzato jsou to struktury. ...se kterymi se pracuje proceduralnim zpusobem.

    A kdyz se to shrne, tak rada projektu, ktera pouziva ORM, ve skutecnosti s daty nakonec nepracuje ani objektove, ani relacne.

  • 18. 11. 2016 12:07

    SB (neregistrovaný)

    Protože jste si pro objektový systém (třeba bankovní systém třeba v Javě) s objektovou povahou dat vybral relační uložení dat, takže musíte vymyslet, jak (téměř) všechny tyto informace rozložit a ponastrkat do tabulí a pak to stejné z těch tabulí zase vytahat a seskládat zpět.

  • 18. 11. 2016 12:02

    SB (neregistrovaný)

    Vy to pořád nechápete! Relační a objektový model nejsou 2 způsoby uložení jedněch dat, to jsou 2 různé podstaty dat! A protože jsou z podstaty jiné, je takovým problémem je převádět mezi sebou.
    Mimoto mícháte do sebe koncept ORM a implementaci ORM, neboť i experti z Oracle používají ORM.

  • 17. 11. 2016 20:56

    Filip Jirsák

    Protože relační databáze jsou desetiletími prověřené, ví se, co zvládnou, a pokud jim někdo svěří důležitá data, určitě nebude v případě problémů popotahován za volbu neověřené technologie. Objektové nebo grafové databáze jsou v porovnání s relačními databázemi pořád spíš experimentem. Druhá věc je pak to, že spousta informačních systémů jsou vlastně různé evidence, které se dobře modelují v relačních databázích. Nepřirozené jsou tam spíš ty objekty – pro mne je spíš otázka, proč se u webových aplikací vůbec dělá ten objektový mezistupeň, místo aby se data z relační databáze rovnou transformovala do HTML/XML/JSON a opačně.

  • 17. 11. 2016 21:05

    Heron

    Druhá věc je pak to, že spousta informačních systémů jsou vlastně různé evidence, které se dobře modelují v relačních databázích.

    Ano, ale to vůbec neodpovídá této diskusi, kdy jsou tady někteří skalními příznivci datových objektů.

    pro mne je spíš otázka, proč se u webových aplikací vůbec dělá ten objektový mezistupeň, místo aby se data z relační databáze rovnou transformovala do HTML/XML/JSON a opačně.

    Ano, to je přesně ono. Data, která jsou více nebo méně v přirozené relační formě se nejdřív v jedné vrstvě převedou na objekty a potom se ty objekty mapují na relace. Praštěné na hlavu.

    Já ORM považuju za zlo (na počátku projektu vypadá že pomůže a potom už je to jen koule na noze) a nikde to samozřejmě nemáme. Tak jsem poněkud zaskočen touto diskusí, kdy někteří vypadají, že bez ORM nevyjdou z domu.

    Taky je to asi tím, že v PG je hromadu let možnost ukládat i nerelační data (hstore, teď json), takže nestrukturovaná data rvu rovnou tam.

    Tak jsem trochu čekal, že ORM má trochu hlubší smysl než jen v tom, že "máme nasazenou SQL databázi a nic dalšího tady nebude".

  • 18. 11. 2016 12:12

    SB (neregistrovaný)

    Nikdo neříká, že musíte používat hned objektové či grafové DB, přístupnější jsou dnes dokumentové DB, které už jen tím, že umějí ukládat uvnitř dokumentu seznamy, což RDB nedokáže (překvapení?), tak mají nepoměrně jednodušší mapování objekt <-> dokument.

    Napište příklad nějaké evidence, která je z povahy relační.

  • 18. 11. 2016 13:47

    Filip Jirsák

    Napište příklad nějaké evidence, která je z povahy relační.
    Je možné, že je to jen zvyk a síla relačních databází, které dokázaly relační model propašovat až do uživatelských modelů. A že by to tedy z uživatelského hlediska šlo modelovat i jinak. Ale v současné době bych asi těžko hledal evidenci, která relační není. E-shop – seznam zboží, zboží je v kategoriích, seznam zákazníků, zákazník má seznam objednávek, v objednávce je seznam zakoupeného zboží. Fakturace – seznam faktur, z každé faktury odkaz na dodavatele, seznam položek faktury. Sklady – zase seznam typů položek, seznam umístění a vazba kolik položek kde leží. Evidence osob – seznam osob, seznam adres, osoba má různé typy adres (trvalý pobyt, korespondenční, fakturační). A uživateli se to vždy prezentuje jako seznam vybraný podle nějakých kritérií, zvolím si jeden záznam, vidím jeho detail a v něm zase odkaz na jiný seznam nebo jiný záznam.

  • 18. 11. 2016 14:22

    Ladislav Thon (neregistrovaný)

    Nemůžu se vyjadřovat k těm ostatním tématům, ale relační fakturace je mýtus. Faktury, a obecně účetní doklady, jsou z povahy věci dokumenty. Položky faktury samy o sobě nedávají žádný smysl, ale musí být v samostatné tabulce, protože ... bagr. Položky faktury patří na fakturu. V dokumentovém světě žádný problém. V relačním -- nelze. S adresami na fakturách je to mimochodem taky zajímavé -- adresa samozřejmě na první pohled patří k nějaké osobě, na kterou má být z faktury vazba, jenže adresa osoby se v čase mění, takže z faktury bude buďto vazba na verzi adresy (koncept umělý a navíc omezující), nebo se spíš ta adresa na fakturu zkopíruje. Ostatně je i na tom papíře.

  • 18. 11. 2016 15:12

    Heron

    S adresami na fakturách je to mimochodem taky zajímavé -- adresa samozřejmě na první pohled patří k nějaké osobě, na kterou má být z faktury vazba, jenže adresa osoby se v čase mění, takže z faktury bude buďto vazba na verzi adresy (koncept umělý a navíc omezující), nebo se spíš ta adresa na fakturu zkopíruje.

    Nevím, proč by verze adresy měla být umělý koncept. Lidé se stěhují zcela běžně. Dokonce lidé mění i jména. Toto dodnes vývojáři různých systémů pro správu kontaktů nepochopili, takže pokud chci evidovat, že se někdo přestěhoval, tak to musím různě ohýbat. Přitom by bohatě stačilo, kdyby daný typ adresy byl prostě jen seznamem adres s různými rozsahy platnosti. Totéž u jména. Nejedná se jen o (typicky) ženy po svatbě, znám lidi, kteří si nechali kompletně změnit jméno i příjmení. Dokonce i města mění jména. A zkuste to zadat do nějaké programu kontaktů... V lepším případě pouze exploduje celý vesmír.

  • 18. 11. 2016 16:27

    j (neregistrovaný)

    "Nevím, proč by verze adresy měla být umělý koncept."

    Oni soudruzi vyvojari jeste stale nepochopili, ze i jeden clovek muze mit klidne 10telefonu, a 15 emailu ... takze tak maximalne naflakaj do tabulky 2-4 sloupce, a ... "si to tam napisete a oddelte treba strednikem ne ..." s cimz se vazne bezvadne pracuje.

  • 18. 11. 2016 16:49

    Heron

    Oni soudruzi vyvojari jeste stale nepochopili, ze i jeden clovek muze mit klidne 10telefonu, a 15 emailu ... takze tak maximalne naflakaj do tabulky 2-4 sloupce, a ... "si to tam napisete a oddelte treba strednikem ne ..." s cimz se vazne bezvadne pracuje.

    Mě na tomhle vlastně nejvíc fascinuje ta psychologie. Ti lidi sami mají běžně x mailů a y telefonů, ostatně pro to píšou i appky, vyměňují firmware a podobně. A teď by mě zajímalo, co přesně se musí stát, aby člověk, který ví že je na světě víc než jedna adresa, tu appku napsal takhle blbě. Jako to jim vypadne mozek z hlavy? Fakt nevím.

    Ad napište a oddělte středníkem. Tady někde probíhala diskuse o validování a konzistenci dat. Normálně napsaná aplikace by nic takového nepřipustila. Prostě v poli emailová adresa bude emailová adresa a ne Babička od Božky.

    Jednou jsem v poli telefon našel záznam: 'stejný jako sousedka'.

  • 21. 11. 2016 9:49

    j (neregistrovaný)

    "Jednou jsem v poli telefon našel záznam: 'stejný jako sousedka'."
    ... normalka, to uz me vubec nevyvede z miry, takovych zaznamu v tech databazich co k nim mam pristup sou tisice. A pak se soudruh managor strasne divi, ze jeho novy uzasny telefonni system ktery ma zaznamenavat hovory aby si on moh kreslit nesmyslne grafy ... nezaznamenava vubec nic.

  • 21. 11. 2016 16:51

    SB (neregistrovaný)

    Další příklad, proč je to v RDB složitější - když potřebuju seznam emailů (bez požadavku na složitější zpracování), v dokumentové DB uložím v dokumentu jejich seznam. Triviální. Ne tak v RDB, tam buďto dám jeden sloupec, odkud si to vylámu, nebo nadimenzuju několik sloupců, nebo udělám extra tabulku, která povede VŠECHNY seznamy emailů všech osob. Každé z těchto 3 řešení je horší nebo složitější.

  • 21. 11. 2016 16:42

    SB (neregistrovaný)

    Verze adresy daného subjektu v čase jsou jako koncept určitě v pořádku, ale může to být i složitější (více platných adres, typy adres, ...).
    Jméno má být jen vlastností identické osoby, proto se může měnit bez změny identity.

  • 18. 11. 2016 15:32

    Pavel Stěhule

    Samozřejmě, že i v relačním světě můžete pracovat s historií - buďto ručně - přidáte si informaci o platnosti, nebo to už podporují některé databáze přímo - viz temporální databáze, případně dneska i část ANSI/SQL - http://www.slideshare.net/CraigBaumunk/temporal-extensions-tosql20112012010438

  • 22. 11. 2016 9:06

    SB (neregistrovaný)

    Že by další dolepování SQL posilující zabetonování aplikační logiky do databáze?

  • 22. 11. 2016 9:19

    Pavel Stěhule

    Pokud mám databázový systém, který mi umožňuje implementaci logiky, tak proč ně? Rozbíjí se tím monolitický design, zvyšuje se tím reuse, operace s daty se dělají blízko datům.
    Když se podíváte na Hadoop like systémy, tak byť jsou napsané v Javě, tak používají koncept podobný uloženým procedurám - stěhují algoritmus na databázový server - blíž k datům. U velkých dat je mnohem praktičtější přesunout výpočet než přesouvat data.
    Samozřejmě, že ne každá technologie je dostatečně vyspělá, aby mi umožňovala plnohodnotné programování - to, co nabízí Oracle, DB2, Postgres ale programátora nijak neomezuje. Předpokládám, že až NoSQL databáze trochu vyspějí, tak sofistikovanější API budou nabízet také.

  • 18. 11. 2016 16:23

    j (neregistrovaný)

    "ale relační fakturace je mýtus"
    what? polozky faktury patri = maji relaci, k te konkretni fakture, na polozkach je relace na konkretni sluzby nebo zbozi, relace na cenotvorbu atd atd.

    Ze nekdo neumi navrhnout strukturu je jeho (a zdaleka ne jen jeho) problem. Firmu v databazi reprezentuje nejaky zaznam firmy, adresa neni jeho soucasti, protoze adres v relaci k tomu zaznamu muze byt N. Soucasti faktury je pochopitelne nejen realace na zaznam "firma", ale prave relace na zaznam "adresa firmy". Pokud se firma prestehuje, tak jen pribude dalsi zaznam adresa, a maximalne se nekde nastavi jako vychozi. Takze vsechny stavajici faktury si podrzi spravne udaje. Nemluve o tom, ze jako "bonus" nepotrebuju mit dalsi sloupce s adresama soukromych osob ... protoze adresa je proste zaznam v tabulce adres.

    Ano, spousta vyvojaru sou prasata bez mozku, ktery neco takhle primitivniho nedokazou pochopit, natoz vytvorit.

    To vubec nemluvim o moznosti vsechny pripadne zmeny auditovat (v tech relacich, neb vzdy patri ke konkretnimu zaznamu), a pak lze kdykoli zobrazit stav libovolneho zaznamu k libovolnemu historickemu datu.

  • 22. 11. 2016 9:15

    SB (neregistrovaný)

    Obávám se, že ve vašem případě jde o klasickou záměnu pojmů: Termín „relace“ (ang. relation) neznamená vztah (ang. relationship), ale „n-tice“. Takže „polozky faktury patri = maji relaci“ je nesmysl, položky mají vztah (k faktuře), ale podstatou se nejedná o n-tice, ale objekty/uzly grafu s hranami - vztahy. Takže tvrzení „ale relační fakturace je mýtus“ znamená „ale n-ticová fakturace je mýtus“ a je správné.

  • 22. 11. 2016 11:55

    ded.kenedy (neregistrovaný)

    Termín „relace“ (ang. relation) neznamená vztah (ang. relationship), ale „n-tice“

    Nemate pravdu. Relace = mnozina n-tic.

  • 21. 11. 2016 11:46

    Karel (neregistrovaný)

    Faktura jsou mrtvá data. Adresa v ní musí být uložena, stejně jako ceny atd. Takže faktura vlastně je dokonalý příklad dokumentu.

    Něco jiného je objednávka, výrobní příkaz apod. Tam je část dat uložena (kusovník, vytvoření kopií z TPV), ale plno dalších je tam referencí (účetní hodnota komponent, nákladová střediska atd.)

    V každém případě je ale model stále relační. I když mám popisek položky vykopírovaný do faktury (aby dodatečný tisk vypadal přesně tak jako originál), tak je tam pořád relace na id položky. Takže mohu kdykoliv spouštět dotazy typu "kdy, komu a kolik jsem fakturoval za položku XY". To je něco, co v dokumentové databázi nefunguje levně. Vyhledáváte podle atributu. Přidejte si dotazy podle zákazníka, země dodání, kódu DPH, dopravce atd.

    A to ta faktura má ještě reference do účetnictví. Jedna faktura může mít více účetních dokladů, na jednom dokladu může být více faktur, faktura se páruje s platbami, pokud se neplatí rychle, tak se musí účtovat kurzové rozdíly atd. Prostě roste vám počet dokumentů, které spolu mají nějaké relace. Rychle se dostanete do stavu, kdy se vám ty dokumenty vyplatí cpát do relační databáze.

    A v adresách se vám motají dvě věci: číselník adres a registr dodavatelů/od­běratelů atd. V ERP se to běžně spojuje do jednoho, ale stále to jsou dvě různé věci. To první jen říká nějakou výchozí adresu dodací, výchozí adresu fakturační, výchozí platební podmínky atd. Na objednávkách se to vykopírovává a pak se to může přepsat. Ten registr je pak o kreditu, kontaktech atd. Zda chcete 400x denně vypisovat tu samou adresu, to je vaše volba. Ale pokud chcete sledovat výši a čerpání kreditu zákazníka, pak se bez "umělého a omezujícího konceptu" číselníku zákazníků neobejdete.

  • 22. 11. 2016 9:42

    SB (neregistrovaný)

    „Faktura jsou mrtvá data. Adresa v ní musí být uložena, stejně jako ceny atd.“
    Chyba - 1. přijdete o identitu adresy, 2. to bude velké. Buďto víte, kdy byla faktura vystavena a adresa je ta platná k tomuto okažiku daného subjektu, nebo ji můžete ze subjektu explicitně označit a zachováte její identitu (a ještě je to menší). Kopírovat není nic třeba.

    „ I když mám popisek položky vykopírovaný do faktury...“
    Ta samá chyba. Položka má identitu a je dán její název buďto napořád (objekt je modelován jako immutable), nebo v času (mutable). Vykopírovávat není nic třeba.

    „To je něco, co v dokumentové databázi nefunguje levně. Vyhledáváte podle atributu.“
    V dokumentové DB si buďto držíte seznam všech položek, ve kterých hledáte (obdoba RDB, nevhodné), nebo v případě, že potřebujete často zjišťovat faktury s položkou, si pro položku držíte seznam faktur (v RDB nejde). Pak nehledáte nic!

    Záměna termínů vztahy - relace.
    Naopak, čím více vztahů máte, tím hůře se modelují v RDB (zde jsou nutné při JOINech prohledávané vazební tabulky) a je vhodnější je ukládat do DB, která umí seznamy (odstraňuje vyhledávání).

    Už zase něco vykopírováváte? Jak potom u faktur zjišťujete shodu adres, když jste přišel o identitu? Porovnáním hodnot???
    Číselník je koncept z RDB pojmenovaný dle vnitřního označení relace řešeného obvykle číslem (přestože to často bez problémů může být řetězec), v objektovém modelu nic takového není, ten používá seznam s položkami s identitou. Je vidět ten rozdíl?

  • 22. 11. 2016 11:42

    ded.kenedy (neregistrovaný)

    Číselník je koncept z RDB pojmenovaný dle vnitřního označení relace řešeného obvykle číslem (přestože to často bez problémů může být řetězec),

    číselník je pojem, který se používal mnohem dřív než nějaké databáze vůbec vznikly

  • 21. 11. 2016 16:37

    SB (neregistrovaný)

    Faktury nejsou dokumenty (jestli se bavíme ve smyslu DB), ty nemají implicitní vazby na související entity, ale objekty, případně uzly grafu, ty vazby mají. To samozřejmě neznamená, že je do dokumentu nejde (jako do relací) explicitně uvést.
    „Položky faktury patří na fakturu. V dokumentovém světě žádný problém. V relačním -- nelze.“
    Přesně to jsem psal v předchozí odpovědi - RDB NEUMÍ ukládat implicitní seznamy, řeší to explicitně cizími klíči!
    Adresa má být namodelována jakkoli jako součást měnícího se subjektu (způsobů je více).

  • 21. 11. 2016 16:30

    SB (neregistrovaný)

    A to je přesně ono: To, co jste popsal, je objektovým systémem s vyjmenováním vzájemných vztahů prvků, to není relační model!
    Co se stane, když to narvete do RDB? Implicitní, přímé paměťové vazby musíte rozpojit a nahradit explicitními klíči, které je třeba dohledávat (to je i u dokumentové DB, ale ne např. u objektové DB), ale především např. položky faktury už nejsou uloženy v krátkém seznamu faktury, ale v jedné obrovské tabulce se VŠEMI ostatními položkami všech faktur, kdy je třeba dle klíče EXPLICITNĚ sestavovat jejich seznam, protože RDB seznamy ukládat neumí (dokumentová i objektová DB to umějí). V případě, že každá položka faktury (či jiná entita) je trochu jiná (což je zcela běžné), tak budete navíc řešit, jak narvat polymorfní prvky do jedné tabulky, nebo je rozstrkávat do více tabulek. Změna struktur za chodu systému je další věc, která u RDB vzhledem ke schematičnosti nejde. Vazby m:n je třeba řešit vazební tabulkou, vazby 1:n je třeba někdy otočit z 1->n na 1<-n, protože opět seznam nejde uložit, takže místo aby faktura odkazovala na svoje položky (v dokumentové DB standard), musím opačně v položkách uvést fakturu. Atd. Neboli relační model je zcela jiný než objektový.

  • 22. 11. 2016 9:44

    Heron

    Implicitní, přímé paměťové vazby musíte rozpojit a nahradit explicitními klíči

    Co si představujete pod výrazem "přímé paměťové vazby"? Jestli jako odkaz z jedné datové struktury (místa v paměti) na jinou datovou strukturu, třeba jako v C, tak toto si pomalu každý vyšší jazyk řeší po svém a u složitějších kolekcí už ten odkaz rozhodně není tak přímý.

    Jinými slovy, toto je pouze implementační detail. Propojit tři tabulky (n:m) pomocí klíčů je úplně stejný implementační detail.

    ale především např. položky faktury už nejsou uloženy v krátkém seznamu faktury, ale v jedné obrovské tabulce se VŠEMI ostatními položkami všech faktur, kdy je třeba dle klíče EXPLICITNĚ sestavovat jejich seznam, protože RDB seznamy ukládat neumí

    Jednak některé DB seznamy ukládat umí, ale především, čemu konkrétně vadí že ty položky jsou v jedné obrovské tabulce? Pokud potřebuju vytáhnout položky k dané faktuře, tak je to jeden join (kterej bude rychlejší, než mi dokumentová databáze vrátí jeden kompletní dokument - kterej je mimochodem taky uložený na disku v jednom obrovském souboru - a to včetně dat, který nepotřebuju). V čem má být problém?

  • 24. 11. 2016 15:43

    SB (neregistrovaný)

    „Co si představujete pod výrazem "přímé paměťové vazby"? Jestli jako odkaz z jedné datové struktury (místa v paměti) na jinou datovou strukturu, třeba jako v C, tak toto si pomalu každý vyšší jazyk řeší po svém a u složitějších kolekcí už ten odkaz rozhodně není tak přímý.“
    Programově tečku (ve Smalltalku mezeru), tj. odkázání triviálně názvem, vnitřně implementačně pointer na objekt (Smalltalk, jak si to řeší Java, netuším), tj. bleskově, každopádně nemá smysl řešit nějakou rychlost procesoru a paměti, rychlost práce DB s diskem je 100x pomalejší.

    „...Propojit tři tabulky (n:m) pomocí klíčů je úplně stejný implementační detail.„
    Vzhedem k tomu, že tu vazební tabulku musíte extra číst a dělat s ní JOIN (tj. hledat v ní), tak to určitě není pouze implementačním detailem.

    „Jednak některé DB seznamy ukládat umí...“
    Ale o těch tu nikdo neuvažoval.

    „...ale především, čemu konkrétně vadí že ty položky jsou v jedné obrovské tabulce?“
    Že je musíte v indexu cizího klíče se statisíci záznamy nejdřív najít.

    „...je to jeden join (kterej bude rychlejší, než mi dokumentová databáze vrátí jeden kompletní dokument...“
    Čtení dokumentu jako celku (dle klíče) je velice rychlé, je to jediný, celistvý kus dat.

  • 24. 11. 2016 16:13

    Heron

    Vzhedem k tomu, že tu vazební tabulku musíte extra číst a dělat s ní JOIN (tj. hledat v ní), tak to určitě není pouze implementačním detailem.

    To je implementační detail. Jestli v nějakém jazyku napíšete objekt.neco (a ono se v pozadí vykoná magie nad pamětí toho programu), nebo zavoláte metodu get_data() a v té si napíšete select neco from neco join neco where neco, tak je to jen implementační detail. To, že tu magii nad kolekcemi objektů (ve vyšších jazycích) nevidíte neznamená, že tam není.

    nemá smysl řešit nějakou rychlost procesoru a paměti, rychlost práce DB s diskem je 100x pomalejší

    Aha, takže tatáž data jednou předpokládáte v paměti a podruhé na disku. A do té paměti se dostala jak? I relační db může mít data v paměti a většinou se i snaží, aby tam byla.

    Že je musíte v indexu cizího klíče se statisíci záznamy nejdřív najít.

    vs.

    Čtení dokumentu jako celku (dle klíče) je velice rychlé

    Takže v případě relační db použití indexu vadí zatímco v případě jiné db použití (většinou stejně naimplementovaného indexu) nevadí.

    je to jediný, celistvý kus dat

    A to je právě to. Ten dokument může být velký stovky MB. Takže rychle vyhledáte (podle indexu) jeden celistvý dokument, ve které máte všechno a načíst to z disku trvá.

    Relační db vznikly proto, aby se ukládalo (proto normální formy) a četlo (proto vhodné dotazy) minimum dat. Takže na stejnými daty zavolám vhodně napsaný dotaz a vrátí se pouze to minimum, co chci. To, že je součástí dat i fotodokumentace mě v danou chvíli nezajímá a db server to ani nemusí číst. Pokud by to bylo v jednom dokumentu, tak se to čte vše.

  • 28. 11. 2016 15:18

    SB (neregistrovaný)

    Zas mícháte dohromady práci v paměti a DB - v paměti (objekt.metoda) mě optimalizace nezajímá, v DB (select ...) ano, protože tam je každé čtení z disku navíc znát. Takže to, co máte v paměti aplikace, musíte rozlámat na kousky, které jdou nastrkat do DB. Podle toho, jak to rozdělíte, to bude rychlé.
    Ano, zde máte pravdu, oboje je přes index, takže podobně rychlé. To jsem si neuvědomil.
    Jestli máte běžný dokument velikosti stovek MB, něco je špatně. Průměrný normalizovaný dokument může být kolem kilobajtů až desítek KB.
    Normální forma není vázaná na RDB, jak si někteří myslí, normalizovaný či denormalizovaný dokument jde stejně dobře udělat i v dokumentové či objektové DB či v objektu v paměti. Rovněž ve čtení nepotřebných dat není RDB nijak vyjímečná, každá DB čte záznamy v nějakých skupinách, protože po položkách se to nevyplatí řešit (a z pohledu objektů je to přímo nekoncepční). Zrovna RDB obsahuje při mapování obecných objektů na relace (v případě obecné tabulky) sloupce, které se plní jen někdy. Velká data nemusíte nutně v dok. DB včlenit do dokumentu, stačí je vést samostatně. V objektové DB je to automaticky, protože i ta data jsou objektem (např. obrázek).

  • 22. 11. 2016 11:49

    ded.kenedy (neregistrovaný)

    Implicitní, přímé paměťové vazby musíte rozpojit a nahradit explicitními klíči, které je třeba dohledávat

    FYI, a votom to je. Relační model sjednocuje uložení dat a vztahu mezi nimi do jedné struktury = relace. Nepotřebuješ mít extra strukturu pro data a extra pro vazbu mezi nimi (seznam). A díky tomu si všechny operace zjednodušíš.

    protože RDB seznamy ukládat neumí

    jelikož základní entitou, se kteoru RDB pracují je relace, tj. množina, je naivní požadovat, aby pracovala se seznamem

  • 24. 11. 2016 16:28

    SB (neregistrovaný)

    „...Nepotřebuješ mít extra strukturu pro data a extra pro vazbu mezi nimi (seznam). A díky tomu si všechny operace zjednodušíš.“
    Nezjednodušíte si nic, protože mezitímco dle seznamu klíčů hledáte v indexu dok. DB (collection), v RDB hledáte dle klíče v indexu tabulky, takže to vyjde podobně. A s tím tykáním opatrně.

    „relace, tj. množina“
    Relace je n-tice, ne množina.

  • 18. 11. 2016 14:32

    Zdeněk Merta (neregistrovaný)

    > Objektové nebo grafové databáze jsou v porovnání s relačními databázemi pořád spíš experimentem.

    Tohle bych si nedovolil říct. Spíš myslíte Objektově-orientované databáze.
    Objektové databáze jsou trošku něco jiného, jsou tu celkem dlouho a jejich základ vznikl dříve než relační databáze.
    Za průkopníka můžeme považovat MUMPS (rok 1966), který se i v současnosti hojně používá

    > Druhá věc je pak to, že spousta informačních systémů jsou vlastně různé evidence, které se dobře modelují v relačních databázích

    Minimálně stejně dobré jsou právě "objektové databáze". Zmiňovaný MUMPS ukládá data do hierarchických struktur.
    Používá se ve zdravotnictví a v bankách a jsou vhodné pravě na různé evidence.
    V hierarchické databázi navíc není problém emulovat relační i dokumentované databáze. Dají se i grafové, ale už to není tak triviální.

  • 18. 11. 2016 11:46

    SB (neregistrovaný)

    Ta otázka nedává smysl, ORM slouží pouze konverzi relace <-> objekty. Pro objektové DB není z podstaty věci třeba nic konvertovat. Pro dokumentové DB se používá ODM (object-document mapping, které je značně jednodušší oproti ORM). Atp.

  • 21. 11. 2016 11:25

    Karel (neregistrovaný)

    ORM je tu desítky let. Byla to dočasná obezlička. Aplikační logika byla objektová, ale neexistovaly rozumné objektové databáze. Oproti tomu relační databáze tu byly, fungovaly a "měl je každý". Takže se v devadesátých letech začalo prosazovat ORM, které mělo fungovat těch pár let, než se prosadí plně objektové databáze.

    Bohužel se za těch 20 let trochu vytratila ta informace, že se jedná o nedokonalou dočasnou berličku, a řada firem a lidí se to snaží tlačit jako plně funkční nástroj. Na druhou stranu ale taky co dělat jiného, když silné objektové databáze stále nemáme. Tak snad se nějaká z nich prosadí a ORM konečně odejde do historie tak, jak bylo plánováno již v minulém tisíciletí, kdy jsem ještě navštěvoval konference.

    https://cs.wikipedia.org/wiki/Konference_Objekty

  • 22. 11. 2016 9:49

    SB (neregistrovaný)

    Tak v tomhle s vámi víceméně souhlasím.
    Objektové DB tu zatím moc nemáme, ale alespoň jsme se posunuli k dokumentovým, do kterých je mapování objektových modelů MNOHEM jednodušší a přímější.

  • 18. 11. 2016 11:29

    SB (neregistrovaný)

    „ORM nemá prostředky k tomu vytvářet efektivní dotazy. ORM vytváří dotazy podle struktury objektů – zda ten dotaz bude nebude efektivní je pouze věcí náhody.“
    To je samozřejmě nesmysl, efektivita dotazů bude tak velká, jak chytré ORM vytvoříte, různých optimalizací se dá navymýšlet spousty, vzhledem k nekompatibilitě relačního modelu s objektovým a různým implementacím je to bezednou studnicí.

  • 18. 11. 2016 13:35

    Filip Jirsák

    To je samozřejmě nesmysl, efektivita dotazů bude tak velká, jak chytré ORM vytvoříte, různých optimalizací se dá navymýšlet spousty, vzhledem k nekompatibilitě relačního modelu s objektovým a různým implementacím je to bezednou studnicí.
    Psal jsem o současných implementacích. Ano, je možné uvažovat o ideálním ORM, ale pak je otázka, zda není lepší uvažovat o ideální objektové databázi.

  • 17. 11. 2016 11:54

    Palo (neregistrovaný)

    A este jedna vec: "Stránkování je nezajímavá trivialita", podobne ako dnes spomenute JOIN, funcie nad stlpcom, autoincrementalne ID, left/full join. Kolko naivnych "RYCHLYCH" SQL kodov som ja uz videl. Namiesto vyberu celeho agregovaneho objektu vratane relacii dotahovanie jednotlivych podobjektov lebo programator je lenivy pre kazdy pripad robit a UDRZIAVAT specialny dotaz s velkym mnozstvom joinov, radsej to dotahuje jednotlivo aj ked vie ze vsetky tie udaje bude potrebovat. Tam je jadro problemu. A preto hovorim ze dobry programator to bude mat urobene rovnako dobre v ORM ako v SQL ale rychlejsie a prehladnejsie, zly programator to v SQL domrsi hroznym sposobom a moze sa tomu lahko vyhnut pouzitim ORM.

  • 18. 11. 2016 11:17

    SB (neregistrovaný)

    ORM není abstrakcí, aby bylo možno použít různých RDB, naopak, jak už název říká, jde o překlad dat z přesně daného objektového formátu do přesně daného relačního formátu! S abstrakcí to nemá co dělat.

  • 18. 11. 2016 12:17

    Zdeněk Merta (neregistrovaný)

    Ad: Optimalizace pomocí Lazy Loading, Eager Fetch, ...

    Jak v ORM řešíte případy, kdy pro jeden scénář potřebuji Lazy Loading a pro druhý třeba Eager Fetch?

  • 18. 11. 2016 23:16

    Uživatel ORM (neregistrovaný)

    To řešíme tak že Lazy Loading je default a pokud píšeme dotaz který bude vytahovat hodně záznamů kde vidíme že by Lazy Loading byl neefektivní (dotahoval by podřízené záznamy extra ke každému nadřízenému záznamu) tak u konkrétních dotazů vynutíme Eager Loading (dotažení všech podřízených záznamů najednou a roztřídění k nadřízeným záznamům v ORM).

  • 18. 11. 2016 10:45

    SB (neregistrovaný)

    „ORM je naprosto zbytečná vrstva...“
    Jo? A jak zrekonstruujete objekty bez ORM? Nebo tím snad chcete naznačit, že vaše aplikace pracuje s relacemi?

  • 18. 11. 2016 13:16

    SB (neregistrovaný)

    Opravdu? Popište mi tedy postup, jak zrekonstruujete objekt rozstrkaný do 2 tabulek, kdy první obsahuje primitivní data objektu bez seznamů a druhá obsahuje prvky seznamu (nekolika seznamů) z objektu.

  • 18. 11. 2016 14:46

    gll (neregistrovaný)

    Použiji obyčejný JOIN a nějakou knihovnu, která konvertuje řádky výsledku na objekty. Reprezentaci o které píšete téměř nikdy nebudu potřebovat, případně ji mohu vyrobit jednořádkovou transformací. Objektová reprezentace má smysl jen pokud něco zjednoduší.

  • 22. 11. 2016 9:55

    SB (neregistrovaný)

    „Použiji obyčejný JOIN a nějakou knihovnu, která konvertuje řádky výsledku na objekty.“
    Právě jste provedl/použil ORM.

  • 22. 11. 2016 12:18

    gll (neregistrovaný)

    To není pravda. Měl jsem na mysli něco takového:

    https://github.com/kennethreitz/records

    Dotazy zapisuji v SQL. Žádné definice modelů tam nejsou.Jak reprezentuji výsledky je nepodstatné.

  • 18. 11. 2016 13:22

    j (neregistrovaný)

    Bych tak nejak (zjevne mylne) cekal, ze vyvojar vi, jak vypada jeho aplikace, a stejne tak vi, jak vypada databaze, pricemz jedno i druhe navrhuje s vedomim toho, k cemu to bude a jak to bude fungovat.

  • 18. 11. 2016 10:42

    SB (neregistrovaný)

    „Objektove a NoSQL databazy neriesia mnohe z toho co relacne databazy zvladaju s lahkostou.“
    Co to je? (Předpokládám, že se bavíme o persistenci pro komplikované objektové systémy, ne o ukládání dat meteorologických stanic.)

  • 18. 11. 2016 10:37

    SB (neregistrovaný)

    1. Předpokládám, že za NoSql myslíte nerelační.
    2. Tvrzení „Jsou situace, kdy se NoSQL databáze mohou hodit.“ považuju za (slušně řečeno) hodně odvážné v situaci, kdy obrovské množství systémů v IT zpracovává objektová data (obchodní systémy) a snaží se je s obrovskými a stále se vracejícími problémy narvat do RDB.
    3. Z toho mi vyplývá, že jako já považuji, vy nepovažujete za jeden z největších omylů IT snahy o ukládání objektových dat do relací, ale ORM (či některých jeho nakynutých implementací?), které je jen řešením daného rozhodnutí a za nic nemůže.

    O čem se tu potom chcete bavit? Postopadesáté o tom, jak narvat objektová data do RDB a jak se je pak pokusit přečíst?

    P. S.: Předpokládám, že tu dost lidí bude prskat, ale rozvrstvení informatické populace je přece známé.

  • 18. 11. 2016 10:54

    Pavel Stěhule

    Neexistuje nic jako objektová data, stejně tak relační data - máte jen nějaký způsob, jak reálný svět zpracováváte - můžete mít objektový model, můžete mít relační model.
    Aktuálně řeším problém v jedné firmě, kde jsou těžké problémy s aplikací - primárně proto, že je některé věci jsou úplně blbě, jiné roky neřešené. Problémy nejsou v relační databázi, ale v amatérismu lidí, co psali tu aplikaci - je to stejné, jako když dáte opravit auto lemplovi, tak spláčete nad výdělkem.
    NoSQL databáze jsou z principu výrazně pomalejší než relační databáze - mají ale jednu výhodu - snadno škálují - takže místo jednoho serveru můžete mít 10, 100 serverů, atd. Pro aplikace typu LinkedIn, Facebook to má jasný přínos - navíc v těchto aplikacích nemáte fakticky nemáte žádnou evidenci - data jsou opravdu skrumáž atributů. Pro mne jsou ale tyto aplikace výjimky potvrzující pravidlo.
    U NoSQL snadno zapisujete, snadno děláte updates, můžete relativně snadno zajistit vysokou dostupnost. Ale už spočítat report, který by vyžadoval konzistentní data a vracel konzistentní výsledky je téměř nemožné - a výrazně pomalejší než nad relační databází.

  • 18. 11. 2016 13:39

    SB (neregistrovaný)

    Chcete snad říci, že n-tice dat vypadávájící z průmyslového měřicího systému s minimálními či žádnými vazbami na další entity mají stejnou strukturu jako informační systém společnosti s hustě vzájemně propojenými nehomogenními a dokonce se strukturálně měnícími entitami?!!! Už sama existence složitosti ORM vás usvědčuje z toho, že opět kecáte.
    Databáze NoSQL jsou pomalejší pouze v prohledávání dat v důsledku jejich volného uložení, tato nevýhoda se však často stírá vhodným modelem obsahujícím podseznamy souvisejících entit, které si ovšem RDB nemůžou dovolit, protože ukládání seznamů neumějí. Není důvod aby pomaleji hledaly dle klíče. Případné horizontální škálování (které v RDB neuděláte) jste zmínil sám.

    „Ale už spočítat report, který by vyžadoval konzistentní data a vracel konzistentní výsledky je téměř nemožné - a výrazně pomalejší než nad relační databází.“ Vy si snad děláte prdel! Jak můžete paušálně prohlásit, že v NoSQL bude něco pomalejší, natož že to nejde ani smysluplně spočítat?!

    Jestli se cítíte být relačníkem, přejmenujte článek na „Optimalizujeme model a dotazy RDB“ a vyhněte se systémům s databázemi NoSQL, nováčci se vyhnou tradovaným bludům.

    Určitě tu bude hodně nesouhlasu (rozložení IT pořád platí), ale snad to pomůže některým otevřenějším začátečníkům.

  • 18. 11. 2016 14:29

    pb. (neregistrovaný)

    Nad dokumentovou databází máme postavený jednoduchý informační systém. Zkušenosti s takovou databází?
    - je to pomalé, protože neexistují hromadné operace, například obdoba "delete from table where date < '2016-01-01'
    - agregace (select ... group by) - tj. obdoba reportu - se obvykle dá udělat, ale je to často takový opruz, že bych se na to mohl vyprdnout. Běh hotového reportu být pomalejší nemusí.
    - databázi máme rozloženou na zhruba deseti počítačích. Jak můžu udělat smysluplný a konzistentní report, když v každém počítači je v databázi něco trošičku jiného a obvykle bývá přístupná sotva polovina počítačů?

    Na druhou stranu distribuovaný charakter dat je v našem prostředí fantastická vlastnost, tady se může jít jakákoliv SQL databáze klouzat. S SQL databází bych nikdy nic podobného provozovat nemohl.

    Že dostanu reporty z neúplných dat? Příliš mě netrápí, že kolega ve svém vypnutém notebooku v batohu má data, ke kterým nemám přístup. V praxi se ukazuje, že každý dělá ve svém omezeném okruhu dat a reporty ke svým datům má obvykle konzistentní. Každý má na svém počítači něco jiného, časem se data nějakým způsobem utřepou a časem (v rozmezí dnů) stejně získám k datům kolegů přístup i já. Jenom s tím musím počítat.

  • 22. 11. 2016 10:05

    SB (neregistrovaný)

    Nebude chyba v tom, že s dok. DB pracujete jak s relační? Sekvenční procházení seznamů je bude asi vždy pomalejší oproti RDB (výměnou za bezschématovost), ale provádíte-li často hromadnou operaci dle nějaké vlastnosti, máte si udělat podle ní „index“/dicti­onary/map, pak je rychlost shodná s RDB.

    To rozložení po více počítačích jsem nepochopil - to, že dok. DB neřeší konzistenci, neznamená, že se na ni můžete ve vyšší vrstvě vybodnout.

  • 22. 11. 2016 10:16

    Pavel Stěhule

    Nezapomínejte, že každý index vás stojí něco málo místa (zanedbatelná cena) a výrazně vám zpomalí update, insert, delete. Indexy jsou v relačních i dokumentových databázích implementovány stejně - takže tam platí stejná pravidla.

  • 18. 11. 2016 15:18

    Pavel Stěhule

    Paušálně to mohu prohlásit z toho důvodu, že NoSQL databáze nemají žádné hromadné operace. Buďto jedete nad indexem, nebo si průběžně udržujete nějaké čítače, nebo zase speciální indexy, z kterých pak čtete data. Pracnost reportingu založeného na Map/Reduce je výrazně větší než použití SQLka.
    Už jen to, že Mongo jako analytický nástroj dodává Postgres říká o tom, jak jsou na tom NoSQL databáze co se týče reportingu.
    NoSQL databáze jsou zatím relativně nové -- cca 10 let - to vůči relačním db cca 30 rokům musí být znát. Osobně věřím, že za 10 let dojde mezi SQL databázemi a NoSQL databázemi k hromadě výpůjček. V tuhle chvíli je ale potřeba k NoSQL databázím říct i to b.

  • 22. 11. 2016 10:18

    SB (neregistrovaný)

    „NoSQL databáze nemají žádné hromadné operace“
    MongoDB: db.getCollecti­on('knihy').fin­d({autor: 'Ocas Ocasovič Ocasov'})

    „...jedete nad indexem...“
    V dok. a obj. DB se tomu říká seznam.

    „Už jen to, že Mongo jako analytický nástroj dodává Postgres říká o tom, jak jsou na tom NoSQL databáze co se týče reportingu.“
    Nejsou náhodou zpracovávaná data relační?

    „NoSQL databáze jsou zatím relativně nové -- cca 10 let“
    Jistě.

    „Osobně věřím, že za 10 let dojde mezi SQL databázemi a NoSQL databázemi k hromadě výpůjček.“
    Panebože, doufám, že ne!