Diskuze: Doporučení No-SQL object databáze pro použítí v .NETu?
V předchozím kvízu, Test znalostí C# .NET online, jsme si ověřili nabyté zkušenosti z kurzu.
Erik Šťastný:15.5.2017 14:02
Tím mám na mysli např Listy.
Jde o RPG hru, takže jeden hráč má pod sebou například postavičku, kterých je proměnlivý počet a ta má pod sebou určitá kouzla a určité vybavení, určitý inventář s proměnlivým počtem slotů atp.
Jasně, že se to dá řešit klasickýma tabulkama a vazbami jako to má 99%
aplikací a firem, nicméně mnohem rád bych vyzkoušel objektové databáze,
které mi v tomhle přijdou daleko blíže principu OOP, než zažité SQL 
Navrhni si tu databázi v jsonu i v sqlku na jednoduchém příkladu ("objektu"). Zamysli se, jak projekt poroste a jak k tomu budeš přistupovat. Budeš potřebovat vazby? Něco jimi hlídat? Chceš škálovat? jak? redundance?
.NET nepoužívám, ale asi budeš chtít aby existoval driver pro zvolené úložiště. Na to je také dobré dávat pozor. V případě sql databáze možná i nějaké ORM ( i když může být nakonec brzdou výkonu, navzdory rychlejšímu vývoji...)
No-SQL přístupů existuje také celá řada, proto musíš hlavně vědět
co chceš
Erik Šťastný:16.5.2017 7:50
O to právě jde, navrhnout jeden json objekt mi přijde úplně krásné a přehledné, než mít data v xx tabulkách rozházené, tak že pro nezasvěceného člověka je to akorát halda IDček odkazující na jiné tabulky a pořád dokola. (příklad. hráč má xx postav, ty mají xx kouzel, ty mají xx věcí v inventáři atp.)
Knihovna pro databázového klienta v c# je samozřejmost
Preferuji jednoduchý přístup pro ukládání a načítání dat vcelku rozsáhlých větvících se objektů, které půjdou snadno rozšiřovat podle nových požadavků aplikace což mě jako pro databázového neznalce přijde v MSSQL nebo MySQL apod. daleko složitější
Co se týče rychlosti, ta hádám, že není u tahového RPG, kde na víc se většina potřebných transakcí do DB načte ihned při přihlášení uživatele do hry, vůbec prioritou.
Erik Šťastný:16.5.2017 8:17
Osobně si teda myslím, že každému nováčkovi, který nikdy neviděl RDBMS systém, tak mu přijde objekt v jsonu daleko přehlednější než 10 tabulek s vazbami.
Nezasvěceným člověkem samozřejmě nemyslím hráče, ale člověka,
který například nějak minimálně spolupracuje na vývoji. Mě fakt
nenapadlo, že to někdo pochopí jako hráče, to pardon 
Jiří Sedláček:16.5.2017 8:54
To je tvůj osobní názor. Dovol abych také jeden přidal. Zvlášť
nezasvěcený člověk dovede špatně navrhnout no-sql databázi. V sql je
jistá šance, že tě to donutí navrhnout aspoň trochu slušně. A i v no-sql
(třeba mongo) se používá více kolekcí a reference mezi nimi.
Proto jsem ti psal ať si zkusíš nějakou jednoduchou entitu reprezentoval
oběma přístupy a zamyslíš se nad tím jak to bude vypadat dál
Erik Šťastný:16.5.2017 9:06
No to už jsem prakticky zkusil. V aplikaci mám objekt hráčův profil, který je prakticky to nejpodstatnější v celé hře a obsahuje všechny informace o hráči. v MySql mám momentálně tabulku, Profile, která v sobě obsahuje IDčka k tabulce Postavy ty obsahují IDčka k tabulkám kouzla,itemy apod.
Nicméně jsem se taky zasekl jak udělat proměnlivý počet postav pro
daného hráče. Což zatím mé znalosti neumožňují implementovat
V Jsonu to z mého pohledu vypadá daleko přehledněji vše v jednom objektu tak jak se s tím pracuje v aplikaci.
Erik Šťastný:16.5.2017 9:35
Nic konkrétního nejspíše ani nemám, tohle je to z čeho momentálně vycházím:
zde JSON podoba:
{
"name": "",
"account_level": 0,
"character_1": {
"name": "",
"strength": 10,
"vitality": 10,
"spell_1": {
"dmg": 5
},
"spell_2": {
"dmg": 10
},
"spell_3": {
"dmg": 15
},
"spell_4": {
"dmg": 20
},
"spell_5": {
"dmg": 25
}
},
"character_2": {...A v příloze SQL podoba.
Michal Štěpánek:16.5.2017 10:13
Ty "návrhy komplexnější databáze" trošku paradoxně většinou nejsou
uvedeny u databází, ale spíše u konkrétních programovacích jazyků,
protože to bývá spojeno s programováním nějaké konkrétní aplikace a
tvorba DB pak závisí na potřebách "té" aplikace. Ta vazební tabulka se
dělá jen v případě vazby M:N, tzn., třeba u tvého případu jeden hráč
může mít více postav a zároveň jedna postava může figurovat u více
hráčů. Pokud by měl jeden hráč pouze jednu postavu, dal by se jen do
tabulky "hráči" cizí klíč - ID postavy...
Ale každému může vyhovovat jiný přístup a je na každém, aby si vybral
tu nejvhodnější variantu pro svou aplikaci... 
Erik Šťastný:16.5.2017 10:23
No asi jsem přesvědčen o tom, že MySQL tabulka dokáže být krásně
přehledná, ale to bych se to musel prvně naučit.
Hlavně vůbec nechápu všechny ty druhy klíčů o kterých mluvíš nebo spíše jejich použití v praxi.
A jak říkal Jiří Sedláček mám právě daleko větší obavu, že tu SQL databázi navrhnu úplně hrozně, že když se na to někdo používá tak se zděsí, a bude to nemožné zpravit jinak než celé zahodit.
Erik Šťastný:16.5.2017 10:30
Jo vlastně pole, má fixní pozice, takže to nemusím IDčkovat ano správně.
Možná to z mých komentářů nebylo úplně zjevné, ale jsem spíše
zastánce sql přístupu. Nicméně rozhodnutí je na Tobě
Erik Šťastný:17.5.2017 8:57
No jo, asi u ní i zůstanu tedy, nicméně už teď si myslím, že je ten
můj návrh špatný, jak jsem řekl jsem v tom úplný nováček. Když se nad
tím později zamyslím a vytvořím nějaký návrh pomohl by jsi mi říct co
je špatně nebo dobře?
Zobrazeno 24 zpráv z 24.