Diskuze: Návrh databáze
V předchozím kvízu, Online test znalostí PHP, jsme si ověřili nabyté zkušenosti z kurzu.
Zobrazeno 14 zpráv z 14.
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.
Důvod také proč píšu je ten, abych to měl kvalitně navrhnuté a nemusel to pak zbytečně předělávat, protože daná varianta je nevýkonná.
Zásada je, že každá tabulka by se v podstatě měla starat o jednu věc. Tabulka uživatelů se "stará" o užvatele, tabulka článků o články, tabulka komentářů o komentáře atd. Tyto tabulky se "propojují" buď cizími klíči (třeba v tabulce články je jako cizí klíč ID autora, v tabulce komentáře je taky ID autora a ještě k tomu ID článku, atd.), nebo další, tzv. "vazební" tabulkou v případě, že chceš mít vztah M:M (například třeba v případě přiřazování rolí uživatele - jeden uživatel může mít více rolí a zároveň jedna role má více uživatelů)...
Ok, díky.
Jak ale řešit chat? Tam nevím jak popsaný princip použít.
Chat jsem sice nikdy neřešil, ale asi bych spáchal tabulku, kde by bylo ID
záznamu, ID odesílatele, ID příjemce, Datum, Text, přičemž ID záznamu by
byl auto_increment, ID odesílatele a ID příjemce by byly cizí klíče z
tabulky Users a zobrazování bych řešil dotazem, kde by byla podmínka že ID
odesílatele nebo ID příjemce se rovná ID přihlášeného uživatele...
Pak už stačí nějak pořešit automatický refresh při přijetí nové
zprávy...
Je toto řešení dosti výkonné? Já se bojím, že když tak bude příliš mnoho záznamů, tak to může být dost pomalé, zas na druhou stranu nevím jak jinak by se to dalo vyřešit.
Chat asi není třeba nějak dlouho archivovat, lze ho průběžně odmazávat. Co si představuješ pod pojmem "příliš mnoho záznamů"?
Teoreticky to můžu časem i promazávat, ale řekněme že bych to
nedělal.
Dejme tomu, že by bylo 1000 uživatelů a kdyby každý napsal třeba 1000
zpráv, tak to už je docela dost záznamů.
Pak už je jen třeba zvolit tu správnou databázi. Nedělám v PHP, takže nevím, co všechno zvládne MySQL, ale MSSQL toto musí zvládnout v pohodě. Otázkou spíš je, jestli je skutečně k něčemu potřebné takové množství dat uchovávat. Pokud skutečně ano, pak bych ještě přidal tabulku "archiv" a tam bych přesunoval starší záznamy, protože v "ostrých" datech k aktivní komunikaci je takové množství dat zbytečné, zobrazovat budeš stejně jen posledních cca 10 záznamů v chatu obou uživatelů...
a co takto automaticky priebezne stare zaznamy premazavat?
napriklad v urcity cas, alebo ked uzivatel odosle spravu?
Zobrazeno 14 zpráv z 14.
