Zadejte hledaný výraz...

Navrh SQL schemy

alahucky
verified
rating uzivatele
(2 hodnocení)
16. 11. 2019 17:33:43
Zdravim, mam dve moznosti ako ukladat data do MySQL a neviem sa rozhodnut ktora je spravnejsia:
Možnost 1:
vs.
Možnost 2: Metriky v jednotlivych tabulkach .. cca. 10 tabuliek typu Language, Browser etc. a mapovanie vo Visit tabulke do stlpcov:
Prva možnosť je náročnejšia z hľadiska insertov, cca. 10 insertov do VisitMetric pre kazde vlozenie zaznamu do Visit. Druhá je viac duplictného kódu kedže sa všetky Language, Browser,Country chovajú rovnako, majú rovnaké stĺpce.
16. 11. 2019 17:33:43
https://webtrh.cz/diskuse/navrh-sql-schemy-2/#reply1424101
TomasX
verified
rating uzivatele
(4 hodnocení)
16. 11. 2019 18:27:02
jednoznačně první, splňuje 3. normální formu a takhle se to má dělat.
V druhém případě jakékoliv přidávání dalších metrik způsobí nutnost přidat další tabulky. Nevhodně fragmentuješ data na db
16. 11. 2019 18:27:02
https://webtrh.cz/diskuse/navrh-sql-schemy-2/#reply1424100
alahucky
verified
rating uzivatele
(2 hodnocení)
16. 11. 2019 19:27:34
Diky. System doteraz fungoval ako moznost 2 s len jednou metrikou. Pridavam teraz nove preto ma napadlo to riesit inak, moznost 1 vyzera sexi ale uz teraz su operacie nad tabulkou Visit pomale - bezne treba 200,000 novych riadkov kazdy den, moznost jedna v podstate prida k tomu dalsich 2,000,000 riadkov kazdy den do tabulky VisitMetric a mam obavu ze to bude este pomalsie.. v peakoch sa robi aj 10 insertov do tabulky za sekundu .. to bude zrazu 10x viac.. sice obidenim ORM sa to da spravit 1 insertom a jednym multiinsertom.
Aj ked zohladnis tento performance problem by si isiel do moznosti 1?
Je k tomu aj nejaka teoria preco moznost 1?
16. 11. 2019 19:27:34
https://webtrh.cz/diskuse/navrh-sql-schemy-2/#reply1424099
node
verified
rating uzivatele
(5 hodnocení)
16. 11. 2019 20:27:59
preco to nedas do jednej tabulky? aku ma logiku mat tabulky s jednym stlpcom a linkovat nan v inej tabulke?
16. 11. 2019 20:27:59
https://webtrh.cz/diskuse/navrh-sql-schemy-2/#reply1424098
alahucky
verified
rating uzivatele
(2 hodnocení)
16. 11. 2019 20:33:12
Tabulka Visit ma viac stlpcov, len som ich nenapisal sorry .. napr. url, datum, cas atd.
Ci si myslel inu?
16. 11. 2019 20:33:12
https://webtrh.cz/diskuse/navrh-sql-schemy-2/#reply1424097
TomasX
verified
rating uzivatele
(4 hodnocení)
17. 11. 2019 12:06:43
pokud jde o rychlost, neumím moc poradit. Problém to být nemusí, ale také to může být fatální, neznám typ, verzi a konfiguraci db. Např. Mariadb 10.2 nasazujeme i při 20 000 insertů / s na jediném stroji, ta technologie to umí zvládnout, nelze ale říct, že každá instance s libovolným nastavení to zvládne.
Sám musíš vědět jak je tvůj systém dimenzovaný a kolik toho zvládá, podle toho případně přejít na 4. normální formu jako způsob optimalizace (plochá tabulky a duplicitami bez referenčních struktur), to ale musí vycházet z měření s vědomím jeho nevýhod.
Můžeš použít i kombinaci, prvotní záznam uvedeš do jedné tabulky jako spousty sloupců (běžně se tomuhle říká staging) a až na pozadí asynchronně (třeba každou minutu) tyhle záznamy převedeš do normalizované formy, s kterou se zase lépe pracuje. Stejně tak to je s reportingem, je zbytečně každý reporting počítat online z RAW dat, můžeš mít předpočítané hodnoty pro hodiny, dny, měsíce a s tím pak pracovat v administraci.
10 insertů / s (multiinsert je samozřejmě vždy lepší) by ale neměl být problém snad pro žádný hosting (výjma wedosu, tam i tohle je problém). Počet indexů drž nízko, nepoužívej přílož dlouhé datové typy (aka varchar(255)), ale vždy co nejpřesnější a ideálně numerické. Stejně tak nemusíš nechávat RAW data neomezenou dobu, ale třeba jen pro poslední rok a zbytek držet jinde či už jen předpočítaně na větší celky, záleží jaké jsou tvoje potřeby a jak s těmito údaji zacházíš. Retence či offloading na pomalejší (levnější) databázi lze poměrně jednoduše.
17. 11. 2019 12:06:43
https://webtrh.cz/diskuse/navrh-sql-schemy-2/#reply1424096
Pro odpověď se přihlašte.
Přihlásit