Vydělávej až 160.000 Kč měsíčně! Akreditované rekvalifikační kurzy s garancí práce od 0 Kč. Více informací.
Hledáme nové posily do ITnetwork týmu. Podívej se na volné pozice a přidej se do nejagilnější firmy na trhu - Více informací.

Diskuze: Doporučení No-SQL object databáze pro použítí v .NETu?

Aktivity
Avatar
Erik Šťastný:15.5.2017 13:02

Zdravím, vytvářím serverovou aplikaci a rád bych už přešel do další fáze a začal pracovat s daty. Databáze jsou pro mě zatím velká neznámá nicméně se mi moc nelíbí koncept tabulek zvláště pro můj druh aplikace kde prakticky jeden objekt má haldy vlastností s proměnou délkou.

Máte někdo prosím nějaké doporučení pro objektovou databázi client-server, která má dobré propojení s .NETem?

 
Odpovědět
15.5.2017 13:02
Avatar
Odpovídá na Erik Šťastný
Michal Štěpánek:15.5.2017 13:44

Zkus to trošku více rozvést, co třeba myslíš tím

jeden objekt má haldy vlastností s proměnou délkou.

?

Nahoru Odpovědět
15.5.2017 13:44
Nikdy neříkej nahlas, že to nejde. Vždycky se totiž najde blbec, který to neví a udělá to...
Avatar
Odpovídá na Michal Štěpánek
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 :)

 
Nahoru Odpovědět
15.5.2017 14:02
Avatar
Odpovídá na Michal Štěpánek
Erik Šťastný:15.5.2017 15:43

Zatím mě asi velmi zaujala tahle databáze https://cs.wikipedia.org/wiki/MongoDB

 
Nahoru Odpovědět
15.5.2017 15:43
Avatar
Jiří Sedláček:15.5.2017 17:10

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

 
Nahoru Odpovědět
15.5.2017 17:10
Avatar
Odpovídá na Jiří Sedláček
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.

Editováno 16.5.2017 7:51
 
Nahoru Odpovědět
16.5.2017 7:50
Avatar
Odpovídá na Erik Šťastný
Michal Štěpánek:16.5.2017 8:11

Trošku se mi zdá, že mícháš víc věcí dohromady. To, co se tobě zdá "krásné a přehledné", může jinému připadat jako chaos. Ale hlavně "nezasvěcenému člověku" je úplně jedno, jestli se data berou z jedné hromady, nebo jestli na pozadí hry se data tahají z tabulek. Ten, kdo bude hru hrát, chce vidět jak se ta hra dobře hraje a ne jak ten kašpárek na pozadí ta data získá, jakým způsobem se ukládají a načítají jednotlivé stavy apod.

Nahoru Odpovědět
16.5.2017 8:11
Nikdy neříkej nahlas, že to nejde. Vždycky se totiž najde blbec, který to neví a udělá to...
Avatar
Odpovídá na Michal Štěpánek
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 :-O

Editováno 16.5.2017 8:17
 
Nahoru Odpovědět
16.5.2017 8:17
Avatar
Odpovídá na Erik Šťastný
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 :)

 
Nahoru Odpovědět
16.5.2017 8:54
Avatar
Odpovídá na Jiří Sedláček
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.

 
Nahoru Odpovědět
16.5.2017 9:06
Avatar
Jiří Sedláček:16.5.2017 9:15

postni co máš. Mrknem na to.

 
Nahoru Odpovědět
16.5.2017 9:15
Avatar
Odpovídá na Jiří Sedláček
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.

 
Nahoru Odpovědět
16.5.2017 9:35
Avatar
Odpovídá na Erik Šťastný
Michal Štěpánek:16.5.2017 9:52

Mně osobně přijdou pohodlnější a přehlednější SQL tabulky (JSON jsem zatím nikdy nepotřeboval, tudíž ho neumím).
"Proměnlivým počtem postav" myslíš, že hráč může mít najednou při jedné hře přiřazeno více postav? V SQLku by byla tabulka hráči, tabulka postavy a "vazební" tabulka kde by bylo ID hráče a ID postavy a tím pádem bys mohl hráči přiřadit kolik postav chceš, resp.kolik jich je v té tabulce "postavy"...
Netuším, jak funguje JSON a jak to tam je s případným přidáváním či odebíráním dalších vlastností či jiných požadavků na rozšíření, ale u SQL je to (alespoň pro mě) naprosto jednoduché...

