Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: Thugmek 01. 06. 2017, 17:33:28
-
Dobrý den, víte někdo jak MySQL vyhledává v databázi? Dělám takovou hříčku, něco jako Travian (pravděpodobně to nikdy nikdo nebude hrát) a potřebuju tabulku hráčských vesnic, kde bude vlastník, poloha a pak velkej XML soubor obsahující všechny informace o vesnici (suroviny, budovy, jednotky...). Jak moc bude ten XML soubor databázi zpomalovat když budu například vykreslovat mapu (načte se všechno kromě toho XML)?
-
Pokud bude dlouhý, měl by být uložený mimo takže při selektu bez XML by to mělo být jedno.
Do nějaké velikosti domnívám se do 64kB se vkládá rovnou mezi data v tabulce.
V případě nouze si myslím, že i v produkci není problém to odhodit do jiné tabulky.
Dobrý den, víte někdo jak MySQL vyhledává v databázi? Dělám takovou hříčku, něco jako Travian (pravděpodobně to nikdy nikdo nebude hrát) a potřebuju tabulku hráčských vesnic, kde bude vlastník, poloha a pak velkej XML soubor obsahující všechny informace o vesnici (suroviny, budovy, jednotky...). Jak moc bude ten XML soubor databázi zpomalovat když budu například vykreslovat mapu (načte se všechno kromě toho XML)?
-
Neni lepsi mit ty XML soubory na disku a v DB sloupecku mit jen cestu k souboru?
-
Pokud už musíš mít ty data v XML, dal bych ho do separátní tabulky, vzhledem k tomu, že ho nepotřebuješ číst pořád.
Ale vážně bych se zamyslel nad tím, jestli by nebylo lepší ty data normalizovat a mít je jako regulérní tabulku..
-
Pokud už musíš mít ty data v XML, dal bych ho do separátní tabulky, vzhledem k tomu, že ho nepotřebuješ číst pořád.
Ale vážně bych se zamyslel nad tím, jestli by nebylo lepší ty data normalizovat a mít je jako regulérní tabulku..
Ak experimentuje, tak možno nemá dopredu vymyslenú pevnú štruktúru dát pre "vesnici". Alebo si netrúfa so svojou znalosťou SQL nasypať tam všetko. Podľa mňa je oboje v poriadku.
Čo by som zvážil, je vykašľať sa na XML (ak nechce robiť XSLT transformácie) a držať to ako JSON. Je kompaktnejší a parsuje sa rýchlejšie. Na webe je tiež možné ho poslať AJAXom do prehliadača, kde sa absolútne jednoducho stane objektom Javascriptu a dá sa s ním ďalej pracovať.
-
a proč to musí být xml soubor?
-
pardon, mezitim přišly odpovědi....
JSON je lepší, ale proč nemít ta data v separátní(ch) tabul(ce|kách)?
-
Kolik těch XMLek bude? Když to dáš jako typ text/mediumtext, v rozumných počtech řádků to mysql zvládne úplně v pohodě. Samozřejmě předpokládám správné indexy a že v tom nebudeš hledat přes like.
Na všechny tvé tabulky engine innodb s nastavením innodb_file_per_table.
-
XML je obvykle lépe na disku v podobě souboru. Kombinace XML s databází nebývá příliš výhodná.
-
XML je obvykle lépe na disku v podobě souboru. Kombinace XML s databází nebývá příliš výhodná.
Naopak, kombinace XML (nebo JSON) s databází je velmi výhodná, pokud daný db engine dokáže s XML/JSON pracovat. Můžeš si nad nimi dělat ad hoc dotazy a dokonce i indexy. Bohužel nevím jak je na tom zrovna MySQL, už přes deset let používám jen DB2 a Postgresql.
Disclaimer: Samozřejmě, neporovnávám XML/JSON s korektní normální formou, ta je vždy pro hledání lepší.
Kombinace souborů na disku s databází je naopak velmi nevýhodná, a to hned z několika důvodů:
- Buď může existovat jen jeden klient (který má u sebe ty soubory), nebo musí všichni klienti sdílet nějaký filesystém. Ne že by to nešlo, s takovým NFS si člověk užije spousty zábavy když vypadne spojení...
- Práce se soubory není součástí transakce. Je ošetřit všechny kombinace rollbacku a chyb FS, jinak se bude stávat že chybí soubor odkazovaný z db, nebo naopak na fs nějaký přebývá. O současné změně obsahu souboru ani nemluvě.
- Pokud už někdy chceš hledat uvnitř (v podstatě nutné při ručním řešení problémů), tak musíš ručně spojovat nějaký grep/xmlstarlet/jq a SQL dotaz.
Samozřejmě, pokud se jedná o významné objemy dat, tak se nedá nic dělat a všechny výše uvedené problémy řešit. A samozřejmě, někdo má rád výzvy :-)
-
V původním dotazu není o vyhledávání v tom XML nic, IMO to chce jen ukládat a pak vytahovat.
-
V původním dotazu není o vyhledávání v tom XML nic, IMO to chce jen ukládat a pak vytahovat.
Jo, to si možná myslí teď, ale podle toho co do nich chce ukládat (cituji: suroviny, budoviny, jednotky) je mi jasné že hned druhý den bude potřebovat najít kolik má prázdných vesnic apod.
-
V původním dotazu není o vyhledávání v tom XML nic, IMO to chce jen ukládat a pak vytahovat.
Jo, to si možná myslí teď, ale podle toho co do nich chce ukládat (cituji: suroviny, budoviny, jednotky) je mi jasné že hned druhý den bude potřebovat najít kolik má prázdných vesnic apod.
suroviny, budoviny, jednotky... Zřejmě do toho bude chtít během hry i zapisovat změny, což je další argument proti použití XML. Tohle vypadá spíš na klasické použití normalizované databáze SQL, tedy bez XML.
Pokud by to měla být NoSQL databáze, tak asi Redis, protože nabízí i kolekce, které by zde mohly najít uplatnění. Při troše šikovnosti by ani nemusely chybět transakce.
-
zatim je to v poho, protoze po nas nechce vymyslet kompletni reseni
-
MySQL má datový typ blob, jeho obsah je uložený mimo zbytek řádku jako soubor a jeho přítomnost nemá vliv na zbytek práce s řádkem.
Obecně ale takovéhle ulehčení není vhodné, narazíš s tím, když budeš chtít třeba dělat statistiku nebo celkový přehled několika údajů, bude to náročné. Velice problematické to je v případě, kdy časem budeš měnit/rozšiřovat strukturu těhle dat, doménová logika pak bude obsahovat zbytečně hodně ifů nebo musíš jednorázově transformovat všechny tyhle xml.
Raději to uloži do databáze ve formě key, value.
-
Raději to uloži do databáze ve formě key, value.
No, a tady bacha: EAV je právem považováno za antipattern, a právem. Dnes už je opravdu lepší použít XML nebo JSON, pokud mají nativní podporu (vlastně EAV byl jeden důvod proč se přidávala). Když relační databáze, tak pokud možno nějaká rozumná normální forma (tj. sloupečky).
-
Pokud netrvas na SQL. Tak zkus eXistdb http://exist-db.org/exist/apps/homepage/index.html.
Je to noSQL database z doby kdy jeste noSQL nebylo kuuul a lide verili, ze kazdy problem se vyresi pomoci XML.
Je to vlastne takove Mongo, akorat misto JSON je tu XML a misto javascriptu je tu JAVA/XPATH
-
PS: jestli chces pouzit relacni db a XML tak pouzij PostreSQL (popr. Oracle XE) ty maji podporu pro XQUERY. MySQL si jde vlastni cestou.
-
PS: jestli chces pouzit relacni db a XML tak pouzij PostreSQL (popr. Oracle XE) ty maji podporu pro XQUERY. MySQL si jde vlastni cestou.
Rozhodně, Postgresql je jedna z nejlepších nosql databází :-)
PS: nosql = not only sql :-)
-
Raději to uloži do databáze ve formě key, value.
No, a tady bacha: EAV je právem považováno za antipattern, a právem. Dnes už je opravdu lepší použít XML nebo JSON, pokud mají nativní podporu (vlastně EAV byl jeden důvod proč se přidávala). Když relační databáze, tak pokud možno nějaká rozumná normální forma (tj. sloupečky).
EAV je o dvě míle dál než jsem měl na mysli :). Použití nativních struktur v XML/JSON bude antipattern za pět let, to si člověk moc nepomůže.
Akademická diskuze tady asi nemá smysl, nějaká normalizace dat v relačních databázím klukům asi moc neřiká. Ukládat celou strukturu v jednom atributu vypadá lákavě, ale chtěl bych upozornit na dost pastí, které se v budoucnu mohou vymstít (upgrade/downgrade, transformace, konzistence, integrita, backup/restore, transakce atd.).
Normalizovat data do tabulky je pro podobnou hru nejlepší, nosql může sloužit jako cache nebo píseček na hraní, data budou ale pod kontrolou v db.
-
Ach jo ... pokud si chce nekdo hrat, potud OK. Jinak je XML/JSON v DB totalni zhovadilost. Proc? Protoze efektivita.
Asi jsem uz prilis stary a muj pohled kde porad pocitam kazdy tik CPU a kazdy bajt se prilis nenosi. Holt je asi dneska v mode porad CPU trapit zbytecnym parsovanim XML sem a tam .. ;-)
-
Ach jo ... pokud si chce nekdo hrat, potud OK. Jinak je XML/JSON v DB totalni zhovadilost. Proc? Protoze efektivita.
Asi jsem uz prilis stary a muj pohled kde porad pocitam kazdy tik CPU a kazdy bajt se prilis nenosi. Holt je asi dneska v mode porad CPU trapit zbytecnym parsovanim XML sem a tam .. ;-)
Obvykle máme zato, že XML/JSON nesplňuje ani 1NF. Existuje však několik případů kdy je ukládání těchto formátů výhodné a splňuje i 3NF. Nejspíš to nebude uvedený příklad a proto nelze ukládání XML/JSON do databáze obecně doporučit.