2011-09-14 15 views
5

Escenario: Diseño de una sala de chat para que varios usuarios chateen a la vez. Todos los chats necesitan ser guardados. Cada vez que el usuario inicia sesión, debería poder ver todos los chats anteriores.Diseño de base de datos para sala de chat. Es necesario guardar cada chat

Aquí es un ejemplo de la tabla que se puede utilizar para almacenar los chats:

CREATE TABLE chat 
(
    chat_id int NOT NULL auto_increment, 
    posted_on datetime NOT NULL, 
    userid int NOT NULL, 
    message text NOT NULL, 
    PRIMARY KEY (chat_id), 
    FOREIGN KEY(userid) references users(userid) on update cascade on delete cascade 
); 

Para recuperar los chats en el orden correcto, necesito algo de clave principal de la tabla en la que estoy almacenando los chats. Entonces, si utilizo la tabla anterior para almacenar chats, entonces no puedo almacenar más de 2147483647 chats. Obviamente, puedo usar algún tipo de datos que tenga un amplio rango como bigint sin signo, pero aún así tendrá algún límite.

Pero como el escenario dice que los chats que se pueden guardar pueden ser infinitos, ¿qué tipo de tabla debo hacer? ¿Debo hacer alguna otra clave principal?

Ayúdenme a solucionar la solución. Me pregunto cómo Google o Facebook logran guardar cada chat.

+1

¿Qué pasa con bigint? Eso le da rango hasta 9223372036854775807 instancias únicas. Si tiene 1 billón de chats por día, tomará 9 billones de años antes de exceder ese rango. – selbie

+0

Pero creo que tener una mesa grande es un inconveniente de perforación. – Paddy

+0

@selbie Alguien me dijo que cuando la tabla se vuelve demasiado grande, solo coloque los datos de la tabla en un archivo, vacíe la tabla y cuando se requiera esa información simplemente cargue los datos del archivo en la tabla. Y así es como Google o fb guardan datos infinitos. Pero no sé si esta es la solución correcta o si es correcta, entonces cómo implementarla exactamente. – Paddy

Respuesta

0

Si no estaba usando MySQL, una clave principal de la identificación del usuario y una marca de tiempo probablemente funcionaría bien. Pero la marca de tiempo de MySQL solo se resuelve en un segundo. (Consulte a continuación los cambios recientes que afectan esta respuesta). Hay algunas maneras de evitarlo.

  • Deje que el código de la aplicación maneje una violación de clave principal esperando un en segundo lugar, luego vuelva a enviar.
  • Deje que el código de la aplicación proporcione una marca de tiempo de mayor precisión, y almacene como un código CHAR (n), como '2011-01-01 03: 45: 46.987'.
  • Cambie a un dbms que sea compatible con marcas de tiempo de microsegundos.

Todo el código de la aplicación debe ser del lado del servidor si tiene la intención de escribir una consulta que presente las filas ordenadas por la marca de tiempo.

tarde

La versión actual de MySQL soporta fractional seconds in timestamps.

+0

MariaDB 5.3 (todavía en versión beta) admite microsegundos en tipos de fecha y hora y hora: http://kb.askmonty.org/en/microseconds-in-mariadb –

+0

El inicio de la clave con un valor no secuencial, como un ID de usuario, causaría datos para insertar al azar en la tabla en diferentes puntos. Lo mejor es agregar secuencialmente nuevos datos al final de la tabla. Especialmente ayuda con índices. –

Cuestiones relacionadas