Navrh SQL schemy

Zdravim, mam dve moznosti ako ukladat data do MySQL a neviem sa rozhodnut ktora je spravnejsia:
Možnost 1:

Kód:

Metric{
  Id
  MetricTypeId
  Code
}

MetricType{
  Id
}

Visit{
 Id
}
VisitMetric{
 VisitId
 MetricId
}

vs.
Možnost 2: Metriky v jednotlivych tabulkach .. cca. 10 tabuliek typu Language, Browser etc. a mapovanie vo Visit tabulke do stlpcov:

Kód:

Language{
  Id
  Code
}
Country{
  Id
  Code
}
Browser{
  Id
  Code
}

Visit{
  Id
  LanguageId
  CountryId
  BrowserId
}

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.

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

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?

preco to nedas do jednej tabulky? aku ma logiku mat tabulky s jednym stlpcom a linkovat nan v inej tabulke?

Tabulka Visit ma viac stlpcov, len som ich nenapisal sorry .. napr. url, datum, cas atd.
Ci si myslel inu?

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.