Rada při návrhu db tabulek

[SB]

SB:
To si asi nerozumíme. Ale když nenapíšeš v čem, tak to působí, že si radši ani rozumět nechceš :-)

Nenapíšu, nic tím nezískám. Vývoj aplikací vaším způsobem jsem byl nucen dělat roky a vracet se k tomu nechci ani myšlenkou. Užijte si to.

P. S.: Všimněte si, že vám netykám, ani jinak neříkám vole, p*čo či soudruhu. Nenapadá vás proč?

[Reklama]

[Kit]

a 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ě.

Samozřejmě nejprve udělám selekci i projekci, abych dostal jen ta data, která potřebuji. Každý záznam pak považuji za kolekci složenou z key:value. Každý key použiji jako klíč pro další zpracování value. Nevyhledávám tedy data ve výsledku, ale algoritmus, kterým ta data mám zpracovat. Říká se tomu metoda push. Úplně nejjednodušší je však celý záznam nasypat do DOMu - výstupní šablona si s tím poradí včetně formátování a překladů.

[Pavel Stěhule]

SQL je poměrně primitivním dotazovacím jazykem, Kit měl asi na mysli PL/SQL. To je taky primitivní jazyk, stačí si uvědomit, že nemá jakékoliv složitější datové struktury (např. něco jako struct/record, seznamy!), pouze primitivní typy, takže např. volání procedur či funkcí s nějakým obsahem v parametrech je zoufalé, jakákoliv práce se seznamy znamená opakované čtení dat z tabulek. Ladění otřesné. Vlastně ani žádnou podobnost s vyššími jazyky nevidím.
Naproti tomu vždy jde vytvořit nějaké ORM, které jedním příkazem s pár parametry provést (různě) složitou operaci s mnoha dotazy SQL a jejich sestavením na pozadí. Ale to ORM musí nejdřív někdo vyvinout.

To jste úplně mimo - PL/SQL je přebrandovaná ADA, rozšířená o embedded SQL

https://en.wikipedia.org/wiki/Ada_(programming_language)

[Logik]

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.

[SB]

SQL je poměrně primitivním dotazovacím jazykem, Kit měl asi na mysli PL/SQL. To je taky primitivní jazyk, stačí si uvědomit, že nemá jakékoliv složitější datové struktury (např. něco jako struct/record, seznamy!), pouze primitivní typy, takže např. volání procedur či funkcí s nějakým obsahem v parametrech je zoufalé, jakákoliv práce se seznamy znamená opakované čtení dat z tabulek. Ladění otřesné. Vlastně ani žádnou podobnost s vyššími jazyky nevidím.
Naproti tomu vždy jde vytvořit nějaké ORM, které jedním příkazem s pár parametry provést (různě) složitou operaci s mnoha dotazy SQL a jejich sestavením na pozadí. Ale to ORM musí nejdřív někdo vyvinout.

To jste úplně mimo - PL/SQL je přebrandovaná ADA, rozšířená o embedded SQL

https://en.wikipedia.org/wiki/Ada_(programming_language)

Který z výše uvedených problémů to řeší?

[Reklama]

[Pavel Stěhule]

SQL je poměrně primitivním dotazovacím jazykem, Kit měl asi na mysli PL/SQL. To je taky primitivní jazyk, stačí si uvědomit, že nemá jakékoliv složitější datové struktury (např. něco jako struct/record, seznamy!), pouze primitivní typy, takže např. volání procedur či funkcí s nějakým obsahem v parametrech je zoufalé, jakákoliv práce se seznamy znamená opakované čtení dat z tabulek. Ladění otřesné. Vlastně ani žádnou podobnost s vyššími jazyky nevidím.
Naproti tomu vždy jde vytvořit nějaké ORM, které jedním příkazem s pár parametry provést (různě) složitou operaci s mnoha dotazy SQL a jejich sestavením na pozadí. Ale to ORM musí nejdřív někdo vyvinout.

To jste úplně mimo - PL/SQL je přebrandovaná ADA, rozšířená o embedded SQL

https://en.wikipedia.org/wiki/Ada_(programming_language)

Který z výše uvedených problémů to řeší?

PL/SQL je plnohodnotný jazyk - podporující struktury, kolekce, kolekce kompozitních typů, globální proměnné. Takže jednoduše si můžete uložit seznam id, i seznam kompozitních hodnot. A můžete s nimi pracovat v PL/SQL, tak i v SQL. Kolekce je dictionary, hash tabulka, takže můžete dělat rychlé lookupy. I mnohem primitivnější T-SQL má inmemory tabulky - což jsou defakto pole kompozitních hodnot - a PL/pgSQL má pole jak skalárních hodnot, tak kompozitů - a existují konstrukce pro úzkou integraci s SQL. Je to mnohem efektivnější než z aplikačního serveru, protože nepřesouváte data po síti. Jinak, co PL/SQL umožňuje přenášení parametrů odkazem, co je samozřejmě rychlé. V Postgresu znám implementaci - všechny větší objekty se předávají funkcím přes ukazatele. Pouze, když je modifikujete, tak se vytváří kopie.

