Esquema de mensajería de juego de base de datos

Question

Estoy tratando de usar una base de datos como back-end para un sistema de mensajería en mi juego (algo así como mensajería instantánea). Estoy usando una base de datos local para almacenar los mensajes recibidos y una base de datos en mi servidor para enviarlos. Aquí están las tablas que estoy usando:

Usuarios:
nombre de usuario (varchar)
idioma (varchar)
currentGames (varchar)

Mensajes:
remitente (varchar)
receptor (varchar)
mensaje (varchar)
marca de tiempo (int)

Mi pla n es que cuando un usuario envía un mensaje, primero almaceno el mensaje en su base de datos local y luego envío el mensaje al servidor.

Cuando un usuario verifica si hay mensajes nuevos (sondeo), primero obtiene la última marca de tiempo de su base de datos local y utiliza esta vez para consultar la base de datos en línea para todos los mensajes enviados después de ese momento. Todos los mensajes recibidos se eliminan de la base de datos.

¿Hay algún problema con la forma en que estoy haciendo esto? Estoy tratando de prepararme para lo peor, y no tengo idea de cómo escalará este tipo de plan. No estoy usando una identificación única para la tabla de "Usuarios" y creo que debería hacerlo. Debido a que mi experiencia con la base de datos es limitada, no entiendo completamente la importancia del ID único de incremento automático o cómo me podría ayudar aquí. Cualquier consejo/crítica sería apreciado.

Answer 1

Como la mayoría de etiquetas de jugadores son transitorios y es probable que quieren diferenciar entre el ID de un jugador (privado) y su nombre de usuario (público, al menos para los amigos), entonces usted quiere un diseño local de la siguiente manera:

FRIEND -- The local user's own tag should go in here too. 
(user_id 
, current_gamer_tag 
, last_update_timestamp 
) 

GAME 
(game_id 
, game_name -- No timestamp here because the name doesn't change? 
) 

MESSAGE 
(message_id -- If you make this a GUID you can use it for synching with the server. 
, sending_user_id -- FK to FRIEND 
, receiving_user_id -- Also FK to FRIEND 
, timestamp 
, content 
) 

Esto contiene mensajes entrantes y salientes localmente y permite que la pantalla de mensajes se centre en etiquetas de jugador mientras que, al mismo tiempo, es fácil sincronizar con el servidor. Por cierto, también podría considerar cambiar el recipient_user_id a una subtabla que contiene una lista de destinatarios si tiene tres o más juegos.

El uso de identificadores únicos es importante por muchas razones. Lo más importante es que te permite modificar tus etiquetas de jugador y evita que tengas que revelar los ID de usuario de tus jugadores en las pantallas de mensajes.También hay un ahorro de espacio aquí porque un entero, incluso un bigint es más pequeño que una etiqueta de jugador. Esto es mejor para la escalabilidad. Usar un GUID en lugar de un número entero creciente para el ID del mensaje significa que no tendrá un "punto caliente insertado" en la tabla de mensajes del servidor, que tendrá un mejor rendimiento siempre que la tabla de mensajes del servidor tenga suficiente espacio libre incorporado . Además, los ID de mensaje se pueden generar en el extremo del cliente y puede estar seguro de que no habrá colisiones de teclas cuando los mensajes lleguen al servidor.

Answer 2

Aquí está mi aspecto. Así es como lo haría ...

Todo depende de cómo funcione su sistema. Si permite que cada nombre de usuario se use una vez y no permite que el usuario lo cambie, lógicamente no tendrá que usar una identificación. Personalmente, utilizo una identificación autoincrementada para mi base de datos de usuarios. Si yo fuera tú, usaría una identificación, simplificaría todo.

Probally en la base de datos local que tendrá que tener algo como esto:

Friend's database: 
USER_ID USERNAME 

Game's database: 
GAME_ID USER_PLAYING_ID 

Messages database: 
TO_USER TIMESTAMP GAME_ID 

Así que al presentar a la base de datos en línea que tendrá un identificador del usuario para enviar a, así como la información del juego.

Una vez más, cómo lo haría. Aparte de todo lo demás, parece que sabes lo que estás haciendo.