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.
¿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
Pero creo que tener una mesa grande es un inconveniente de perforación. – Paddy
@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