Rada při návrhu db tabulek

PanVP

Re:Rada při návrhu db tabulek
« Odpověď #75 kdy: 25. 06. 2021, 07:26:29 »
https://www.krcmic.cz/krumpac-x-krompac/

Jsem rád, že můj příspěvek umožnil přispět do diskuze i lidem, jako jste vy.


Kit

  • *****
  • 853
    • Zobrazit profil
    • E-mail
Re:Rada při návrhu db tabulek
« Odpověď #76 kdy: 25. 06. 2021, 09:40:05 »
Citace
Např. 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í.

Adaptace aplikace na změnu struktury může být rovněž jednoduchá. Stačí ji řídit tokem dat z databáze - pracuje pak se starou i novou verzí bez vidliček. Dělám to tak už dlouho a je to velmi efektivní.

Logik

  • *****
  • 1 049
    • Zobrazit profil
    • E-mail
Re:Rada při návrhu db tabulek
« Odpověď #77 kdy: 25. 06. 2021, 10:09:14 »
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?

Kit

  • *****
  • 853
    • Zobrazit profil
    • E-mail
Re:Rada při návrhu db tabulek
« Odpověď #78 kdy: 25. 06. 2021, 10:48:12 »
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?

Můžeš. Výsledkem DB dotazu je množina slovníků (asociativních polí). Stačí ji přes nějaký foreach nebo map nasypat do DOMu, který pak předhodíš šabloně, která ho traverzuje a exportuje do výstupní podoby. Chybějící sloupce nezobrazí, přebývající sloupce zobrazí v základním režimu. Nikde žádné vidličky, v šabloně žádné cykly a nejlépe žádné podmínky.

Logik

  • *****
  • 1 049
    • Zobrazit profil
    • E-mail
Re:Rada při návrhu db tabulek
« Odpověď #79 kdy: 25. 06. 2021, 11:12:42 »
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

  • *****
  • 853
    • Zobrazit profil
    • E-mail
Re:Rada při návrhu db tabulek
« Odpověď #80 kdy: 25. 06. 2021, 11:37:38 »
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.

K tomuto účelu se dají využít pohledy a původní tabulky zamknout před aplikací. Stará verze se tak k datům nedostane, což je ten lepší případ. Business logiku jsem dal do databáze, protože každý zákazník má svá specifika a chci udržovat jen jednu aplikaci.

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.

Testy samozřejmě musí vypadat jinak.

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.

Tady mohou pomoci pohledy a uložené procedury. Data z databáze zpracovat reflexí, viz výše. Aplikace v podstatě nepotřebuje znát strukturu databáze, se kterou pracuje.

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.

Stromové databáze zpracovávám traverzováním, případně v XML použiji XPath. Ovšem pro hromadné výstupy je to traverzování obvykle výhodnější, protože tu strukturu jednoduše znát nemusím.

Logik

  • *****
  • 1 049
    • Zobrazit profil
    • E-mail
Re:Rada při návrhu db tabulek
« Odpověď #81 kdy: 25. 06. 2021, 11:53:57 »
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...

Kit

  • *****
  • 853
    • Zobrazit profil
    • E-mail
Re:Rada při návrhu db tabulek
« Odpověď #82 kdy: 25. 06. 2021, 12:14:11 »
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.

Dost se toho dá napsat i bez vnořených procedur - pohledy toho také umí hodně. V některých databázích do nich můžeš i insertovat.

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

To právě není založeno na hledání v DB (samozřejmě do SELECT dávám selekci i projekci). Dostanu z ní data v nějaké struktuře a teprve v aplikaci hledám, jak ji mám zpracovat. Je to obrácený postup, který je dokonce rychlejší a přizpůsobí se prakticky jakékoli struktuře.

Logik

  • *****
  • 1 049
    • Zobrazit profil
    • E-mail
Re:Rada při návrhu db tabulek
« Odpověď #83 kdy: 25. 06. 2021, 13:01:01 »
Jasně, ale i insertovací pohledy a pohledy vůbec je věc, kterou používá (a teda i umí efektivně použít) jen malá část lidí. Ale jinak samozřejmě, to jsou nástroje, kterejma se v SQL dají krásně zastřít změny DB, což je jedna z výhod SQL řešení.

