Rada při návrhu db tabulek

[Ink]

No já vidím takový fundamentální problém. Objektové databáze mohou teoreticky dosahovat stejných výkonů, jako relační. Jenže, aby toto opravdu nastalo, bylo by potřeba objekty a vlastnosti popsat tak definitivně, že by si takový popis svojí složitostí nezadal s relačními databázemi.

Fundamentalni problem je OOP jako takove. Vsechno ostatni jsou nasledky.

[Reklama]

[Logik]

PanVP:

ORM - rovnák na vohejbák.

Ne, to není rovnák na vohejbák. To je způsob, jak si zjednodušit práci se SQL databází, aniž bys ztratil možnost používat některé možnosti SQL, které v NoSQL přístupu prostě nemáš. Dívej se na to jako na vícevrstvou technologii: narozdíl od NoSQL, kterej je monolit a máš přístup jen do nejvyšší vrstvy, v ORM máš možnost, když "standadní implementace nevyhovuje", jít o vrstvu níž a získat to, co potřebuješ, efektivně.

Samozřejmě za to i platíš (např. vznikají problémy, jestli má být logika v DB nebo v APP) - každá technologie má své silné a slabé stránky.

jak jsem se drbal s návrhem databáze pro tak triviální věc

Sorry, ale todle není problém SQL, ale toho, že s SQL nemáš praxi. Což není nic špatného, dokumentuje to jednu z nevýhod SQL: pomalejší křivku učení.

Proč bych se měl drbat se složitou konstrukcí tabulek, když to vyřeší objektová případně nosql databáze?

Úplně stejně Ti můžu odpovědět. Proč bych se měl drbat dokolečka s psaním rutin na vyhledávání těch správných záznamů v NoSQL, když v SQL to mám zadarmo, a podstatně výkonnější (u složitějších dotazů), než je schopen napsat za rozumný čas jeden člověk?
Ona složitost SQL dekompozice je ve skutečnosti jen zdánlivá nevýhoda. Když to umíš, tak bez probléímů rychle a správně rozložíš cokoli do SQL relací zcela automaticky a rychle. Jasně, ne tak rychle, jako v NoSQL, ale oproti implementaci logiky to rychlé je.
 To, co je velká výhoda NoSQL přístupu pro jednodušší projekty - superrychlej návrh struktury, protože do ní nacpeš "cokoli jakkoli" je ve skutečnosti zároveň slabina NoSQL. Protože zatímco v SQL máš danej formát rozpadnutí na relace, kterej je pro danou "logickou strukturu" jeden, NoSQL je v podstatě moderní reinkarnace stromových databází. Se všemi plusy: snadná práce s daty, když "lezeš po stromě" a mínusy: když potřebuješ chodit "napříč lesem" - a tedy nutností dobře navrhnout strukturu stromečků.

Takže zatímco v SQL databázi se navrhuje databáze "automaticky" a při dodržení patřičných pravidel to "nejde udělat blbě" (trochu přeháním, ale v porovnání s NoSQL to platí), v NoSQL u složitějších případů je poměrně podstatné, jestli se člověk na začátku vývoje "strefí" do datové struktury, která bude vhodná i třeba po letech - a tedy narozdíl od SQL databáze by ses tedy měl podstatně více drbat s analýzou dat, budoucích požadavků atd.... Anebo daleko víc času, než jsi získal "superrychlým první návrhem", ztratíš refaktory databáze když zjistíš, že tam nějaký požadavek nejde udělat efektivně.

===

Ink:Problematičnost OOP se týká toho, jestli a jak je správné "bundlovat" data a kód - a to se vůbec netýká toho, jak jsou data uložena. Kolekce nějakých datových struktur a potřebu jejich persistentního uložení (často včetně požadavků na transakce) máš snad u každého (reálně použitelného) programátorského paradigmatu.

[BoneFlute]

Protože zatímco v SQL máš danej formát rozpadnutí na relace, kterej je pro danou "logickou strukturu" jeden,

Což je super věc. Protože následně můžeš udělat nástroj, který ti rozpadnutí na relace udělá za tebe. Takže máš výhody obou světů.

[Miroslav Šilhavý]

Protože zatímco v SQL máš danej formát rozpadnutí na relace, kterej je pro danou "logickou strukturu" jeden,

