Está en la página 1de 4

Tablas customizadas de la DB de Simtennis.

Las tablas llevan el prefijo sim_ para diferenciarlas rapidamente de las basicas de joomla (jos_).

Este esquema es el primer modelo de datos planteado, no tuvo ningun test ni analisis postearior.
No está ordenado alfabeticamente a fin de ser mas faciles de ralacionar y entender su lógica en una
lectura directa.

sim_character:

Alacema los Charactes/Personajes con los que se puede jugar en el Juego (Ford,Arnold...etc)

id. (PK, unique, int)


name. (String) El nombre del personaje (Ford, Arnold, ...etc)
picture. (String) URL con imagen del personaje

Son los campos basicos como para trabajar, adicional se podrian agregar otros tantos como
descripcion, edad, nacionalidad, zurdo/diestro... Lo que sea que pueda ser interesante para mostrar
en el momento que el usuario elija o cambie su personaje.

sim_player:

Almacena informacion de los usuarios que juegan en SIM. Son los datos adicionales al concepto
basico de usuario que maneja Joomla para los fines particulares de la competicion en el sitio.

id. (PK, unique, int)


id_user (unique,int) PK de la tabla user propia de la DB de Joomla.
id_char (int) PK de la tabla de Characters/Personajes (sim_character).
rank (int) Puesto que ocupa en el Ranking, es un campo que se actualiza semana a semana, o
manualmente (de forma sincronica cuando se indique, pero no se actualiza al mismo tiempo que los
resultados de los partidos) con el objetivo de responder de la forma mas real posible al sistema del
ATP.
points (int) Puntos que acumula el Jugador en el ciclo actual, tecnicamente se podrian calcular en
tiempo real como el rank, pero calculandolo solo cada vez que corresponda reduce
significativamente la carga de la DB.
suspensionend (date) Día desde el cual el Jugador esta activo como tal, Se aplica como flag de
suspension tambien. Seguramente en un modelo posterior se implementara una tabla de
suspensiones para llevar control de los jugadores, pero de esta forma se soluciona rapidamente y no
necesariamente se va a descartar.

sim_type:

Almacena los diferentes tipos/clases de torneos.


El objetivo es hacer una agrupacíon logica por tipos de torneos, para facilitar su creacion, evitar
repeticion de datos y asimilar los diferentes “tipos de torneo” de las series que se juegan en el ATP
(Master1000, Master 500, GrandSlam...)

id. (PK,unique,int)
type (String) Nombre del tipo de Torneo (Master 1000, GS, Challenger...etc)
rounds (int) Cantidad de rondas que se juegan en el torneo (EJ: Cuartos, Semis, Final. Serían 3
rondas)
qualy (Bool) Flag que marca si para estos torneos se admiten o no partidos de Qualy.
playerlimit (int) Cantidad maxima de inscriptos para estos torneos. Se entiende que mediante el
campo rondas se puede calcular cuantos jugadores integran el cuadro principal, pero mediante este
campo se determina en que cantidad de jugadores se cortan las inscripciones.
counts_year (int) Cantidad de torneos de este tipo de cuentan en ciclo de Rank. Según la logica de
la ATP por cada año se toman en cuenta para el Rank solo los N mejores torneos de un tipo (EJ: los
4GS, 2 Master 1000, 4 Master 250... Hipoteticamente) Este campo indica el valor N para cada tipo.
mode (int o string) Identificacion relacional o simplemente un codigo para identificar el modo en
el que se realiza el torneo. Por ahora simplemente apuntamos a los torneos de eliminacion directa,
pero existiendo la posibilidad de que haya Round Robins u otros, la idea es poder mantener esta
tabla tambien.

Este es uno de los conceptos fundamentales y que puede ser mas conflictivo, cualquier cambio o
mejora impactaria directamente en todo el funcionamiento, por lo que lo ideal sería hacerlos lo
antes posible o “emparchar” mas tarde.

sim_tournament:

