Kit:
SQL je dostatečně expresivním jazykem, většina ORM toho nedosahuje.
Ano a ne. Záleží na úhlu pohledu. SQL má samozřejmě velmi výrazně širší možnosti, než jakýkoli ORM. Z tohodle pohledu ano. Ale z hlediska snadnosti napsání dané úlohy je SQL oproti ORM "assembler". Proto je někdy vhodné psát jen v ORM (pak ale často mohou být NoSQL databáze lepší volbou), někdy jen v SQL, někdy se hodí přístup kombinovat. Samozřejmě, má to své z určitého poledu problematické stránky, jak v link postoval SB.
SB:
V seznamu je definováno pořadí, které je závislé na pořadí přidání elementu. Seznam nepotřebuje index. RDB dodává množinu, u které není definováno pořadí, pokud není explicitně uvedeno řazení v dotazu. Update DB tabulky seznamem není triviální úlohou a zpravidla je výhodnější to řešit jinak.
To ale není problém OO a SQL, ale jde o obecnější problém
Objektový model neznamená nutnost používání seznamů. Ani v těch "nejpurističtějších" OO definicích žádné seznamy nejsou. Seznamy se používají čistě proto, že jsou to datové struktury, se kterými se dobře a jednoduše pracuje v imperativních jazycích. Ve skutečnosti mají být objekty "odrazem reality". Když si vezmu takový objekt "školní třída", tak ta má jako vlastnost "seznam žáků". A podle čeho má být ten seznam seřazen? Podle příjmení? Čísla ve třídním výkazu? Prospěchu? U drtivé většiny vlastností objektů není žádné "preferované pořadí", tedy jde o množiny, ne o seznamy.
Že se ta množina realizuje v praxi pomocí seznamu, to, že je tam nějaké pořadí dané časem vložení: to není žádná "objektová věc", ale je to implementační artefakt, který nemá s podstatou uložených dat nic společného. Max. se tento artefakt použije k implementačnímu urychlení procházení dané množiny podle nějakého preferovaného pořadí.
A z druhé strany - ano, SQL databáze používají na ukládání množiny. Nebo přesněji v programátorské hantýrce (pokud nejsou definovány unique constrainy) multisety. A ano, objekty jsou zpravidla implementovány seznamy. Potud ano, jenže..... Jak píšu výš ta "seznamovost" není podstata objektů. Funkcionální jazyky jsou "seznamové" ještě více, než OOP jazyky. Stejnětak v neOO přístupu, když se používají datové struktury a "funkce vedle", opět velmi často budeš pracovat se seznamy. Prostě seznam je nativní způsob ukládání něčeho v paměti při interaktivní práci, nezávislý na užitém programátorském paradigmatu
A teď je otázka - existuje nějaký "nativně seznamový" způsob persistentního ukládání dat? Jistě: samotný soubor je seznam bytů. Jenže ten je na nějaké rozumné používání hrozně nešikovný, je třeba nad ním udělat nějakou abstrakci. Tak jakou? Za "seznamovou" by se mohla částečně považovat stromové databáze, nebo jejich moderní inkarnace dokumentové databáze. Ale i tam (např. Mongo) jsou na hlavní úrovni kolekce, tedy množiny. A uvnitř sice jsou seznamy, které se velmi snadno mapují na "objekty" (ve skutečnosti na struktury pro interaktivní práci), což je velmi výhodné.....dokud nepotřebuji pracovat se "seznamy" napříč stromy. Nebo s vlastnostmi v jiném pořadí, než v kterém jsou uložené. Pak se najednou elegance těchto databází ztrácí.
Stejnětak vlastně filesystém - navenek je to stromová struktura, ale seznam souborů v adresáři není seznam, ale set, který se jednou řadí tak, jednou jinak. Stejnětak filesystém samotný je vlastně multiset datových bloků, s nějakým indexem vybudovaným nad tím setem. Když se zamyslíš, tak v podstatě každý aspoň trochu použitelný způsob práce s perzistentními daty daleko spíš připomíná práci se sety, než práci se seznamy.
To, co popisuješ není nekompatibilita mezi OO a SQL, ale je to obecně konflikt mezi strukturami vhodnými na interaktivní práci: kde z principu fungování paměti je výhodné sekvenční zpracování seznamů, a strukturami vhodnými na persistentní storage a vyhledávání dat, kde obecnost matematického množinového popisu poskytuje možnosti, které žádný "list-based approach" přinést prostě nemůže.A v podstatě i odrazem toho jsou debaty mezi SQL a NoSQL táborem: kdy jedni preferují snadnost eleganci a univerzalitu toho množinového popisu, za cenu té nikoli nekompatibility, ale práce navíc při mapování mezi těmi světy. Protože nekompatibilní to není, existuje tam bijekce. Jen je to práce navíc to "namapovat". A právě proto vznikly ORM, aby tu práci navíc co nejvíce odstínily (byť samozřejmě ne zadarmo).
A jsou lidé, kteří místo toho se snaží o co nejpřímější mapování "paměti" do persistentního úložiště, a Ti preferují jednoduchost NoSQL databází, kde je to mapování podstatně jednodušší. Ale ani jeden přístup není "ten jediný správný". Jsou případy, kde univerzálnost toho množinového popisu dalece převáží práci navíc, vynaloženou na mapování mezi těmi světy. A jsou případy, kdy tomu tak není a opravdu přímý "dokumentový" přístup je rychlejší.
A ani jeden z nich nebude mít pravdu, když bude tvrdit, že jeho přístup je "ten nejlepší na vše". Někdy se hodí mít úložiště "univerzální" za cenu té vícepráce - a někdy je ta vícepráce zbytečná.
"Seznamový" pohled na data není nic jiného, než "znásilnění" dat do formátu, s kterým se "algoritmicky dobře pracuje". A jak to u takovéhoto znásilnění bývá, tak je vhodné do té doby, dokud se nad danými daty používá "jeden způsob zpracování", pro který je vhodné způsob uložení dat optimalizovat.
Relační způsob je univerzální. Není "znásilněný", takže v něm jde všechno "dobře". Ale samozřejmě není optimalizovaný pro ten "jeden preferovaný způsob tak", jako stromové/dokumentové databáze.
Způsobů mapování objektů na relace je vícero, určitě ne jeden.
To bych se hádal. Pokud nebereš alternativy, které tu někdo zmiňoval, jako JSON a pole - což je jen jiná forma denormalizace, tak daná datová struktura má IMHO 1:1 rozpad na relace. Nebo máš nějaký konkrétní případ, kde to bude jinak?To, v čem se struktury liší je případně návrh té ukládané datové struktury, kdy se třeba někdy přizpůsobuje, aby se uložila do db vhodným způsobem, ale pokud máš nějakou strukturu entit a jejich vazeb, tak je rozpad na relace jednoznačný. Alespoň ve smyslu jako v příkladu níže.
V DB NoSQL se používají právě ty seznamy proto, aby se tím lesem nemuselo zbytečně courat, to je pazvyk z RDB.
Ne, to není pazvyk z RDB, to je prostě nutnost. Pokud máš učitelský sbor, a chceš jednou "seznam" učitelů, co učí danou třídu, podruhé seznam učitelů, co učí v dané učebně, potřetí seznam těch, co...., a počtvrté seznam žáků, co...., tak se prostě courání přes les principiálně nevyhneš.
Samozřejmě, jde to "emulovat" tak, že máš ve stromě uložen seznam "idček". Jenže to už je lezení přes strom a když se nad tím zamyslíš, tak nejde o nic jiného, než o zakuklený relační přístup.
Někdy to jde také řešit duplikací dat na více místech - ale ani to není jiného, než denormalizace v SQL, která je sice užitečná, ale vždy problematická, takže se Ti najednou výhodnost NoSQL začne ztrácet.
Chybně navržených relačních modelů jsem viděl dost.
Ano,
chybně. To je právě to ono. Relační model je buďto správný, nebo chybný. Stromový model může být zcela správně: tedy může do něj být bez problémů zachytitelná jakákoli "realizace daného axiomatického systému" - prostě do něj zachytíš jakoukoli "validní" situaci, a přesto může být pro dané použití naprosto nevhodný. Např. když uděláš stromeček kdy budou nahoře žáci, pod každým žákem seznam jejich předmětů a pod každým předmětem jeho učitel, tak se Ti s tím při vytváření rozvrhu tříd bude pracovat fakt blbě. Ale datový model bude správně: korektně popíše jakoukoli "validní" situaci.
Relační model: kdy budeš mít množiny učitelů, žáků a předmětů a vazby mezi nimi, je daný jednoznačně, a když ho udělá člověk správně, tedy bude respektovat kardinalitu vazeb a z ní plynoucí způsob realizace této vazby, tak je právě jedna implementace takového "systému". A v této implementaci bude realizovatelný "jakákoli" úloha, kterou si vzpomeneš.
Zobrazit příspěvky