Což je super věc. Protože následně můžeš udělat nástroj, který ti rozpadnutí na relace udělá za tebe. Takže máš výhody obou světů.

Tak jednoduché to není. Síla RDBMS je ve výkonu, a totéž se dá řešit různými způsoby s odlišným dopadem na výkon v různých situacích. Informace může být v tabuli, může být napojena vazbou, může být uložena jako pole (nebo obdobný komplexní typ) v tabuli... Míru rozpadnutí do vazeb nástroj nerozhodne, protože to rozhodnutí se opírá o předpokládaný způsob užití a požadavek výkonu při různých operacích.

S trochou nadsázky by se dalo říct, že "stejně blbě" jako NoSQL databáze by to mohl udělat i nástroj (ostatně, ORM), a pak by opravdu nebyly RDBMS potřeba.

[BoneFlute]

Protože zatímco v SQL máš danej formát rozpadnutí na relace, kterej je pro danou "logickou strukturu" jeden,

Což je super věc. Protože následně můžeš udělat nástroj, který ti rozpadnutí na relace udělá za tebe. Takže máš výhody obou světů.

Tak jednoduché to není. Síla RDBMS je ve výkonu, a totéž se dá řešit různými způsoby s odlišným dopadem na výkon v různých situacích. Informace může být v tabuli, může být napojena vazbou, může být uložena jako pole (nebo obdobný komplexní typ) v tabuli... Míru rozpadnutí do vazeb nástroj nerozhodne, protože to rozhodnutí se opírá o předpokládaný způsob užití a požadavek výkonu při různých operacích.

To řeším tak, že tomu systému přidám hint. Takže když mám pole struktur, tak defaultně mi z toho vytvoří defaultní relaci. Ale mohu dodat informaci, že lepší je tato startegie. Výhoda SQL je ten matematickej aparát, kterej problém extrahuje do několika málo strategií (v základu šesti). S čímž se přirozeně lépe pracuje, než s "libovolností" u jiných řešení.

pak by opravdu nebyly RDBMS potřeba.

RDBMS je potřeba. Přece to engine nebudu psát znova!
Co není je potřeba low-level SQL+Relační algebra.

[Reklama]

[BoneFlute]

Ten neznám, sem s ním 

V objektovém obchodu s vánočními stromky ukážete na stromek, který chcete, vezmete, zaplatíte, odejdete.

V relačním obchodu jsou v jednom rohu opřené kmínky, každý z nich má číslo a v sobě díry pro větve, kdy každá díra má malinkaté čisílko. O kus vedle je na zemi hromada větví, každá větev má číslo a na sobě mnoho malých čisílek - vy si musíte vyhrabat ty s odpovídajícími čísly z vybraného kmínku. Ještě o kus dál je veliká krabice s jehličím, kdy každá jehlička má opět číslo - vy opět hledáte jehličky odpovídající čisílkům na větvích. Když to všechno dohledáte, stromek sestavíte, zaplatíte, odejdete.

IKEA?

[Ink]

Ink:Problematičnost OOP se týká toho, jestli a jak je správné "bundlovat" data a kód - a to se vůbec netýká toho, jak jsou data uložena. Kolekce nějakých datových struktur a potřebu jejich persistentního uložení (často včetně požadavků na transakce) máš snad u každého (reálně použitelného) programátorského paradigmatu.

A říkám, že ne? Podle mě to jsou ale spojené nádoby - jestliže nějak strukturuješ/modeluješ aplikaci, má to vliv i na to, jak nakládáš s daty při ukládání nebo rekonstrukci z DB. Pokud je řádek z tabulky struktura/n-tice, prostě ji pošleš dál nebo ji něčím rozšíříš, abys dostal kýžený tvar, se kterým chceš pracovat. Jakmile musíš řešít, jestli ta struktura je autonomní chytrý objekt, jehož vnitřní uspořádání je zapouzdřené a nikomu do něj nic není, najednou se to blbě napasovává třeba na relační databázi...

[Logik]

jehož vnitřní uspořádání je zapouzdřené a nikomu do něj nic není... [/size]najednou se to blbě napasovává třeba na relační databázi...

Když je dobře udělanej datovej objekt, tak se Ti IMHO na relační databázi pasuje úplně stejně dobře, jako "surová data" ve formě ntic.

