Zobrazit příspěvky
Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.
Právě jsem vytvořil commit (sic): "Vytvoří pro Fondy továrny, aby se dali dát do DIContaineru."
Všimněte si angličtiny s českou gramatikou použité za účelem vtípku.
Rozhovor se tu krapet zvrhl v několik falešných premis:
- ORM není o tom, nedostat se nebo schovat SQL. Když už něco schovávat, tak to je relační algebra. Ale SQL nikomu nevadí.
- To, že potřebuju specializovaný dotaz, kde dělám hroznou magii neznamená, že nesmím použít ORM. Tím spíše, když specializovaný dotaz je sotva procento všeho.
- To, že někdo zprasil ORM tak, že z toho Pavel málem omdlel neznamená, že napsat si "lehkou obálku" by dopadlo lépe.
- Napsat si "lehkou obálku" nebude automaticky výhodnější.
- Narvat všechno do DB je volená strategie, která nejde přímo proti ORM.
Kit:CitaceSamozřejmě nejprve udělám selekci i projekci, abych dostal jen ta data, která potřebuji.Ale to je problém slepice nebo vejce. Těžko uděláš projekci a selekci, když neznáš strukturu a nevíš, co a jak projektovat a strukturovat.
Jako jo, není výjimka, že se nějaké "listové atributy" (tam, kde se dají data aspoň nějak zestromovatět) ukládají v RDBS např. do JSONu a tam pak je Tvůj postup dobře použitelný, ale IMHO to rozhodně není univerzální model na to, jak pracovat s daty v nějaké aplikaci.
Citacea teprve v aplikaci hledám, jak ji mám zpracovat.Možná nerozumím tomu, jak to myslíš, ale nedokážu si představit, jak z velký databáze tímto způsobem dostaneš hledaná data efektivně.
Jo, nacpat co nejvíce bussines logiky do DB je hodně dobrá cesta. Pak se dá samozřejmě dá měnit databázi aplikaci "pod rukama", aniž by si ta vůbec všimla. Ale to už jsme hodně daleko od NoSQL databází, a taky to vyžaduje člověka, co něco umí - pro "běžnýho prací prášek" jsou stored procedure sprostý slovo.
Traversování stromu popř. nějaké wildcardy v XPath věc řeší, ale to je IMHO spíše na jednorázové zpracovávání dat (importy a podobně). Nedokážu si představit (rozumně výkonnou) aplikačku s nějak rozumně velkou databází, která nespoléhá na pevné umístění dat, ale každou entitu hledá kdekoli v stromové struktuře. Zas jsme u toho, že každej postup se hodí někde...
Jo, tak to jo - to je v takovém případě rozumný postup, ale to je velmi specifické užití. V okamžiku, kdy Ti na tom závisí nějaká "bussines logika", tak si nedovedu představit, že by to šlo použít. Např. když ti do tabulky zaměstnanců přibydou "skrytí agenti" - které nebudeš chtít zobrazovat na webu v seznamu zaměstnanců - tak už se s takto jednoduchým přístupem nevyřeším. Nemůžu vzít novou databázi a nad ní pustit starou verzi aplikace, prozradil bych Čepigu.
Navíc když budeš chtít pokrýt aplikaci testy, tak by Ti to mělo na té starší db zařvat atd.... Takže jo, beru, že tendle přístup se někdy hodí, ale myslím, že se nedá brát jako "univerzální řešení" na modifikaci či refaktoring databáze.
My to řešíme (ale to asi není nic nového) většinou systémem migrací - tzn. aplikace si vždycky při deployi (jak se to skloňje :-)) upraví databázi na nejvovější verzi. Což jakž takž řeší půl problému (stará db verzus nová aplikace) - dělat "downgrade databáze" je zpravidla problém. Ale to furt neřeší ten základní problém, že s každou změnu struktury db je třeba upravit jak všechen SQL kód tak veškerou bussines logiku dotčené tou změnou, včetně testů. Což může někdy být hodně práce, takže je výhoda, když je schéma DB co nejuniverzálnější a tedy se nemusí měnit.
Předtím jsem nemluvil až tak o přidání sloupce (s tím je zpravidla práce minimum) - na kteréžto, jestli jsem pochopil Tvůj post, je zaměřeno Tvé řešení především - ale o refaktoring vztahů mezi entitami. Kterej se v SQL (pokud člověk neudělá chybu v kardinalitách) dělá zřídka, ale v stromových databázích - z důvodů, které jsem popsal v minulých postech - se mu někdy vyhnout nejde.
Kit: Moh bys to "řízení tokem databáze" nějak rozvést? Nějak si neumím představit, co přesně pod tím myslíš.... a třeba se něco naučím :-)
Toho mít dvě verze kódu pro různé struktury se snad zbavit nemůžeš, ne?
CitaceNapř. dokumentové DB jsou bezschématové, takže změna struktury se provádí uložením dokumentu v jiném formátu. V RDB je třeba změna statické struktury zvláštními příkazy, a to při odstavené DB.To ale překrucuješ, co jsem tvrdil. Nepsal jsem o složitosti provádění změny - koneckonců, když už se provádí změna, je způsob realizace změny schématu ten menší problém - daleko větš problém je nutnost adaptovat aplikaci na tu změnu, to že stará aplikace na nové struktuře nefunguje a nová na staré (anebo se kód zanáší "legacy vydličkama").
Psal jsem o tom, že tam, kde relační struktura nevyžaduje změnu, tak stromová může a dosti často bude, protože stromová struktura je podstatně méně univerzální, než ta relační.
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?
V seznamu je definováno pořadí, které je závislé na pořadí přidání elementu. Seznam nepotřebuje index.Však taky indexy neslouží k popisu pořadí vkládání položek do seznamu.
PanVP:RDB NEZNÁ seznamy! Jasně, už slyším křik: „Ale když udělám SELECT něco FROM něco WHERE id_rádobyseznamu = něco, tak mám seznam.“ To ale není seznam, to je pouze podmnožina VŠECH prvků seznamů STEJNÉHO typu nasypaných do jedné krabice zvané tabulka, ...CitaceORM - rovnák na vohejbák.Ne, to není rovnák na vohejbák.
ORM je tzv. "leaky abstraction" - https://en.wikipedia.org/wiki/Leaky_abstraction
coz vubec nevadi, pokud nepotrebujete stridat databaze. Hlavni ucel ORM je moznost psat SQL ve vyssim, expresivnejsim jazyce.
Root.cz (www.root.cz), informace nejen ze světa Linuxu. ISSN 1212-8309
Copyright © 1998 – 2023 Internet Info, s.r.o. Všechna práva vyhrazena. Powered by Linux.