Diskuze: Ukládání kreditu
V předchozím kvízu, Online test znalostí PHP, jsme si ověřili nabyté zkušenosti z kurzu.
Zobrazeno 12 zpráv z 12.
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.
Rozhodně chceš mít uložené transakce a z nich počítat stav konta. Už
jenom proto, že uživatele pravděpodobně bude zajímat, proč a kdy mu
zmizel/přibyl kredit. Navíc budeš mít případně možnost pohodlně řešit
storno a refundace.
// Dost pravděpodobně chceš tabulku transakcí všech uživatelů, ne jen
jednoho uživatele.
Díky. A to vypočítávání bys dělal automaticky jako trigger při každém vložení záznamu do tabulky, a ukládal konečný stav creditu do vlastního políčka, nebo udržoval sloupec trvale dynamický třeba v pohledu, nebo to počítat až přímo pro potřebu scriptu?
Za předpokladu, že ten stav kreditu bude hodně dynamický
Nejdřív bych to udělal jednoduše bez triggeru. Pokud bys měl hodně čtení a výrazně tě to zpomalovalo, pak bych zauvažoval nad přidáním indexu nebo triggeru. Ale nejsem žádněj velikej databázista.
Viděl bych lepší držet u uživatele i aktuální stav kreditu. Tedy
nepočítat to pokaždé dynamicky. Až bude mít hromadu transakcí, bude to
zbytečně zdržovat.
Prostě po každé transakci (plus, minus, storno, refund apod...) uložit
transakci do tabulky transakcí a zároveň spočítat uživateli aktuální
kredit a ten si držet u jeho id.
Když bude mít hodně úprav (což předpokládá), pak ho naopak bude přepočítávání při každé změně brzdit.
Jo, asi bude třeba rozhodnout , kde bude důležitější být rychlejší a kde naopak bude možná prodleva.
A co udělat tabulku , do které ukládat všechny transakce a pro potřebu aplikace vytvořit MySQL pohled, který bude mít třeba jen sloupec id a kredit - udržovaný pomocí aggregované funkce z té tabulky, a s tou hodnotou dále pracovat v aplikaci?
Bude to mít nějaký pozitivní význam? Potřebuji zajistit, aby aplikace neumožnovala akce v případě záporného kreditu, tech změn bude tak 20 za minutu pro jednoho uživatele.
Pohledem můžeš shovávat komplexnější kód, ale výkonnostně ti to nijak nepomůže.
A ještě malý dotaz, je lepší mít samostatné tabulky pro ruzné druhy operací dobití kreditu / odeslání kreditu, nebo jedna a věnovat tomu sloupec pro odlišení a operovat se znaménky?
Určitě bych to dal do jedné tabulky a ke každému záznamu přidával ID typu transakce. Jednak se ti s tím bude mnohem líp pracovat až budeš tvořit nějaký komplexnější dotaz a jednak kdybys chtěl s těma kreditama dělat něco dalšího (třeba mít ještě další stavy "čeká na připsání", "čeká na platbu" apod.) tak bys musel přidávat do databáze další tabulky a upravovat dotazy a to není moc systematické.
Zobrazeno 12 zpráv z 12.
