sql - teams - ncaa scores
El mejor esquema para representar al NCAA Basketball Bracket (8)
Modelo propuesto
Diagrama de ER propuesto http://img257.imageshack.us/img257/1464/ncaaer.jpg
Mesa de equipo
Todo lo que necesitamos saber sobre un equipo es el nombre y la semilla. Por lo tanto, necesitamos una tabla de "Equipo" para almacenar el valor inicial. La única clave candidata es el nombre del equipo, por lo que la usaremos como principal para mantener las cosas simples. Es poco probable que los nombres de los equipos de la NCAA cambien en el transcurso de un solo torneo o contengan duplicados, por lo que debe ser una clave adecuada.
Mesa MatchUp
Se puede usar una tabla "MatchUp" para emparejar a los equipos en cada uno de los emparejamientos. Las claves foráneas (FK1, FK2) para el "Equipo" asegurarán que los equipos existan y una clave principal sobre estos valores asegura que los equipos solo se emparejen entre sí una vez.
Una clave foránea (FK4) en la tabla "Equipo" de la mesa "MatchUp" registrará al ganador. Lógicamente, el ganador debería ser uno de los dos equipos participantes en el partido. Una restricción de verificación contra la clave principal podría garantizar esto.
Una vez que se ha determinado el resultado de una partida, la semilla de Víctor podría recuperarse de la mesa del equipo para compararla con la de otros Víctor con el fin de determinar emparejamientos posteriores. Al hacerlo, se puede escribir un FK (FK3) en el emparejamiento resultante para determinar el progreso del torneo (aunque estos datos probablemente podrían derivarse en cualquier momento).
Mesa de juegos
También modelé los juegos de cada Match Up. Un juego se identifica por la coincidencia de la que forma parte y un número de secuencia basado en el orden en el que tuvo lugar durante el partido. Los juegos tienen un ganador de la mesa del equipo (FK2). La puntuación también se puede registrar en esta tabla.
¿Cuál es el mejor esquema de base de datos para representar un bracket de baloncesto masculino de la NCAA? Aquí hay un enlace si no está familiarizado: http://www.cbssports.com/collegebasketball/mayhem/brackets/viewable_men
Puedo ver varias formas diferentes de modelar estos datos, con una sola tabla, muchas tablas, columnas codificadas, formas algo dinámicas, etc. Necesita una manera de modelar tanto qué semilla y lugar ocupa cada equipo, junto con cada juego y el resultado (y posiblemente puntaje) de cada uno. También necesita una forma de representar quién juega quién en qué etapa del torneo.
En el espíritu de March Madness, pensé que sería una buena pregunta. Aquí hay algunas respuestas obvias, y el objetivo principal de esta pregunta es ver todas las diferentes formas en que puede responderlo. De la mejor manera, puede ser subjetivo al idioma que está usando o cómo está trabajando exactamente con él, pero trate de mantener las respuestas dn agnóstico, independiente del idioma y de un nivel bastante alto. Si alguien tiene alguna sugerencia sobre una mejor manera de expresar esta pregunta o una mejor manera de definirla, házmelo saber en los comentarios.
Como no especificó RDBMS, voy a ser un poco diferente e ir con un enfoque CouchDB ya que estaba leyendo sobre este fin de semana. Aquí está la estructura del documento que se me ocurrió representar un juego.
{
"round" : 1, //The final would be round 5, and I guess Alabama St. vs. Morehead would be 0
"location" : "Dayton, OH",
"division": "South",
"teams" : ["UNC", "Radford"] //A feature of Couch is that fields like teams don''t need a fixed nuber of columns.
"winner" : "UNC" //Showing my bias
}
Una aplicación más interesante o completa podría tener también datos almacenados en algún lugar para equipos, clasificaciones y similares. El enfoque de John cubre bien ese ángulo, parece. Agradezco cualquier comentario de personas que conocen mejor mis habilidades en el sofá.
Creé un pequeño sistema con las siguientes tablas:
Juegos: GameId, TournId, RoundId, Sequence, Date, VisitorId, VisitorScore, HomeId, HomeScore, WinnerId, WinnerGameId, WinnerHome (bit)
Predicciones: PredId, UserId, GameId, PredVisitorId, PredHomeId, PredWinnerId
Rondas: RoundId, TournId, RoundNum, Heading1, Heading2
Equipos: TeamId, TournId, TeamName, Seed, MoreInfo, Url
Torneos: TournId, TournDesc
Usuarios: TournId, UserName
WinnerGameId conecta al ganador de un juego con su próximo juego. WinnerHome dice si el ganador es el hogar o visitante de ese próximo juego. Aparte de eso, creo que es bastante auto explicativo.
La inclinación natural es mirar un soporte en el orden en que se juegan los juegos. Lees el diagrama tradicional desde afuera hacia adentro. Pero pensemos al revés. Cada juego se juega entre dos equipos. Uno gana, el otro pierde.
Ahora, hay un poco más que solo esto. Los ganadores de un par de juegos en particular se enfrentan entre sí en otro juego. Entonces, también existe una relación entre los juegos, independientemente de quién juegue en esos juegos. Es decir, los equipos que se enfrentan en cada juego (excepto en la primera ronda) son los ganadores de dos juegos anteriores.
Por lo tanto, es posible que notes que cada juego tiene dos "juegos infantiles" que lo preceden y determinan quién enfrenta en ese juego. Esto suena exactamente como un árbol binario: cada nodo raíz tiene como máximo dos nodos secundarios. Si sabes quién gana cada juego, puedes determinar fácilmente los equipos en los juegos "principales".
Entonces, para diseñar una base de datos para modelar esto, solo necesitas dos entidades: Team y Game . Cada Game tiene dos claves externas que se relacionan con otros Game . Los nombres no importan, pero los modelaríamos como claves separadas para hacer cumplir el requisito de que cada juego no tenga más de dos juegos anteriores. Llamémosles leftGame y rightGame , para mantener la nomenclatura del árbol binario. Del mismo modo, deberíamos tener una clave llamada parentGame que parentGame la relación inversa.
Además, como noté antes, puedes determinar fácilmente los equipos que se enfrentan en cada juego mirando quién ganó los dos juegos anteriores. Entonces solo necesitas rastrear al ganador de cada juego. Por lo tanto, otorgue a la entidad del Game una clave externa winner para la mesa del Team .
Ahora, está la pequeña cuestión de sembrar el soporte. Es decir, modelar los enfrentamientos para los juegos de la primera ronda. Podría modelar esto teniendo un Game para cada equipo en la competencia general donde ese equipo sea el winner y no tenga juegos anteriores.
Entonces, el esquema general sería:
Game:
winner: Team
leftGame: Game
rightGame: Game
parentGame: Game
other attributes as you see fit
Team:
name
other attributes as you see fit
Por supuesto, agregaría toda la otra información que quisiera a las entidades: ubicación, puntajes, resultado (en caso de que el juego se haya ganado por pérdida o por alguna otra condición fuera de lo común).
Para hacer un seguimiento de un gran número de predicciones de corchetes diferentes: puede usar 67 bits para hacer un seguimiento del resultado de cada juego. (es decir, cada uno de los sesenta y siete juegos jugados en el torneo está representado por un bit, 1 = "el equipo A gana", 0 = "el equipo B gana"). Para mostrar un corchete dado, puede usar una función bastante simple para asignar los 67 bits a la IU. La función conoce los nombres de los equipos y su ubicación inicial, y luego rastrea su movimiento a través del corchete mientras rastrea el ''bitboard''.
Para un RDBMS, creo que el enfoque más simple que sigue siendo lo suficientemente flexible para adaptarse a la mayoría de las situaciones es hacer lo siguiente:
Teams tiene [team-id (PK)] , [name] , [region-id (FK a Regions )] , [initial-seed] . Tendrás una entrada para cada equipo. (La tabla de regiones es una tabla de códigos triviales con solo cuatro entradas, una para cada región de la NCAA, y no figura aquí).
Los participantes tienen [game-id (FK para juegos )] , [team-id (FK para equipos )] , [score (nullable)] , [outcome] . [puntaje] es anulable para reflejar que un equipo podría perder. Normalmente tendrá dos participantes por juego.
Games tiene [game-id (PK)] , [date] , [location] . Para saber qué equipos jugaron en un juego, busca el Id. De juego apropiado en la tabla Participantes. (Recuerde, puede haber más de dos equipos si alguien abandonó o fue descalificado).
Para configurar el paréntesis inicial, haga coincidir las semillas apropiadas entre sí. A medida que se juegan los juegos, tenga en cuenta qué equipo tiene outcome = Winner para un juego en particular; este equipo se compara con el ganador de otro juego. Complete el corchete hasta que no queden más equipos ganadores.
Uso el mismo esquema para todas mis bases de datos.
t
--------
1 guid PK
2 guid FK
3 bit
Luego en mi código:
select [2],[3] from t where [1] = @1
@ 1 es la identificación de los datos que estoy buscando. Entonces, si [2] no es nulo, lo selecciono nuevamente, configurando @ 1 a [2].
Esto hace que sea muy fácil modelar la situación que publicaste.
4 tablas:
Equipo (Equipo, Región, Semilla)
Usuario (UserId, Email, blablabla)
Soporte (BracketId, UserId, Points)
Pick (BracketId, GameId, equipo, puntos)
Cada corchete que una persona presente tendrá 63 filas en la tabla de Selección.
Después de jugar cada juego, actualizarías la tabla de selección para anotar selecciones individuales. El campo de puntos en esta tabla será nulo para el juego que aún no se jugó, 0 para una selección incorrecta o un número positivo para la selección correcta. GameId es solo una clave que identifica en qué parte de los usuarios se ubica esta selección (por ejemplo: East_Round2_Game2, FinalFour_Game1).
La columna de puntos en la tabla de corchetes se puede actualizar después de cada actualización de la tabla de selección, de modo que contenga la suma de puntos para ese corchete. Lo más visto será la clasificación, no quiero volver a sumar cada vez que alguien quiera ver la tabla de líderes.
No necesita mantener una tabla con todos los juegos que realmente se jugaron o sus resultados, simplemente actualice la tabla de selección después de cada juego. Incluso puede hacer resaltar el corchete de selecciones correctas / incorrectas simplemente mirando la columna Puntos en la tabla de selección.