Citace
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ě. Když se zase vrátím k tomu příkladu s předměty a učitely, kde můžu mít jak kolekci učitelů, kde každej má pod sebou předměty, nebo kolekci předmětů, kde každej má pod sebou učitele, tak si nedokážu představit, jak bez znalosti konkrétní struktury z toho vytáhnout např. seznam (unikátních) předmětů, aniž bych např. zkoušel obě možnosti (což znamená vydličky v kódu), nebo stáhnul "celou db" a pak to v ní "naslepo" (oni třeba ty předměty mohou být pověšeny ještě pod třídama atd....) hledal objekty typu předmět.

SB

  • ****
  • 347
    • Zobrazit profil
    • E-mail
Re:Rada při návrhu db tabulek
« Odpověď #84 kdy: 25. 06. 2021, 13:22:22 »

Pane Logiku, já si myslím, že si moc nerozumíme.

SB

  • ****
  • 347
    • Zobrazit profil
    • E-mail
Re:Rada při návrhu db tabulek
« Odpověď #85 kdy: 25. 06. 2021, 13:35:04 »
SQL je dostatečně expresivním jazykem, většina ORM toho nedosahuje.
Neni, je to jazyk nizke urovne abstrakce...

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.

Re:Rada při návrhu db tabulek
« Odpověď #86 kdy: 25. 06. 2021, 13:52:17 »
SQL je dostatečně expresivním jazykem, většina ORM toho nedosahuje.
Neni, je to jazyk nizke urovne abstrakce...

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.

Problém všech abstrakcí je, že zjednodušují vývoj, ale zhoršují výkon oproti práci s normalizovanými datovými strukturami. Ideální ORM by umělo dokonale převádět požadavky do SQL, rozhodovat se, kdy užívat transakce a kdy ne, jak uzamykat záznamy, ... Vysvětlit ORM (namapovat) strukturu, aby to vůbec umělo, by bylo stejně složité, jako využívat přímo SQL.

ORM a NoSQL volí určitý kompromis, někdy přidávají možnost horizontálního škálování výkonu.

To, co vyvolává hádky mezi zastánci těchto dvou přístupů je právě to, že ten kompromis je od určitého okamžiku už nepřekročitelný, a schopnosti RDBMS databáze se suplují na úrovni aplikace (či jazyka). Z pohledu vývoje je to možná pohodlnější (možná jen zdánlivě, vedou se o tom spory).

Funguje to dobře, když vývoj i zadavatel aplikace jsou srozuměni s tím, co to obnáší a bude obnášet do budoucna. Srážka nastává, když pak přijdou požadavky, nápady, nebo kritika řešení, které by se daly řešit mnohem efektivněji pomocí RDBMS.

Pak si taky všímám, že někteří schopnosti databáze posuzují z pohledu, jak pohodlně jim naservíruje výsledky až k cílovému zpracování. Jiní zase vnímají, že uvnitř těch mechanismů musí být spousta práce (= ztraceného výkonu), která se vynakládá vzdáleně od optima.

Podle mě je ten myšlenkový souboj nerozsouditelný, podobně jako se nedá najít jednoznačná odpověď, jestli koupit levnou Dacii nebo drahé Audi, když jsou obě auta stejně velká a ve městě jezdí stejně rychle (50-80 km/h) a argumentovat tím, "co kdyby přišla potřeba jezdit napříč Evropou". Jeden koupí preventivně Audi, druhý si koupí letenku a oba jsou spokojení se svým řešením.

Logik

  • *****
  • 1 049
    • Zobrazit profil
    • E-mail
Re:Rada při návrhu db tabulek
« Odpověď #87 kdy: 25. 06. 2021, 14:19:20 »
SB:
To si asi nerozumíme. Ale když nenapíšeš v čem, tak to působí, že si radši ani rozumět nechceš :-)
Vezmu stejný příklad jako jsem psal: učitele a předměty ve škole. V SQL to namodeluju jednoduše a existuje pouze jeden způsob, který dodržuje pravidla: tabulka učitelů, tabulka předmětů, a vazební tabulka X učí Y.
Jak toto namodeluješ v dokumentové databázi? Jako kolekci učitelů, kde každej bude mít pod sebou seznam "učených předmětů"? Jako kolekci předmětů, kde každej bude mít pod sebou seznam učitelů, co je učí? Nebo jako dvě nezávislé kolekce, kde v každém prvku každé kolekce bude seznam odkazů na prvky té druhé kolekce (X učí Y a Y je učen X)?  Nebo jinak?
Jaké konkrétní řešení zvolíš a proč? A je Tebou zvolené řešení jediné "správné", nebo bys jindy volil jiné?

 
Citace
Kit měl asi na mysli PL/SQL
To IMHO neměl. Navíc se pleteš. Jednak PL/SQL i PL/PgSQL např. jak struktury, tak seznamy umí, viz např.
https://docs.oracle.com/cd/A84870_01/doc/java.816/a81354/oraoot2.htm
https://www.oracletutorial.com/plsql-tutorial/plsql-varray/
jednak např. v Postgresu klidně můžeš psát stored procedures třeba v Pythonuhttps://www.postgresql.org/docs/9.0/plpython.html
Citace
jakákoliv práce se seznamy znamená opakované čtení dat z tabulek.
Což jednak není pravda (viz výš), jednak (např. díky temporary tables atd...) ani opakovaný select vybraných dat nemusí být žádný problém.

