Rada při návrhu db tabulek

[SB]

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.

[Reklama]

[PanVP]

Ale to není vtip, to je krutá realita 

[Logik]

PanVP:To není realita, ale velmi jednostranný pohled. Respektive to cherry-pickuje zrovna ten příklad, pro který jsou dokumentové databáze (skutečných objektových moc není) opravdu vhodné.

V realitě často potřebuješ nejen koupit vybraný stromek, ale třeba najít ten, který má nejtmavší jehličí na druhé větvi od spoda. S relačními stromky prostě najdeš to jehličí, a pak se zeptáš prodejce, kterýmu že stromku to jehličí patří, on se podívá do papírů s podivným jménem index a během chvilky Ti to řekne.
Zatímco "dokumentový" prodejce v takovém bude v takovém případě dokolečka běhat přes prodejní plochu a nadávat jako špaček, protože Ti bude nosit jeden stromek za druhým, jen aby sis porovnal barvu jehličí na té správné větvi.

Každá technologie má své + a - a neexistuje "jediná správná technologie". Jen vhodné technologie na dané konkrétní nasazení. Přičemž jich může být i více, a ta vhodnost záleží i na tom, co daný člověk umí: u věcí "na hranici" ať to radši Mongař dělá v Mongu a nesnaží se o SQL, i když třeba by SQL přístup přinesl nějaké výhody - a naopak když se bude člověk s dokumentovou databází snažit pracovat "relačně", tak taky vznikne prasopes.

Takže jako vtip je to dost dobrý, ale dělat z toho nějakou hlubokou pravdu je ulítlý....

[Miroslav Šilhavý]

...

Chtěl jsem napsat něco podobného. Někdo myslel na dobrý, jednoduchý prodej. Jenže za týden si manažer vzpomene, že chce statistiku stromků na skladě, podle druhu stromu a velikosti. Jenže v návrhu objektu někdo zapomněl na krabici nalepit tyto informace zvenčí. A tak se otevírá jedna krabice za druhou, aby se někdo nakoukl, co je vevnitř. A manažer se diví, proč je na to potřeba tří směn, než mu někdo takovou informaci dodá.

:-)

[PanVP]

Jáááááj, to jsem nevěděl, že tohle se svojí db nemůžu dělat  tak snad abych takovou funkčnost ze svých projektů odebral no....   

[Reklama]

[Miroslav Šilhavý]

Jáááááj, to jsem nevěděl, že tohle se svojí db nemůžu dělat  tak snad abych takovou funkčnost ze svých projektů odebral no....   

Ale jo, jen se ta databáze kurevsky nadře ve srovnání s relační.

[PanVP]

Mám dva druhy dat - první se pohodlně vlezou do 1 GB a bydlí si v paměti, to je problém pro Pentium 3 Tualatin.
A data nad 10 TB....a to je problém i pro můj cluster.

[Ink]

Mám dva druhy dat - první se pohodlně vlezou do 1 GB a bydlí si v paměti, to je problém pro Pentium 3 Tualatin.
A data nad 10 TB....a to je problém i pro můj cluster.

No a já znám i další druhy dat, na které se skvěle hodí relační databáze. I kdyby byla celá v RAM, pořád na ně bude vhodnější než NoSQL.

[M_D]

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

[Vietnanka]

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.

Pozor,  muze jit pouze o objektovou tovarnu, kterou provozuje jedinacek a nemuzete prijit s pozadavkem na nejaky abstrakni stromek. A pokud nezkonstruujete objednavku, tak ani dal nepokracujte. Pokud jejich stromek je finalni vyrobek na nejaky extra pozadavky zapomente.

A specifikovat vlastnosti toho stromku taky nemusi byt med, treba jehlice chcete jine, ale prodavac je nemy tak jen pres rozhrani  posunku opakuje ze ty jehlice jsou takove a menit to nejde.

Nebo jestli barvu staci rict slovem nebo najit ve vzorniku Tridy pantone a pri konstrukci objednavky nebo  metodou Vyberbarvu..


A opovazte se odejit bez destrukce uctenky.


V relacnim svete by byl akorat pruser nezauctovat transakci, to by triggernulo Scillerovou ktera by kaskadove zaklekla na vsechny subdodavatele z databaze financniho gestapa

[Google CTCCTCGGCGGGCACGTAG]

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

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

[PanVP]

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

Ano, ano, použijeme rovnák na ohýbák!  To bude cool!
ORM totiž je právě ten rovnák na ohýbák...

Nejsem proti relačním databázím, rozhodně ne, ale velmi často jsou zkrátka naprosto nevhodně použité.
Zlomená ruka? Do sádry! Nakřupnutá hlava? Do sádry! Zlomený prst? Do sádry! Zánět slepáku? Do sádry!

Je zajímavé, že pokud do sádry plácnete pacoše se zápalem plic, může mu to částečně ulevit...a třeba se i uzdraví = další argument dávat sádru.