Editováno 16.5.2017 9:54
Nahoru Odpovědět
16.5.2017 9:52
Nikdy neříkej nahlas, že to nejde. Vždycky se totiž najde blbec, který to neví a udělá to...
Avatar
Odpovídá na Michal Štěpánek
Erik Šťastný:16.5.2017 10:05

Netuším jak funguje vnitřně např ta MongoDB, který ten JSON formát používá, ale standardně si prostě ubereš nebo odebereš parametr jak potřebuješ a uložíš znovu.

Hmm to zní zajímavě, v tomhle je ten problém, že jsem vůbec nevěděl, že se ty vazby např dělají další tabulkou, proto narážím na to, že pro člověka kdo s tím neumí to moc snadnější a pohodlnější není. Zvlášť když jsem na to nenašel nějaké hezké návody. Všude včetně IT networku jsou detailní návody, na instalaci, vytvoření tabulek, selecty, inserty atp. Ale nějaké tutoriály jak na návrhy komplexnější databáze s nějakými příklady jsem bohužel nenašel.

 
Nahoru Odpovědět
16.5.2017 10:05
Avatar
Odpovídá na Erik Šťastný
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... 8-)

Nahoru Odpovědět
16.5.2017 10:13
Nikdy neříkej nahlas, že to nejde. Vždycky se totiž najde blbec, který to neví a udělá to...
Avatar
Odpovídá na Michal Štěpánek
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.

 
Nahoru Odpovědět
16.5.2017 10:23
Avatar
Jiří Sedláček:16.5.2017 10:29

json třeba takhle?
https://www.itnetwork.cz/dev-lighter/930

 
Nahoru Odpovědět
16.5.2017 10:29
Avatar
Odpovídá na Jiří Sedláček
Erik Šťastný:16.5.2017 10:30

Jo vlastně pole, má fixní pozice, takže to nemusím IDčkovat :) ano správně.

 
Nahoru Odpovědět
16.5.2017 10:30
Avatar
Jiří Sedláček:17.5.2017 8:53

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

 
Nahoru Odpovědět
17.5.2017 8:53
Avatar
Odpovídá na Jiří Sedláček
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? :)

 
Nahoru Odpovědět
17.5.2017 8:57
Avatar
Jiří Sedláček:17.5.2017 9:10

Ano, ale je třeba znát i nějaký koncept. Čeho chceš dosáhnout, jinak se nad tím nedá moc uvažovat

 
Nahoru Odpovědět
17.5.2017 9:10
Avatar
Odpovídá na Jiří Sedláček
Erik Šťastný:17.5.2017 9:11

No tak to je jasné, že k návrhu přidám i stručně pár vět co si od toho představuji.

 
Nahoru Odpovědět
17.5.2017 9:11
Avatar
Odpovídá na Erik Šťastný
Michal Štěpánek:17.5.2017 9:35

U návrhu DB je potřeba postupovat "odzadu". Musíš vědět, jaká data chceš, aby ti program vyplivnul a podle toho pak určíš, jaká data potřebuješ do programu nasypat. Tím pádem budeš pak vědět jaká data by měla DB obsahovat...

Nahoru Odpovědět
17.5.2017 9:35
Nikdy neříkej nahlas, že to nejde. Vždycky se totiž najde blbec, který to neví a udělá to...
Avatar
Odpovídá na Michal Štěpánek
Erik Šťastný:17.5.2017 9:42

V tom bych řekl, že mám celkem jasno.

 
Nahoru Odpovědět
17.5.2017 9:42
Děláme co je v našich silách, aby byly zdejší diskuze co nejkvalitnější. Proto do nich také mohou přispívat pouze registrovaní členové. Pro zapojení do diskuze se přihlas. Pokud ještě nemáš účet, zaregistruj se, je to zdarma.

Zobrazeno 24 zpráv z 24.