, prostě ji pošleš dál nebo ji něčím rozšíříš, abys dostal kýžený tvar, se kterým chceš pracovat[/size]

To imho není dobrá strategie. Kód by měl mít nějakou "kulturu" a mezi to patří i rozumně definované interfacy (nikoli v objektovém smyslu) funkcí. Když rozumně navrhneš datové struktury, tak - ať už jim budeš říkat objekt, ntice nebo nevímjak - tak bys s nimi neměl mít potřebu pokaždé manipulovat na jiný tvar.


Já osobně mám zkušenost, že nejlepší architektura SW je taková, kde ten SW pokudmožno co nejlépe "modeluje realitu". A pokud tomu tak je, pak model objektů (datových struktur) jde na DB napasovat dobře, protože ta má také modelovat realitu. Samozřejmě, že to nesmí bejt tak, že DB dělá jeden člověk, návrh datových struktur v backendu někdo jiný, a pak se divěj, když každej zjednodušší realitu (protože vždy je třeba zjednodušit) jinak...


Ale to je problém vždy: i když nebudíš mít nějak vynucené datové struktury, tak si třeba krátkodobě pomůžeš tím, že tam, kde se Ti to tluče, tak to "nějak vohneš". Ale z dlouhodobého hlediska je vždy lepší to zrefaktorovat tak, aby si interfacy sedly. A pokud je interface na druhé straně neměnný (3rd-party library) tak zas není dobrá strategie se ji "přizpůsobovat" (co když to v další verzi změní), ale lepší je zavést si tam konverzí funkce.

[xyz]

ORM je tzv. "leaky abstraction" -  https://en.wikipedia.org/wiki/Leaky_abstraction

[Google CTCCTCGGCGGGCACGTAG]

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.

[SB]

Ale to není vtip, to je krutá realita 

Já vím, ale nechtěl jsem vám to kazit.

[SB]

A blbé je, když se ti sejde věc, kde potřebuješ vedle sebe ideálně na něco relační, na něco timeseries a na něco NoSQL/dokumentační pohled... (a pokud těch dat je opravdu hodně, takže je blbé přiohýbat vše do jednoho konceptu).
Pak snad jedině narvat tam dopředu něco jako Apache Ignite, do něj nacpat transformační logiku, definovat mu pár vzdálených backendů paralelně vedle sebe - PostgreSQL, Cassandra, CouchDB, ... a mlátit/číst data přes to Ignite dle chuti chvíli jako K/V, chvíli jako SQL (zde to má svoje ale) a ať si s tím gulášem poradí a nejčastější data drží v RAM cache. :-)

Jsou 2 řešení: To vaše - budete to mít v jedné DB (což samo o sobě je otázkou, zda to stojí za to, u velkých systémů je stejně více zdrojů dat), ale ta data budete muset přeprzňovat mezi jejich a DB formátem. Nebo použijete pro každý typ dat určenou DB, ale bude to rychlé a bez přeprzňovaček.

[SB]

Vetsina nevyhod relacnich databazi (ukecanost, synchronizace schematu s kodem) mizi pri pouziti rozumneho ORM.

Ale z podstaty věci to zadarmo nebude, že?

https://en.wikipedia.org/wiki/Object%E2%80%93relational_impedance_mismatch

[Ondrej Nemecek]

A blbé je, když se ti sejde věc, kde potřebuješ vedle sebe ideálně na něco relační, na něco timeseries a na něco NoSQL/dokumentační pohled... (a pokud těch dat je opravdu hodně, takže je blbé přiohýbat vše do jednoho konceptu).

Jsou 2 řešení: To vaše - budete to mít v jedné DB (což samo o sobě je otázkou, zda to stojí za to, u velkých systémů je stejně více zdrojů dat), ale ta data budete muset přeprzňovat mezi jejich a DB formátem. Nebo použijete pro každý typ dat určenou DB, ale bude to rychlé a bez přeprzňovaček.

Nejde třeba použít Postgres která umí fungovat i jako NoSQL, JSON a timeseries databáze (nemám zkušenost)? Kombinujete to někdo takto u Postgres?

[Kit]

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.

SQL je dostatečně expresivním jazykem, většina ORM toho nedosahuje.