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

[SB]

ActiveRecord vs. Data Mapper se liší v tom, kde je zapouzdřená kompetence za persistenci - zda spolu s daty (v objektu reprezentujícím data z business domény) anebo bokem (v data mapperu). Některá ORM umožňují použít oba přístupy (vybrat si, kterému dám přednost). Viz.:

Když se dívám na definici Active Recordu od Fowlera (https://www.martinfowler.com/eaaCatalog/activeRecord.html), musím se omluvit - myslel jsem, že je použit pouze jako mechanismus pro podržení mapované relace z RDB pro potřeby jednoduchého zápisu (v podstatě kopie relace), tj. objekt pro potřeby mapovače. Je to mnohem horší, má to být přímo doménový objekt. To je samo o sobě nesmysl, protože 1. neodděluje OM od RDB, 2. umožňuje mapování pouze primitivních objektů, které se vejdou do 1 relace (v praxi ne moc časté). Nenapadlo mě, že by se to někdo vůbec pokusil použít. Moje chyba.

[Reklama]

[Kit]

Když je to DataMapper, tak přece nemapuji objekty, ale data.

Samozřejmě, protože RDB objekty neumí, takže to chování musíte zadrátovat odděleně do aplikace. Objekt se pak při rekonstrukci v aplikaci skládá z toho chování z aplikace a těch dat namapovaných z RDB.

RDB objekty umí - zvládá data včetně chování, s určitými omezeními. Jen se to musí umět. Cílem je rozdělit kompetence mezi RDB a jeho aplikace tak, aby celek byl robustní a konzistentní. Přidání další aplikace do takového systému pak nepředstavuje významný problém.

[Kit]

ActiveRecord vs. Data Mapper se liší v tom, kde je zapouzdřená kompetence za persistenci - zda spolu s daty (v objektu reprezentujícím data z business domény) anebo bokem (v data mapperu). Některá ORM umožňují použít oba přístupy (vybrat si, kterému dám přednost). Viz.:

Když se dívám na definici Active Recordu od Fowlera (https://www.martinfowler.com/eaaCatalog/activeRecord.html), musím se omluvit - myslel jsem, že je použit pouze jako mechanismus pro podržení mapované relace z RDB pro potřeby jednoduchého zápisu (v podstatě kopie relace), tj. objekt pro potřeby mapovače. Je to mnohem horší, má to být přímo doménový objekt. To je samo o sobě nesmysl, protože 1. neodděluje OM od RDB, 2. umožňuje mapování pouze primitivních objektů, které se vejdou do 1 relace (v praxi ne moc časté). Nenapadlo mě, že by se to někdo vůbec pokusil použít. Moje chyba.

Není to tak špatné, jak to na první pohled vypadá.
1. Není nutné oddělovat OM od RDB
2. Umožňuje to mapování nejen primitivních, ale i komplexních objektů, které se skládají z mnoha relací
3. Co třeba strom?

[SB]

Doménovým objektem je jednoduše kolekce.

Nevím, jak to souvisí s Data Mapperem, ale kolekce vůbec nemusí být doménovým objektem. Obecně (bez ohledu na skutečnost, zda má objekt položky pojmenované (běžný objekt) či indexované (seznam)) platí, že doménový objekt je ten, který patří do domény, neboli modelovaného problému, pak je obvykle i ukládaný. Naopak při výpočtech v doméně se používá mnoho objektů (včetně seznamů), které do domény nepatří a po dokončení výpočtu zaniknou.
Seznam je mimochodem strukturou, kterou RDB neumí samostatně uložit (RDB koneckonců neumí často samostatně uložit ani objekt), což je jedním z problémů, které řeší ORM.

[SB]

RDB objekty umí - zvládá data včetně chování, s určitými omezeními. Jen se to musí umět. Cílem je rozdělit kompetence mezi RDB a jeho aplikace tak, aby celek byl robustní a konzistentní. Přidání další aplikace do takového systému pak nepředstavuje významný problém.

Tak jasně, i metody objektu jde strčit třeba do jednoho řetězce nebo blobu v relaci. Ale pořád to neumožňuje pracovat s objekty v DB stejně jako v aplikaci (to by měly umět ODB, např. Gemstone). Jestli máte na mysli PL/SQL, tak to se ale nebavíme o OOP.

[Reklama]

[SB]

Není to tak špatné, jak to na první pohled vypadá.
1. Není nutné oddělovat OM od RDB
2. Umožňuje to mapování nejen primitivních, ale i komplexních objektů, které se skládají z mnoha relací
3. Co třeba strom?

1. Není, ale pak vám struktura RDB a jakékoliv její změny přeteče do domény v aplikaci s následnou nutností (hluboce) upravovat a výpočty podřizovat její struktuře. O konečné pro výměnu persistentní vrstvy (která už není vrstvou, ale součástí), tj. nejen např. více zdrojů, webovou službu místo DB, nebo jiný typ DB, ale dokonce jen jiná RDB(!!!), se doufám nemusím rozepisovat. Tento přístup jsem zažil v jedné nejmenované, velké, české firmě, tam to teda ještě dotáhli do extrému tak, že Active Record byl pouhým recordem (tj. holá data bez chování, v lepším případě se používal anemický datový model, v horším se to do recordu praskalo pokaždé extra) a komboboxy v GUI si načítaly data pomocí SQL z RDB.
Ne, tohle není ani OOP, ani koncepční přístup (přestože si to mnoho lidí z IT myslí).

2. Jak, když AR je (z definice) jedna relace na jeden (rádoby)doménový objekt???

3. Co je se stromem?

[Kit]

Doménovým objektem je jednoduše kolekce.

Nevím, jak to souvisí s Data Mapperem, ale kolekce vůbec nemusí být doménovým objektem. Obecně (bez ohledu na skutečnost, zda má objekt položky pojmenované (běžný objekt) či indexované (seznam)) platí, že doménový objekt je ten, který patří do domény, neboli modelovaného problému, pak je obvykle i ukládaný. Naopak při výpočtech v doméně se používá mnoho objektů (včetně seznamů), které do domény nepatří a po dokončení výpočtu zaniknou.
Seznam je mimochodem strukturou, kterou RDB neumí samostatně uložit (RDB koneckonců neumí často samostatně uložit ani objekt), což je jedním z problémů, které řeší ORM.

Vytrženo z kontextu.

Doménovým objektem může být i kolekce, proto ji k tomuto účelu používám. Jen se to některým vývojářům nelíbí, protože to nemá gettery a settery, které by však byly v uvedeném případu zbytečné a komplikující.

Odkdy má seznam indexované položky? U seznamu je definováno pouze jejich pořadí. Používání indexů v souvislosti se seznamy je cestou do pekel.

Seznam ukládám přes jeden prepared statement, za kterým hrnu data. To jsou 4 řádky mého ORM. Ovšem ukládání seznamů do databáze není zas tak časté, jak by se mohlo zdát. Kolekce i objekty je možné snadno uložit do RDB, pokud jsou serializovány.

[Kit]

Není to tak špatné, jak to na první pohled vypadá.
1. Není nutné oddělovat OM od RDB
2. Umožňuje to mapování nejen primitivních, ale i komplexních objektů, které se skládají z mnoha relací
3. Co třeba strom?

1. Není, ale pak vám struktura RDB a jakékoliv její změny přeteče do domény v aplikaci s následnou nutností (hluboce) upravovat a výpočty podřizovat její struktuře. O konečné pro výměnu persistentní vrstvy (která už není vrstvou, ale součástí), tj. nejen např. více zdrojů, webovou službu místo DB, nebo jiný typ DB, ale dokonce jen jiná RDB(!!!), se doufám nemusím rozepisovat. Tento přístup jsem zažil v jedné nejmenované, velké, české firmě, tam to teda ještě dotáhli do extrému tak, že Active Record byl pouhým recordem (tj. holá data bez chování, v lepším případě se používal anemický datový model, v horším se to do recordu praskalo pokaždé extra) a komboboxy v GUI si načítaly data pomocí SQL z RDB.
Ne, tohle není ani OOP, ani koncepční přístup (přestože si to mnoho lidí z IT myslí).

2. Jak, když AR je (z definice) jedna relace na jeden (rádoby)doménový objekt???

3. Co je se stromem?

1. Bez problémů měním strukturu RDB, aniž bych musel upravovat aplikaci. Dobře napsaná aplikace se tomu sama přizpůsobí.
2+3. Právě ten strom je ukázkou jednoho objektu, který se může skládat z mnoha relací.

[JS]

Aha, takže jste měl na mysli globálně unikátní, to je ale váš vyjadřovací problém.

Nemel jsem na mysli jen tohle, to je jeden z prikladu takove vlastnosti. Rozmysli si, jestli chces nejdriv pochopit co rikam nebo to rozporovat.

Jiny priklad je treba globalni omezeni nejakeho zdroje, treba pocet vlaken nebo file descriptoru. V OOP se tohle modeluje blbe, protoze objektum obecne nemluvime do toho, jak jsou vnitrne implementovane.

Měl jste asi na mysli tabulky, ne relace.

Ne, mel jsem na mysli relace, z relacniho modelu dat. Jestli je relace reprezentovana jednou nebo vice tabulkami (ktere se spoji) je jedno.

Jde o to, ze v OOP se objekty o ostatni objekty nemusi (a nemaji) starat, ale v relacnim modelu dat je schema globalni. Takze globalni podminky na vsechny objekty (urciteho druhu) se v OOP vynucuji obtizne, kdezto v relacnim modelu je to pomerne snadne. Ovsem za cenu, totiz ze se porusi encapsulation - schema musi kompletne videt do vsech tabulek.

Je treba si uvedomit, ze oboji ma svoje vyhody a nevyhody. Ale plynou z toho problemy pri prechodu od jednoho modelu ke druhemu. Ostatne, myslim, ze tenhle clanek uz vsechny tyto problemy (a mnohe dalsi) popsal: http://blogs.tedneward.com/post/the-vietnam-of-computer-science/

[SB]

Doménovým objektem je jednoduše kolekce.

Nevím, jak to souvisí s Data Mapperem...

...Doménovým objektem může být i kolekce, proto ji k tomuto účelu používám. Jen se to některým vývojářům nelíbí, protože to nemá gettery a settery, které by však byly v uvedeném případu zbytečné a komplikující.

Nelíbí se mi ten otočený způsob uvažování. Lépe: Dom. objektem může být jakýkoliv objekt, takže i seznam.
Pravidlo o zapouzdření platí (opět) pro jakýkoliv objekt, tedy i pro seznam. Seznam bez zapouzdření je tedy z pohledu OOP chybou.

Odkdy má seznam indexované položky? U seznamu je definováno pouze jejich pořadí. Používání indexů v souvislosti se seznamy je cestou do pekel.

Pochopitelně se tím myslí vnitřní reprezentace, čímž jsem chtěl ukázat, že seznam není ničím jiným než objektem, který má místo pojmenovaných položek číslované položky, a to bez ohledu na to, zda je s pořadím, bez pořadí, s řazením či jiný.

Seznam ukládám přes jeden prepared statement, za kterým hrnu data. To jsou 4 řádky mého ORM. Ovšem ukládání seznamů do databáze není zas tak časté, jak by se mohlo zdát. Kolekce i objekty je možné snadno uložit do RDB, pokud jsou serializovány.

Vizte výše - seznam je objekt jako každý jiný, proto by se mechanismus pro vyvolání uložení neměl nijak lišit. Samozřejmě musí mít identitu mapovatelnou do RDB (nějaký jedinečný identifikátor). Jinou otázkou je rozklad seznamu do tabulek na straně RDB, to je dost jiná liga, obzvláště u heterogenních seznamů. Zrovna serializace (předpokládám binární) způsobuje nemožnost deserializace při změně struktury v doméně a nemožnost vyhledávání v RDB, takže nic moc.

[SB]

1. Bez problémů měním strukturu RDB, aniž bych musel upravovat aplikaci. Dobře napsaná aplikace se tomu sama přizpůsobí.
2+3. Právě ten strom je ukázkou jednoho objektu, který se může skládat z mnoha relací.

1. Jak to přizpůsobení probíhá? Je tam nějaký adaptivní mechanismus nebo umělá inteligence?
2., 3. Nenacházím žádnou souvislost mezi strukturou stromu a relace, vysvětlete to prosím.

[SB]

Aha, takže jste měl na mysli globálně unikátní, to je ale váš vyjadřovací problém.

Nemel jsem na mysli jen tohle, to je jeden z prikladu takove vlastnosti. Rozmysli si, jestli chces nejdriv pochopit co rikam nebo to rozporovat.

Jiny priklad je treba globalni omezeni nejakeho zdroje, treba pocet vlaken nebo file descriptoru. V OOP se tohle modeluje blbe, protoze objektum obecne nemluvime do toho, jak jsou vnitrne implementovane.

Asi už vím, co myslíte. Globální konzistencí myslíte správnost dat jako celku přes mnoho systémů. To jo, ale s tím nemá OOP nic společného, to platí pro všechna uspořádání dat.

Toto moc nechápu - máte na mysli použití např. poolů?

A pozor na to vykání.

Měl jste asi na mysli tabulky, ne relace.

...Jde o to, ze v OOP se objekty o ostatni objekty nemusi (a nemaji) starat, ale v relacnim modelu dat je schema globalni. Takze globalni podminky na vsechny objekty (urciteho druhu) se v OOP vynucuji obtizne, kdezto v relacnim modelu je to pomerne snadne. Ovsem za cenu, totiz ze se porusi encapsulation - schema musi kompletne videt do vsech tabulek.

Je treba si uvedomit, ze oboji ma svoje vyhody a nevyhody. Ale plynou z toho problemy pri prechodu od jednoho modelu ke druhemu. Ostatne, myslim, ze tenhle clanek uz vsechny tyto problemy (a mnohe dalsi) popsal: http://blogs.tedneward.com/post/the-vietnam-of-computer-science/

Tady nějak vůbec tomu dostavci - proč chcete mít všechny objekty stejné? Jak se schema kouká do tabulek???

Na Vietnam kouknu.

[Kit]

Doménovým objektem je jednoduše kolekce.

Nevím, jak to souvisí s Data Mapperem...

...Doménovým objektem může být i kolekce, proto ji k tomuto účelu používám. Jen se to některým vývojářům nelíbí, protože to nemá gettery a settery, které by však byly v uvedeném případu zbytečné a komplikující.

Nelíbí se mi ten otočený způsob uvažování. Lépe: Dom. objektem může být jakýkoliv objekt, takže i seznam.
Pravidlo o zapouzdření platí (opět) pro jakýkoliv objekt, tedy i pro seznam. Seznam bez zapouzdření je tedy z pohledu OOP chybou.

Takže jinak: Jako doménový objekt používám kolekci, která již má své zapouzdření.

Odkdy má seznam indexované položky? U seznamu je definováno pouze jejich pořadí. Používání indexů v souvislosti se seznamy je cestou do pekel.

Pochopitelně se tím myslí vnitřní reprezentace, čímž jsem chtěl ukázat, že seznam není ničím jiným než objektem, který má místo pojmenovaných položek číslované položky, a to bez ohledu na to, zda je s pořadím, bez pořadí, s řazením či jiný.

O vnitřní reprezentaci se nebavíme, nehledě k tomu, že vnitřní reprezentace seznamu obvykle ani indexy nemají. Indexy u seznamu ani nejsou potřebné, resp. jejich používání porušuje zapouzdření.

Seznam ukládám přes jeden prepared statement, za kterým hrnu data. To jsou 4 řádky mého ORM. Ovšem ukládání seznamů do databáze není zas tak časté, jak by se mohlo zdát. Kolekce i objekty je možné snadno uložit do RDB, pokud jsou serializovány.

Vizte výše - seznam je objekt jako každý jiný, proto by se mechanismus pro vyvolání uložení neměl nijak lišit. Samozřejmě musí mít identitu mapovatelnou do RDB (nějaký jedinečný identifikátor). Jinou otázkou je rozklad seznamu do tabulek na straně RDB, to je dost jiná liga, obzvláště u heterogenních seznamů. Zrovna serializace (předpokládám binární) způsobuje nemožnost deserializace při změně struktury v doméně a nemožnost vyhledávání v RDB, takže nic moc.

Mezi OOP a RDB musí být vložena mezivrstva. Ta může být v aplikaci nebo v databázi, případně vhodně rozdělena mezi ně tak, aby bylo co nejjednodušší a přitom robustní API. Pro umístění v databázi hovoří zejména fakt, že už má svou cache, takže není třeba dělat v OOP nějaké náhražky.

[Kit]

1. Bez problémů měním strukturu RDB, aniž bych musel upravovat aplikaci. Dobře napsaná aplikace se tomu sama přizpůsobí.
2+3. Právě ten strom je ukázkou jednoho objektu, který se může skládat z mnoha relací.

1. Jak to přizpůsobení probíhá? Je tam nějaký adaptivní mechanismus nebo umělá inteligence?
2., 3. Nenacházím žádnou souvislost mezi strukturou stromu a relace, vysvětlete to prosím.

Adaptivní mechanismus je jednoduchý: Aplikace se nespoléhá na to, že dostane co chce, ale analyzuje výsledek z RDB a ten zpracuje. Vazba je tedy adaptivní, opírá se o jednoduché a neměnné API.

Každý element stromu je relací. Strom je kolekcí, tedy i objektem.

[SB]

O vnitřní reprezentaci se nebavíme, nehledě k tomu, že vnitřní reprezentace seznamu obvykle ani indexy nemají. Indexy u seznamu ani nejsou potřebné, resp. jejich používání porušuje zapouzdření.

Naopak, pole je pro implementaci seznamu výhodné, koneckonců když se implementace přesune níže do primitiv, stejně z toho nejspíš vyjde pole.
Když je to vnitřní reprezentace, tak se indexy ven nedostanou.

Mezi OOP a RDB musí být vložena mezivrstva. Ta může být v aplikaci nebo v databázi, případně vhodně rozdělena mezi ně tak, aby bylo co nejjednodušší a přitom robustní API. Pro umístění v databázi hovoří zejména fakt, že už má svou cache, takže není třeba dělat v OOP nějaké náhražky.

Ona mezivrstva s mapovačem musí být stejně v aplikaci, protože jediná z těch 2 umí manipulovat s objekty i n-ticemi, pro RDB jsou objekty jaksi cizí, takže nemá jak ony objekty poskytovat (třeba v JSONech nebo já nevím v čem).