id. (PK,unique,int)
name (String) Nombre del Torneo (EJ: Buenos Aires Open, Rolland Garros, Australian Open...)
id_type (int) PK de sim_type, designa el tipo de torneo. (Ej: Australian Open, British Open, French
Open y US Open compartirian el id del type de GransSlam).
week (int) semana del calendario de ATP en la que se juega el torneo. Es la semana en la que se
empezará la competencia y con la que se calculan los vencimientos y validez anuales de los puntos.
county (String) Nombre del Pais en el que se juega el Torneo, en principio es simplemente el
nombre, no vi sentido en hacer una tabla con Paises. Si en algun momento pinta poner datos de los
paises, o alguna URL de las federaciones nacionales de tennis o de alguna comunidad, se podría
hacer, por ahora no le veo caso.
City (String) Nombre de la ciudad en la que se realiza el torneo. Valen las aclaraciones hechas para
'country' .
author (String) Nombre o Forma de itentificacion del Creador del torneo. Podría guardarse el id
de jomla del user, pero como no necesariamente el que “diseña” el circuito es el que lo guarda deje
un String.
enabled (Bool) Flag destinado a señalar si el torneo esta activo. No apunto a activarlo en cuanto a
que se este jugando, sino a si se va a usar. Por ejemplo, un torneo que se deje de jugar deberia estar
en enabled “0”, pero debe seguir registrado y contanto historicamente. Sin embargo, no se listara
dentro de los torneos a jugar en el calendario.
crationdate (date) Fecha en la que se agrego el torneo, solo a modo de registro, no pretende
guardar fechas desde la que se juegan torneos en la ATP, Si hoy se agrega el Abierto de Brasil que
se juega desde hace 30 años en el ATP, la fecha es la de hoy, no la de 1980.

sim_player_tournament:

Tabla usada para guardar las inscripciones de los jugadores a los torneos.

id_player. (int) PK de sim_jugador. El Id del jugador que se anota.


id_tournament. (int) PK de sim_tournament. Id del torneo al que se anota.
year. (int) Año de la lista de inscriptos para el torneo. Tendriamos una de estas listas por torneo que
se juega, una vez al año.
Seed (int) Numero de preclasificacion correspondiente al usuario incripto para este año en este
torneo.
La idea es que todos los jugadores que se anotan se van agregando, cuando termine el periodo de
inscripcion se ordena por rank y se asignan los seeds. El sorteo no se hace aca, sino sobre los
partidos.
El Torneo propiamente dicho esta formado por los partidos y estas listas.

sim_points_type:

Tabla que contiene los puntajes que se le aseguran a los participantes en cada ronda. La idea es que
la persona que NO gana en la ronda recibe ese puntaje. De esta manera se evita hacer excesos de
calculo para asignar puntos. Para hacerlo posible se considera que la ronda 0 existe y solo participa
el campeon del torneo, y no tiene ganador. Asi se pueden obtener los valores corespondientes en
una sola query.

id_type (int) PK de sim_type, el id del tipo de torneo del que se informan los puntajes de la ronda.
round (int) numero de ronda que tiene el valor de puntos de esta fila.
points (int) Puntos que recibe el No ganador de esta ronda, en este tipo de torneo.

Este concepto es central. Tiene como limitacio que, si se decide que por ejemplo, hay torneos del
tipo challenger que solo contabilizan 4 por año y a su vez queres que un challenger tengas
diferentes valores en rondas que otro, el modelo no puede solucionar ambos requerimientos.
Aunque, según el funcionamiento real del circuito esto no debería pasar.

sim_match:

El conjunto de todos los partidos para un id_tournament en un mismo year es lo que forma una
“instancia real” concreta del torneo. Las llaves y tada la info de el evento se arman desde esta tabla.

id. (PK,unique,int) Id de partido.


