Diskuze: Průběh souboje - ukládání do databáze
V předchozím kvízu, Online test znalostí PHP, jsme si ověřili nabyté zkušenosti z kurzu.
Zobrazeno 19 zpráv z 69.
K personalizaci obsahu a reklam, poskytování funkcí sociálních médií a analýze naší návštěvnosti využíváme soubory cookie. Informace o tom, jak náš web používáte, sdílíme se svými partnery pro sociální média, inzerci a analýzy. Partneři tyto údaje mohou zkombinovat s dalšími informacemi, které jste jim poskytli nebo které získali v důsledku toho, že používáte jejich služby.
Používáme nezbytné cookies pro fungování webu a s tvým souhlasem také analytické a marketingové cookies.
Zajišťují základní funkce, bezpečnost a služby, které sis vyžádal. Nelze je vypnout.
| Služba | Poskytovatel | Účel | Cookies a úložiště | Doba uložení |
|---|---|---|---|---|
| ITnetwork | ITnetwork | Provoz webu, relace, přihlášení a uložení nastavení cookies. | PHPSESSID, auth_token, sid, itn_consent_impression, __Host-itn_consent | Relace až 1 rok |
| Google Tag Manager | Správa značek a načítání měřicích nástrojů webu. | Žádné | Neukládá se | |
| Google Fonts | Načítání typografie webu. | Úložiště řízené poskytovatelem | Dle podmínek poskytovatele | |
| Google Hosted Libraries | Načítání potřebných knihoven a stylů webu. | Úložiště řízené poskytovatelem | Dle podmínek poskytovatele | |
| Google reCAPTCHA | Ochrana formulářů a webu před zneužitím. | _GRECAPTCHA, rc::a, rc::b, rc::c, rc::f | Relace až 180 dní | |
| YouTube | Přehrávání vloženého video obsahu. | localStorage, IndexedDB; cookies after playback interaction | Relace až trvalé úložiště | |
| Vimeo | Vimeo | Přehrávání vloženého video obsahu. | __cf_bm, _cfuvid, vuid, localStorage, IndexedDB | Relace až 2 roky |
| Facebook Login | Meta | Přihlášení pomocí účtu třetí strany. | Úložiště řízené poskytovatelem | Relace až 1 rok |
| GoPay | GoPay | Zpracování uživatelem vyžádané platby. | Úložiště řízené poskytovatelem | Dle podmínek poskytovatele |
Pomáhají nám porozumět používání webu a zlepšovat ho.
| Služba | Poskytovatel | Účel | Cookies a úložiště | Doba uložení |
|---|---|---|---|---|
| Google Analytics 4 | Měření návštěvnosti a používání webu. | _ga, _ga_* | Až 2 roky | |
| Microsoft Clarity | Microsoft | Měření návštěvnosti a používání webu. | _clck, _clsk, _cltk | Relace až 1 rok |
Slouží k měření kampaní, personalizaci reklamy a marketingové komunikaci.
| Služba | Poskytovatel | Účel | Cookies a úložiště | Doba uložení |
|---|---|---|---|---|
| Google Ads | Měření kampaní, reklama a remarketing. | _gcl_au, _gcl_ls | Relace až 90 dní | |
| Meta Pixel | Meta | Měření kampaní, reklama a remarketing. | _fbp, _fbc, localStorage | Až 90 dní |
| Sklik | Seznam.cz | Měření kampaní, reklama a remarketing. | retargeting, sid, szn:* | Relace až trvalé úložiště |
| LinkedIn Insight | Měření kampaní, reklama a remarketing. | bcookie, li_gc, lidc, __cf_bm | Relace až 1 rok | |
| Ecomail | Ecomail.cz | Měření kampaní, reklama a remarketing. | ecmid, Úložiště řízené poskytovatelem | Dle podmínek poskytovatele |
| Atribuce kampaní ITnetwork | ITnetwork | Přiřazení návštěvy a objednávky ke kampani. | campaign_clid[*], user_session_context | Až 1 rok |
V předchozím kvízu, Online test znalostí PHP, jsme si ověřili nabyté zkušenosti z kurzu.
V databázích se dnes řeší třeba i takové záležitosti, jako jsou např. kolize a průniky polygonů, statistická analýza dat apod. Jen webaři dělají z SQL databází obyčejný KVS. Zabíjejí tak jejich schopnosti a výkon.
Porušení normální formy to je, když bude chtít přidat nějaký atribut k souboji, tak má problém. Teoreticky je všechno v pořádku, prakticky se někdy rozhodně něco změnit a bude mít velký problém. Tento způsob ukládání dat silně nedoporučuji.
Pokud kompletní zprávu ze souboje budu považovat za atomickou (jak tady všichni navrhujeme), tak to porušením 1NF není.
To je pravda, ale ona atomická není
Pokud je ten postup souboje důležitý, měl by se normálně
ukládat jako řádky, vybrat pár řádků podle klíče není nic hrozného.
Pokud se do db něco ukládá serializované, asi na těch datech moc
nezáleží, půjde je jen špatně editovat a je otázka zda jsou vůbec
potřeba. IMHO když se tohle dělá, tak je někde chyba v návrhu.
Jinak celá ta myšlenka ukládání postupu boje je dobré cvičení, ale prakticky nesmysl, jak tu již zaznělo. Ty informace jsou prakticky k ničemu.
Zas takový nesmysl to není, jestli to dobře chápu, tak se to k těm 100
kolům téměř nedostane, je možný že protivník umře třeba ve třetím,
občas, když to bude vyrovnané tak třeba v patnáctém (takhle to je běžně
u her, ale nevím k čemu těch 100 kol, to je zbytečně moc). Pokud by to bylo
kolem těch deseti kol, pak si to velká část hráčů bude chtít přečíst.
Už třeba jen proto, že se z toho dají zjistit principy hry, důležitost
různých atributů, nejvýhodnější jednotky, zbraně a tak dále 
Nebyla zde ani zmínka o editaci reportu ze souboje, o přidávání atributů také ne. Články do DB také nedáváš po odstavcích, ale ukládáš je vcelku.
Hmm, jak tak vidím, tak asi celé detaily ukládat nebudu. Maximálně dát možnost hráči, aby si zprávu uložil - to by se převedlo do JSON a uložilo do DB, v jiném případě by se to jen jednou vypsalo a pak by ve zprávě byly jen základní informace (vítěz, odměna, celkové způsobené poškození atp.).
Takhle by problém nebyl ani s tím, kdybych třeba přidal nový atribut. Uložená zpráva o souboji by byla jen kopií toho, co se stalo před updatem hry.
Výsledek by byl takový, že by se nehromadily zbytečně nepoužitelné
informace, ale zároveň by byla možnost se na ten výsledek podívat i
jindy.
Mně se tohle zdá jako docela rozumné řešení, co myslíte?
Pokud to bude realtime boj, tak se mu to ukáže z paměti. Tam to má nějaký smysl, člověk na to čeká atd. Pokud to není realtime, tak mi průběh nepřijde moc důležitý.
To je snad ještě horší než předtím. Proč budeš ukládat do DB zprávu v JSON, kde je kdo vyhrál? Zpráva je normální řádek, vítěz je normální sloupec.
Když budu chtít vědět, kdo vyhrál, podívám se na zprávu o souboji, která přijde vždy. Když si budu chtít uložit kopii detailů, bude mě zajímat pouze průběh souboje. V nejhorším případě se to dá poznat i z toho výpisu, kdo vyhrál (= ten, kdo dal poslední ránu).
Je vidět, že jsi tu jeho hru zatím nehrál. Už jsem ji zkoušel a vím o co v ní jde. Martin Konečný potřebuje jen vygenerovat zprávu ze souboje tak, aby si ji oba soupeři mohli kdykoli přečíst. Po přečtení ji zpravidla vymažou, ale někteří si ji budou chtít ponechat.
A to nějak odporuje tomu jak funguje řádek v databázi?
Zabiják na tebe vystřelil z kuše, ale minul. Udeřil jsi ho mečem, ale ochránila ho zlatá přilba. Zabiják na tebe zaútočil kopím, zasáhl tě a ubral ti 6 životů. Vystřelil jsi na něj z luku, ...
Už tušíš, o co tady jde?
Tohle ale není JSON
Pokud
tam chce mít tohle, tak je to ok. Předtím sjme se bavili o logu dat v
JSONu.
Třeba nechce úplně ztratit strukturu a chce si zachovat možnost další případné analýzy bez nunosti parsování. Tohle je jen text, který uvidí hráč.
Pokud ten tvůj text uložím do JSONu, bude to poměrně složité. Když potom rozšíří způsob boje, bude potřebovat změnit ten formát. Skončí to tak, že bude udržovat zpětnou kompatibilitu se starými logy nebo je bude parsovat a updatovat, obojí je nešikovné. Pokud si uloží řádky textového výstupu, tak proti tomu řešení nic nemám a je správné.
Pokud ty záznamy bude chtít poslat klientovi přes AJAX, tak se naopak JSON docela hodí. A pokud po najetí myší na "zlatou přilbu" bude chtít v bublině zobrazit její schopnosti, je nějaká struktura nutná. Ale až u klienta.
Parsování a updatování JSONu je velmi jednoduché v PHP i v JS.
Zobrazeno 19 zpráv z 69.