Proč bych se měl drbat se složitou konstrukcí tabulek, když to vyřeší objektová případně nosql databáze?
Jednoduše, moc příjemně se s ní pracuje. Ano, možná ten systém nezvládne 10 000 000 současných dotazů, z čehož nemůžu spát, protože těch současných dotazů jsou maximálně tisíce a systém by zvládl i statisíce dotazů.

Databáze Oracle? Použij server !!! TURBO!!! MEGA!! RAID, hotplug, ECC killchip, iWARP, quadsocket, RAMSTORAGE!
Mašina na AI? Použij server !!! TURBO!!! MEGA!! RAID, hotplug, ECC killchip, iWARP, quadsocket, RAMSTORAGE!
Počítač na malování? Použij server !!! TURBO!!! MEGA!! RAID, hotplug, ECC killchip, iWARP, quadsocket, RAMSTORAGE!
Co?
Na malování použít server?
NO JISTĚĚĚ...co kdyby se požadavky zvýšily....

[Miroslav Šilhavý]

...

Tak jistě, to co tady píšete, je pravda.
V praxi není problém v tom, že by jeden nebo druhý přístup byl lepší. Většinou to hapruje na tom, že výběr technologie se nečiní kvalifikovaně, provádí ho někdo jiný, než ten, kdo má představu o budoucnosti projektu. Dost často ho dělá i ten, který nezná oba přístupy a jejich výhody a nevýhody.

Dohady v diskusích vnímám spíš tak, že spousta lidí (a já mezi ně patřím) považuje za bezpečnější a potentnější přístup, aby programátor nejprve na slušné úrovni ovládl RDBMS a pochopil, že skládat jehličky do větviček a do stromku nemá jen nevýhody, ale i výhody. Aby v budoucnu mohl kvalifikovaně posoudit, na co se hodí jaká technologie. Mezistupeň v poznání jsou ORM, u kterých taky pochopí další výhody a nevýhody. Tento postup je dialektický.

Proti tomu velmi často najdete programátory, kteří RDBMS neznají - maximální poznání u nich končí u joinu v mysql a jeho výkonnostních problémů. Jestli vyžadují ACID neumějí zodpovědět, ve skutečnosti ani fakticky neznají důležitost takové otázky, maximálně definici z papíru. S takovými je pak těžko diskutovat, radit a rozebírat jejich otázky typu "jakou databázi mám zvolit". Kdyby ty základní zkušenosti měli, nepoložili by takovou fundamentální otázku. Když ty znalosti nemají, je (myslím si) lepší začít od rozumných základů poznání.

To si můžete povšimnout i zde, na rootu, že když se někdo orientuje a potřebuje prodiskutovat jen nějaký technický detail nebo zkušenost, diskuse jsou věcné. Zvrtnou se ve většinou jen ve chvíli, kdy se ukáže, že na začátku asi stojí nějaký chybný úsudek. Většinou to pak končí tím, že tazatel je zklamán, že na špatnou otázku ve špatně nastavené situaci nedostane dobrou odpověď, která by vyřešila všechna trápení světa.

[PanVP]

Předně, myslím, že panuje jistá úroveň shody.

Dále, domnívám se, že budoucnost leží ve spojení / unifikaci databázových enginů.
Všichni experimentují s NoSQL což ovšem nutně není/nemusí být objektová databáze, případně objektová databáze může být podskupinou NoSQL databází.

Tato diskuze ztratí veškerý smysl ve chvíli, kdy bude jen na uživateli, jaký model použije.
Jako velký příznivce MongoDB si rozhodně nedovedu představit, jak bych do toho dal pouhých pár milionů záznamů a efektivně s nimi pracoval. Stejně tak si nechci vzpomínat, jak jsem se drbal s návrhem databáze pro tak triviální věc, jako je docházkový systém, který jsem se ...já hňup... zavázal udělat za kamaráda zadarmo, protože za to přeci nebude dávat třicet tisíc.

Vždycky si vzpomenu na prosté: A...hřebík zatloukej kladívkem a díru vrtej vrtačkou, nikdy obráceně? Chápeš? Tak chápeš? Evidentně ne...

[Miroslav Šilhavý]

Tato diskuze ztratí veškerý smysl ve chvíli, kdy bude jen na uživateli, jaký model použije.

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.

Jestli má tato diskuse smysl, tak podle mě naopak jedině ve chvíli, kdy se bavíme o rozdílech, mezi kterými lze volit.

Ono je ve skutečnosti jedno, jestli stejné vazby a principy manipulace s daty popíšete v SQL, nebo objektově. Bude se lišit řeč zápisu, ale jinou řečí budete popisovat totéž. Jestli mají objektové databáze nějakou výhodu, tak je to právě v tom, že pro spoustu úloh se dá zápis zjednodušit o popis toho, co RDBMS vyžadují (řekněme "zbytečně") a naopak se zaměřit na popis vlastností, které se v RDBMS zapisují složitě.