Jinak ke všem mně známým jazykům uložených procedur existují debuggery. Debugování je úplně v pohodě.

V podstatě nic z toho, co tu píšete o uložených procedurách není tak posledních 20 let pravda.

[Kit]

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.

Používám to na relačních datech. Ano, při projekci i selekci potřebuji znát seznam sloupců i kandidátních klíčů. Pokud to vadí, použiji pohled nebo vloženou proceduru. Pak si vystačím s "SELECT * FROM Pohled" nebo "CALL procedura(parametry)". Je to pro mne jednodušší, než to komplikovaně řešit v ORM. Také je to podstatně rychlejší - někdy i o dva řády.

Co je však podstatné, mám jednu šablonu na mnoho druhů výstupů z databáze. Ta šablona se jim jednoduše přizpůsobí a zobrazí data v závislosti na názvu pohledu i na dodaných sloupcích. Jen u větších projektů tu šablonu dělím na více menších, které dědí z jedné společné.

[BoneFlute]

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.

IMHO jedinej způsob - verzování:
Přihlásím se k verzi 1, a pošlu změny. Ve verzi 1 jsou háčky, které informují verzi 2. Verze 2 zpracuje události, a protože zná rozdíli, tak převede data z verze 1, na verzi 2. Verze 2 taky nemusí být poslední, tak se to přesouvá až po tu poslední, která jediná uloží data do databáze.
V reálu samozřejmě většina těch verzí už bude mrtvá, takže to bude 53 -> 54, maximálně 52 -> 53 -> 54.

V reálu ale málokdy a málokdo řeší tak ultimátní transparentnost, a většinou se prostě aplikace vypne -> zaktualizuje -> zapne. Což je sice na uživatele nemilosrdné, ale zase nevzniká ta obrovská zátěž v podobě držení zpětné kompatability.

[BoneFlute]

Vysvětlit ORM (namapovat) strukturu, aby to vůbec umělo, by bylo stejně složité, jako využívat přímo SQL.

V tomto se hrubě neshodneme.
Díky tomu nelze souhlasit s tvými závěry.

[Miroslav Šilhavý]

Vysvětlit ORM (namapovat) strukturu, aby to vůbec umělo, by bylo stejně složité, jako využívat přímo SQL.

V tomto se hrubě neshodneme.

Těžko nad obecnou (objektovou) strukturou dat vysvětlíte stroji, co a jak má/může optimalizovat. DB engine to může leda odhadovat nad vytipovanými statistikami. Když to necháte na takové empirii, buďto to bude neefektivní (nikdy nemůže vyzkoušet všechny možné přístupy ve všech možných kombinacích), nebo to bude ubírat výkon. Nebo dáte enginu hinty. Pokud by ty hinty měly být ideální, budou stejně složité jako v RDBMS / SQL.

Proto dnes vídáme horizontální škálování prezentované jako výhodu i v situacích, ve kterých by RDBMS stíhal i před dvaceti lety a s tehdejším hardwarem.

(Ovšem nerozporuji, že někdy může být takový přístup efektivnější, i z hlediska financí)

[BoneFlute]

Vysvětlit ORM (namapovat) strukturu, aby to vůbec umělo, by bylo stejně složité, jako využívat přímo SQL.

V tomto se hrubě neshodneme.

Těžko nad obecnou (objektovou) strukturou dat vysvětlíte stroji, co a jak má/může optimalizovat. DB engine to může leda odhadovat nad vytipovanými statistikami. Když to necháte na takové empirii, buďto to bude neefektivní (nikdy nemůže vyzkoušet všechny možné přístupy ve všech možných kombinacích), nebo to bude ubírat výkon. Nebo dáte enginu hinty. Pokud by ty hinty měly být ideální, budou stejně složité jako v RDBMS / SQL.

Proto dnes vídáme horizontální škálování prezentované jako výhodu i v situacích, ve kterých by RDBMS stíhal i před dvaceti lety a s tehdejším hardwarem.

(Ovšem nerozporuji, že někdy může být takový přístup efektivnější, i z hlediska financí)

Vůbec nereaguješ na to co píšu.

[Miroslav Šilhavý]

Vysvětlit ORM (namapovat) strukturu, aby to vůbec umělo, by bylo stejně složité, jako využívat přímo SQL.

V tomto se hrubě neshodneme.