id_tournament. (int) PK de sim_tournament.
year (int) Año en el que se juega este partido para este torneo (sim_tournament).
round (int) Ronda a la cual corresponde este partido, de este torneo en el año year.
order (int) Posicion dentro de la llave para este partido. Pensando en una llave que se extiende en
froma horizontal, de izquiera (primeras rondas) a derecha (final). La ronda representaria el eje X, y
esta variable “order” el eje Y. Su funcion es permitir armar las llaves de forma de determinar los
cruces.
id_player1. (int)
id_player2. (int) Pks de la tabla sim_player. Los dos participantes del partido.
id_winner1. (int) id de sim_player declarado por el player1.
id_winner2. (int) id de sim_player declarado por el player2.
id_winner. (int) id de sim_player de quien resulto ganador. Es el valor que se toma como
verdadera sin importar los dos anteriores (resolver conflicto , o poner el resultado para resolver el
conflicto despues)
wo. (Bool) Flag que marca si el partido termino por WO.
doublewo (Bool) Flag que marca si se asigno un doble WO.
ret (Bool) Flag que marca si el final el partido de dio por un retiro.
Closed (Bool) Flag que determina si el partido ha finalizado definitivamente (sin conflictos en
ganador ni resultado).

La finalidad de estos Flags es hacer univoca la resolucion del partido.


Podrian reportar diferentes ganadores y se mantienen los resultados diferentes para seguir un
conflicto, pero se puede seguir con el torneo si un administrador/moderador decide respetar un
resultado sobre el otro.
Podria no haber ganador en caso de que sea la ronda Final, pero tampoco le corresponderia ningun
Flag de WO, ni Ret. Ya que eso haría que se aumente el procesamiento del partido para calcular el
record del jugador y que no cuente como derrota.
Se hizo una analisis de las distintas combinaciones y se llego a este modelo como “irredusible” con
un funcionamiento optimo, sin embargo se puede modificar.

sim_seed_order_type:

La funcion es determinar como se llena el cuadro. El administrador, o creador del “tipo de torneo“
definira de que manera se cubre el cuadro con los preclasificados, siendo el resto sorteados o
asignados a mano. La idea es que tambien se puedan asignar manualmente cada partido si se desea,
pero que se pueda sortear automaticamente para hacerlo transparente.

id_type. (int) PK de sim_type.


seed. (int) Preclasificado que ocupara el partido de este orden (explicado el concepto de orden en
sim_match).
order. (int) Obicacion del partido en la ronda correspondiente.

Despues de armar la primera ronda (o sortearla automaticamente) se sigue desplegando según el


orden y numero de ronda. EJ: Ganador de ronda 4, orden 1, juega contra Ganador de orden 2 en
ronda 4, en el partido de orden 1 de ronda 3. (Las rondas son superiores con el menor numero)

sim_set:

Almacena los resultados que declaran los jugadores luego de jugar un partido para cada set. La idea
es que puede haber hasta 2 resultados para un mismo set dado que los 2 jugadores pueden dar
resultados.

id. (PK,int,unique).
id_match. (int) PK de sim_match, para el que vale este resultado de set.
set. (int) Numero de set al que corresponde el resultado, no se supone que se guardan en orden (por
eso se guarda el numero de set) ademas puede permitir habrir conflictos sobre sets en particular.
Games1. (int)Cantidad de games obtenidos en este set para este partido por parte del jugador de
id_jugador_1 de la entrada correspondiente en el partido de id_match de la tabla sim_match.
Games2. (int) Cantidad de games obtenidos en este set para este partido por parte del jugador de
id_jugador_2 de la entrada correspondiente en el partido de id_match de la tabla sim_match.
id_submiter. (int) PK de la tabla sim_player del jugador que reporto este resultado.
date. (Date) Día en el que el jugador aporto este resultado.

sim_rank_year_week:

Almacena el historico de ranking por semana (o sus modificaciones, eso se vería) para cada
jugador. El objetivo es poder hacer calculos y comparaciones rapidamente respecto a sus posiciones
historicas, dado que hacer una query o un StoredProcedure que entregue estos datos o los calcule
causaria un overheat muy alto si se hiciera en tiempo real.

id_player. (int) PK de sim_player.


rank. (int) posicion que ocupaba en el rank en este momento.
Week. (int) Semana en la que se registro este puesto en el rank.
year. (int) Año en el que ocupó este puesto en esta semana.

También podría gustarte