Ty furt cpeš SQL do pozice jednoduchého jazyka na primitivní selekty, jako znáš z dokumentovejch databází. Čím více osekáš SQL (a návazné technologie), tím to samozřejmě líp zapouzdříš do nějakého ORM, aniž by to bylo omezující. To je sice jeden z možných usecase pro SQL (kde jsou případy, kdy tento přístup bude lepší než NoSQL - kvůli univerzálnějšímu způsobu uložení dat a s tím spojenou schopností DB optimalizovat plány a číst data z DB efektivně - ovšem také případy, kdy bude NoSQL podstatně lepší volba) - ale zbytečně tím házíš mnoho z možností, které SQL nabízí, do kanálu.




Miroslav:To bych podepsal. A ještě bych přidal, že bohužel dosti často majitelé Audi haněj letadla, že je to neflexibilní řešení, a Ti co létají haněj Audi, že jsou drahé. A to zpravidla Ti, co třeba nikdy tím letadlem neletěly, takže nevidí jeho výhody a jen nevýhody - a naopak.

SB

  • ****
  • 347
    • Zobrazit profil
    • E-mail
Re:Rada při návrhu db tabulek
« Odpověď #88 kdy: 25. 06. 2021, 14:26:00 »
Adaptace aplikace na změnu struktury může být rovněž jednoduchá. Stačí ji řídit tokem dat z databáze - pracuje pak se starou i novou verzí bez vidliček. Dělám to tak už dlouho a je to velmi efektivní.

Přesně tak. Aplikace (server) od začátku přímo počítá s různorodostí a změnou dat (což je tak nějak z podstaty nevyhnutelným požadavkem pocházejícím ze skutečného světa). 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 (zde neřeším GUI atd.) bez zásahů do DB.
To samé v RDB znamená upravit schéma (nedej bože předělávat procedury a ladit je), upravit data (ano, obvykle s odstávkou DB, aby se to celé nepodělalo (závisí na provedení RDB)), v aplikaci přepracovat obvykle statickou strukturu na jinou. V případě, je-li aplikace statická, pak synchronizace nasazení změn DB a aplikace.

Ale pane Logiku, ať se nehádáme: Dělejte si to, jak chcete.

Re:Rada při návrhu db tabulek
« Odpověď #89 kdy: 25. 06. 2021, 14:30:55 »
A ještě bych přidal, že bohužel dosti často majitelé Audi haněj letadla, že je to neflexibilní řešení, a Ti co létají haněj Audi, že jsou drahé. A to zpravidla Ti, co třeba nikdy tím letadlem neletěly, takže nevidí jeho výhody a jen nevýhody - a naopak.

Mám stejný pocit. Mám dokonce častou zkušenost, že když se zavilým příznivcům ORM a NoSQL na konkrétních usecasech ukáže ekvivalent v RDBMS, tak pochopí, že výsledná složitost není vyšší a potenciál výkonu vyšší je ("kdybych býval věděl, co budu potřebovat a jak se projekt vyvine, tak bych použil RDBMS od začátku, protože by to byla stejná práce a výsledek lepší").

Na druhou stranu ale neignorujme, že někdy je flexibilita řešení cennější, než jeho výkon. Mnohdy, v reálném životě, je lepší hrnout rychle neoptimální řešení. Často se v praxi přijde na to, že včerejší nápad je potřeba dnes stejně přehodnotit (ne kvůli technickým nedostatkům, ale prostě v životě nefunguje) - a to se stihne 2x udělat rychleji, než v RDBMS rozmyslet první změnu ve schematu.