| | 9 | |
| | 10 | = Модел на пријателства (friendships) = |
| | 11 | Пријателството е моделирано како една релација помеѓу два корисници, при што секогаш се чуваат како '''user_id_low''' и '''user_id_high''' со услов првиот да е помал. Ова спречува дупликати како (A,B) и (B,A). Полето '''requested_by_user_id''' покажува кој ја испратил поканата, а '''status''' ја следи состојбата (pending, accepted, blocked). |
| | 12 | |
| | 13 | ---- |
| | 14 | |
| | 15 | = Модел на натпревари (matches, match_teams, match_participants) = |
| | 16 | Натпреварот е поделен на три дела: сам натпревар, тимови во натпреварот и играчи во тие тимови. Ова овозможува јасна структура: натпревар -> тимови -> играчи. Со надворешен клуч се осигурува дека играч може да припаѓа само на тим кој е дел од конкретниот натпревар. Овој пристап е флексибилен и поддржува различни типови игри. |
| | 17 | |
| | 18 | ---- |
| | 19 | |
| | 20 | = Преференци и нотификации = |
| | 21 | Преференците чуваат кои игри му се омилени на корисникот, а нотификациите можат да се поврзат со тие преференци. Така системот може да испраќа известувања поврзани со интересите на корисникот, на пример за нов турнир во омилена игра. |
| | 22 | |
| | 23 | ---- |
| | 24 | |
| | 25 | = Many-to-many релации (game_genres, game_developers) = |
| | 26 | Овие релации се решени со помошни (junction) табели со составен примарен клуч. Ова значи дека една игра може да има повеќе жанрови, а еден жанр може да припаѓа на повеќе игри. |
| | 27 | |
| | 28 | ---- |
| | 29 | |
| | 30 | = Членство во тим (team_memberships) = |
| | 31 | Членството е моделирано како посебна табела затоа што не е само врска, туку има дополнителни информации како улога (капетан, член, тренер) и статус. Така може да се следи кој корисник во кој тим е и каква улога има. |
| | 32 | |
| | 33 | ---- |
| | 34 | |
| | 35 | = Претплати и плаќања (subscriptions, payments) = |
| | 36 | Се чуваат информации за претплатите и нивните периоди, а плаќањата се поврзани со нив. Со посебен услов се осигурува дека еден корисник може да има само една активна претплата. |
| | 37 | |
| | 38 | ---- |
| | 39 | |
| | 40 | = Постигнувања (user_achievements) = |
| | 41 | Оваа табела покажува кои корисници кои постигнувања ги отклучиле и кога. Така може да се следи напредокот на корисниците и да се прават статистики. |
| | 42 | |
| | 43 | ---- |
| | 44 | |
| | 45 | = Сервери и локации = |
| | 46 | Локацијата е одделена во посебна табела, а серверите се поврзани со неа. Ова избегнува дуплирање на податоци и овозможува повеќе сервери да користат иста локација. |
| | 47 | |
| | 48 | ---- |
| | 49 | |
| | 50 | = Систем за статистики (stat_types, participant_stats) = |
| | 51 | Статистиките се моделирани на флексибилен начин преку две табели. Во '''stat_types''' се дефинираат типовите на статистики за секоја игра (на пример: kills, assists, deaths, headshots), додека во '''participant_stats''' се чуваат конкретните вредности за секој играч во одреден натпревар. Ова значи дека за еден играч во еден натпревар може да има повеќе записи – по еден за секој тип на статистика. |
| | 52 | |
| | 53 | Овој пристап е избран затоа што различни игри имаат различни метрики, па не е практично да се прават фиксни колони (на пример kills, assists, итн.) за сите игри. Наместо тоа, моделот овозможува лесно додавање нови типови статистики без промена на структурата на базата. Со тоа системот станува многу пофлексибилен и проширлив. |
| | 54 | |
| | 55 | Дополнително, овој дизајн е погоден за интеграција со надворешни сервиси, како на пример FACEIT API. Бидејќи FACEIT API враќа статистики во динамичен формат (различни игри, различни полиња), овие податоци можат директно да се мапираат во '''stat_types''' и '''participant_stats''' без потреба од промена на базата. Ова овозможува системот автоматски да увезува и чува реални статистики од натпревари, што ја зголемува точноста и функционалноста на апликацијата. |
