Databázový návrh, řešení?

Pokud chceš podporovat i sporty jako je třeba biatlon, tak ani home a away nebude stačit. V některých sportech není počet částí pevně daný (tenis může skončit dříve, golf se může protáhnout). Někdy je cílem maximalizovat skóre (desetiboj), jindy minimalizovat (běh). Někdy je pořadí dáno sekvencí výsledků parametrů (šachy). Zmiňuješ hokej, který může mít prodloužení a nájezdy.

Pokud přijmeš nějaká omezení, nevidím na tom schématu nic špatného.

Nabídnu univerzální řešení - události. Kdykoli někdo skóruje gól nebo doběhne, vytvoříš událost:


Pak je vyhodnocení počtu gólů za třetiny a celkově otázkou aplikační logiky, která bude odlišná pro fotbal a hokej. Otázkou je, jestli máš informace s takovou granularitou.

To, co navrhuje juriad se mi líbí. Pokud máš k dispozici údaje, kdy do skóroval, dají se z nich dělat zajímavé statistiky (v posledních 5 minutách padá 20 % gólů). K času uložit i číslo poločasu / třetiny, ve které se to stalo. U zápasu pak uložit, kolik měl "poločasů".

Případně by se dala udělat i struktura matches(id), parts(match_id, order, duration), points(part_id, player_id, time). Je to hodně variabilní, ukládá to i informaci, kolik částí zápas měl, že se hrály tři prodloužení.

Moc se mi nelíbí ukládání home_* a away_*, ale vnímám to spíš jako osobní preferenci. Zdá se mi, že ve výsledku jsou složitější dotazy. Alternativa je uložit informaci to sloupce (enum 'home', 'away'). Uvažuju třeba dotazy "kolik gólů dal tým", "kolik gólů dal tým doma", "kolik gólů dal tým venku". Při první reprezentaci je potřeba měnit vybírané sloupce v dotazu, při druhé se mění je podmínka ve where. Zdá se mi, že musíš ve spoustě dotazů sčítat home+away, duplikovat části pro home / away. Myslím, že jsem to tak na jednom projektu tak začal a pak přešel k té druhé variantě, která tam je doteď, a jsem spokojený. Každopádně je jednoduché udělat jedno jako tabulku a druhé jako view, pokud těch záznamů není opravdu hodně, rychlé to bude obojí podobně.

Podobně bych chtěl mít rozlišené dotazy "kolik gólů dal tým", "kolik gólů dal tým v prvním poločase", "kolik gólů dal tým v druhém poločase" jen jednoduchou podmínkou ve where. Celkový výsledek bych uložil jen pokud by to bylo potřeba kvůli rychlosti nebo faktu, že informace, kdy góly padly chybí.

Kcko:
„To co ty ukazuješ v závěru je hezké, ale to je spíš statistika pro daného hráče ne pro tým jako celek.“
Dotazy pro hráče a pro tým by taky měly ideálně vypadat skoro stejně, lišit je jedním joinem nebo podmínkou ve where.

Ten nápad s událostmi toto dovoluje - každou událost, kterou mám k dispozici - začátek zápasu, vstřelený gól, faul, prodloužení jde popsat. Nejspíš to nebude ve formátu, se kterým by bylo snadné pracovat - všechny operace vedou na nějaké agregace. Ale můžeme vedle této fronty událostí postavit jinou strukturu, která je vhodná pro dotazování - a tu automaticky plnit například pomocí triggerů nebo periodicky nějakým procesem. Tato technika se nazývá Event sourcing a CQRS a má mnoho výhod:
* primární data zůstávají na věky dostupná a nezměněná
* struktura sekundárních dat se může měnit - lze je přegenerovat z primárních dat
* lze poměrně jednoduše přidat další vypočítanou statistiku
* aplikaci lze škálovat - mít víc procesů, které zapisují do fronty, víc procesů, které odvozují statistiky z nových událostí ve frontě, víc procesů, které zodpovídají dotazy od uživatele
Ale pak už opouštíme klasické hostingy a přesouváme se do cloudu.

Nebál bych se případné změny schématu později - není to zas tolik práce. Důležitější je nepřijít o data. Primárně bych se snažil uložit všechna data, která jsou k dispozici, byť teď pro ně není využití.
Můžeš začít s tím, co máš. Statistiky můžeš řešit třeba pomocí materializovaných pohledů, pokud zjistíš, že selecty jsou pomalé - předpokládám, že statistiky se nemusí refreshovat příliš často. Případně si je budeš ukládat bokem a přepočítávat při každém zápisu - předpokládám, že zápasy nekončí každou sekundu. A možná časem doiteruješ k něčemu obecnějšímu.