Vývoj aplikací vaším způsobem jsem byl nucen dělat roky a vracet se k tomu nechci ani myšlenkou.
Ale já přeci nechci, abys to vyvíjel po mém. Já se Tě ptám, jak takováto data uložíš
po svém. Teda jaký přístup použiješ v NoSQL databázích, které tu hájíš jako "jediný správný způsob".
Ten příklad totiž přesně ukazuje, že stromová struktura má své limity, a že některá data do ní nejde dostat tak, aby byly univerzálně použitelné. Což znamená v případě, kdy existuje dobré stromové zjednodušení, práci při analýze navíc, a v případě kdy neexistuje, horší výkon výsledného řešení (anebo nějakou formu denormalizace a duplikace dat navíc, což přidělá práci).Což bys pochopil, kdybys místo výmluv tu výzvu vzal a nad řešením se zamyslel. Takto mám pocit, že se snažíš odpovědi vyhnout, protože nevíš, jak bys rozumně odpověděl.
Btw. - ne, určitě si nevyvíjel věci po mém. Zaprve neexistuje "po mém" - já narozdíl od Tebe netvrdím, že existuje "jeden správný způsob". A zadruhé, kdybys opravdu dělal skutečný (nazvěme to třeba) SQL-vývoj, tak bys věděl některé věci (např. o PL/SQL), které jsi evidentně nevěděl. Působíš na mne, jako by Tě v nějaké firmě nutili dělat v SQL, aniž by Tě naučili alespoň základní věci kolem něj - a že jsi z toho byl (vcelku oprávněně) frustrovanej - a tak je pro tebe cokoli, co Tě od SQL odstíní (ORM, NoSQl,....) "výhra". To ale není chyba SQL, ale chyba té firmy, kdes dělal....
Ví, který záznam v kterém formátu ukládá a naopak čte, podle toho rekonstruuje doménový model v paměti. Mimoto si sama řeší kontrolu dat a konzistenci (to musí bez ohledu na DB), takže p*cat se s tím ještě v DB netřeba. Jakékoliv změny tedy znamenají zapracování práce s novým formátem do doménového modelu
A po takových deseti změnách formátu je z databáze i kódu guláš, kdy v db jsou uloženy záznamy v deseti verzích, z kódu je nečitelný guláš počítající s deseti různými formáty záznamu, a nedej bože, jestli je třeba udělat větší refaktoring struktury, pak mám polovinu záznamů daného typu támdle (např. předměty pod učitelema) a polovinu úplně jinde (např. "nad učitelema"), což vede k velmi "efektivnímu" čtení takto po databázi "rozsypanejch" dat.
konzistenci (to musí bez ohledu na DB), takže p*cat se s tím ještě v DB netřeba
Vzhledem k tomu, v jakém stavu jsou často DB, kde se řeší konzistence dat jak na klientu, tak na serveru, tak se obávám, že to je teorie nestřetávající se s realitou. Možná jsi geniální člověk, který nikdy neudělal chybu a druhou kontrolu nepotřebuje. Pak se ovšem smiř s tím, že jsi na světě jediný, a že Tvý kolegové chyby dělat budou. Mraky chyb je i v databázích, kde je doublecheck na klientovi i na serveru. Natož když jednu z nich odstraníš.
To samé v RDB znamená upravit schéma
A? Schéma "v hlavě" upravit musíš tak jako tak - i v sql i v nosql databázi. A napsat k němu dokumentaci (v NoSQL o to podrobnější, že Ti schází struktura tabulky, která ji částečně může nahradit). Vyplivnout úpravu schématu do SQL kódu je oproti tomu už detail.
(nedej bože předělávat procedury a ladit je
Zatímco v Tvém řešení musíš upravit procedury tak, aby počítaty se záznamy v starém i novém formátu, v SQL řešení stačí je upravit pouze na nový formát. To je jednodušší úkol, nikoli složitější. Že ve svém řešení nemáš prodcedury? Ale máš. Akorát je máš nikoli v DB, ale na klientovi, což je - pokud umíš pracovat s DB - vlastně úplně jedno. Viz např.
https://www.pgadmin.org/docs/pgadmin4/development/debugger.html
Kit:
Samozř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.
Zobrazit příspěvky