Těžko nad obecnou (objektovou) strukturou dat vysvětlíte stroji, co a jak má/může optimalizovat. DB engine to může leda odhadovat nad vytipovanými statistikami. Když to necháte na takové empirii, buďto to bude neefektivní (nikdy nemůže vyzkoušet všechny možné přístupy ve všech možných kombinacích), nebo to bude ubírat výkon. Nebo dáte enginu hinty. Pokud by ty hinty měly být ideální, budou stejně složité jako v RDBMS / SQL.

Proto dnes vídáme horizontální škálování prezentované jako výhodu i v situacích, ve kterých by RDBMS stíhal i před dvaceti lety a s tehdejším hardwarem.

(Ovšem nerozporuji, že někdy může být takový přístup efektivnější, i z hlediska financí)

Vůbec nereagujete na to co píšu.

A na co tedy? Psal jsem, že stejně definitivně namapovat v ORM nebo jiné abstrakci datové struktury, aby byly srovnatelné výkonné, by byla stejně složitá práce, jako rovnou používat SQL.

[BoneFlute]

Vysvětlit ORM (namapovat) strukturu, aby to vůbec umělo, by bylo stejně složité, jako využívat přímo SQL.

V tomto se hrubě neshodneme.

Těžko nad obecnou (objektovou) strukturou dat vysvětlíte stroji, co a jak má/může optimalizovat. DB engine to může leda odhadovat nad vytipovanými statistikami. Když to necháte na takové empirii, buďto to bude neefektivní (nikdy nemůže vyzkoušet všechny možné přístupy ve všech možných kombinacích), nebo to bude ubírat výkon. Nebo dáte enginu hinty. Pokud by ty hinty měly být ideální, budou stejně složité jako v RDBMS / SQL.

Proto dnes vídáme horizontální škálování prezentované jako výhodu i v situacích, ve kterých by RDBMS stíhal i před dvaceti lety a s tehdejším hardwarem.

(Ovšem nerozporuji, že někdy může být takový přístup efektivnější, i z hlediska financí)

Vůbec nereagujete na to co píšu.

A na co tedy? Psal jsem, že stejně definitivně namapovat v ORM nebo jiné abstrakci datové struktury, aby byly srovnatelné výkonné, by byla stejně složitá práce, jako rovnou používat SQL.

Tak, to už je lepší. A v tom se neshodneme. Podle mne nebylo.

Ve skutečnosti si s něčím takovým hraju, takže to mám z první ruky. Napsat pravidla, kdy tomu ORM řeknu, že v tomto případě má použít tuto nebo jinou strategii je trivka.

[Miroslav Šilhavý]

Ve skutečnosti si s něčím takovým hraju, takže to mám z první ruky. Napsat pravidla, kdy tomu ORM řeknu, že v tomto případě má použít tuto nebo jinou strategii je trivka.

Ona je trivka i data rozložit do RDBMS - to je asi o osobní preferenci.
Pointa je v tom, že obě práce vedou k tomu samému - jen jinými prostředky, jiným jazykem a v jiných momentech popisujete totéž.

U objektových databází a ORM máte rychlý start a problémy lze dlouho řešit triviálními "hinty". Pak to narazí na mantinel, kde už s tím nejde hnout jinak, než refactoringem aplikace a horizontálním škálováním.

U RDBMS strávíte nějaký čas na začátku a v průběhu optimalizací. Na opravdový limit, kdy by bylo potřeba refactorovat aplikaci narazíte o mnoho později.

Abyste rozuměl, nehádám se o tom, že jeden přístup exceluje nad druhým. Pro oba mám pochopení a u obou vidím nevýhody i výhody.

Z části vznikají flamewary i z toho, že pro spoustu lidí je MySQL / MariaDB jediný RDBMS, který kdy poznali. Pokud bychom zúžili diskusi na MySQL, pak bych stál taky prakticky bezvýhradně na straně ORM a objektových databází.

[Logik]

BoneFlute:
Je trivka? Potkal jsem se s tím, že jeden dotaz jsem napsal asi deseti způsoby - unionem vevnitř, unionem venku, pomocí OR, pomocí materializované CTE, jednou byla podmínka tady, jednou ekvivalentní ale jiná tam, jednou se použilo DISTINCT ON, jednou radši window funkce, jednou GROUP BY atd. atd.... Moc si nedokážu představit, jak by takové hinty vypadaly....

 Moc nevěřím, že by šel napsat ORM tak, aby opravdu uměl uživatelsky pochopitelně  pokrejt a generovat opravdu všechny možnosti vyjádření toho samého dotazu, a přitom byl pořád jednoduchej a elegantní. Věřil bych, že jde napsat něco, co pokreje většinu běžně používanejch technik, ale že by opravdu obsáhnul 100% vyjadřovacích schopností SQL bych byl dosti skeptickej.
Co si dokážu představit je query builder, který to zvládne, a kterým nakrmím nějaký ORM. Ale nikoli něco, co mne od SQL odstíní. Ale třeba se pletu...