Тук има няколко въпроса/проблеми, така че ще се опитам да отговоря на всеки един.
Всички взаимодействия в турнира трябва да бъдат в реално време/отразени за много потребители.
За малък до среден трафик на вашия уебсайт това може да не е проблем. За по-натоварения трафик това бързо ще започне да бъде основен проблем.
Помислете за пример колко често искате да анкетирате базата данни с вашите AJAX повиквания. Всяка секунда? Така че, ако имате 100 души с отворена страница, имате 100 обаждания към базата данни всяка секунда? Ще откриете, че това бързо ще убие вашата база данни.
Въпреки че това е малко извън темата, силно бих препоръчал да проучите как да кеширате резултатите от турнира преди време. Можете да кеширате статистическите данни и т.н. и или да ги оставите да изтекат, или да изтекат проактивно, но определено отделете известно време в проучването им.
Статистика/резултати в реално време
Имайте предвид, че присъединяването отнема време в релационни бази данни. Ако нормализирате силно турнирната си структура, получаването на статистика може да е болезнено. Най-трудната част от системата, която да бъде ефективна, ще бъдат агрегатите и статистическите данни от всеки турнир.
Когато проектирате своята база данни/таблици/изгледи/съхранени процедури, имайте предвид крайната цел – бързо получаване на статистика. Това може да означава не нормализиране на данните твърде много (за да се избегнат твърде много обединения). Това може също да означава да обръщате много внимание на вашите типове данни - например използване на bits/shorts/etc. вместо цели числа.
Как да моделирам различните типове турнири
Не съм запознат с турнирните модели, но имам конкретни съвети как да моделирам. =)
Някои въпроси, които трябва да си зададете:
-
Всички турнири имат ли общи полета? С други думи, за кръгов турнир съхраняваме 10 полета. За един елиминационен турнир съхраняваме 11 полета. Ако споделят едни и същи 10 полета, тогава бих препоръчал да поставите всички типове турнири в една таблица и след това да използвате поле tournament_type, за да определите типа на турнира за вашето приложение.
-
Всички турнири нямат ли общи полета? Направете ги отделни маси - по една за тип турнир. Може да направите една таблица за споделени данни, но след това да имате различни таблици за конкретна информация.
-
Ще се разделят ли турнирните полета с течение на времето ? С течение на времето ще искате да добавите полета към видовете турнири. Ако прогнозирате, че турнирите ще станат много уникални и много специфични с течение на времето, направете ги отделни. В противен случай ще се окажете с много полета, които имат тонове NULL стойности в тях.
-
Обмисляли ли сте решение за NoSQL ? Хубавото на NoSQL магазина е, че той денормализира данните, така че да нямате присъединявания. Също така можете да имате хетерогенни (различни типове данни) в една и съща "таблица" или контейнер. Просто нещо, което трябва да имате предвид, защото може да направи живота ви значително по-лесен. Вижте MongoDB като пример.
