¿un campo de estado o una tabla nueva?

[minombreesmm]

Que será mejor para las notificaciones?
tener un campo de estado (no leida, leida)
o insertar las leidas en otra tabla y borralas de la origen?

claramente se ve que si libero la tabla de las leidas, seran mas ligeras las consultas de notificaciones, pero por otro lado estaria saturando la base de datos con otra tabla.

¿que me aconsejan?

de antemano gracias

[ZedGe1505]

Todo en una tabla, es mejor tener 1 campo más que 10 campos en una nueva tabla.

Aparte si tienes llaves e índices no debieses saturar el flujo hacia la base de datos con consultas

[minombreesmm]

Iniciado por ZedGe1505

Todo en una tabla, es mejor tener 1 campo más que 10 campos en una nueva tabla.

Aparte si tienes llaves e índices no debieses saturar el flujo hacia la base de datos con consultas

Entonces es mejor:

tabla1(para insertar y leer el estado de leido o no)

campo2
campo3
estado
con 500 mil registros

a esto otro:


tabla1(solo para insertar y borrar y consultar para insertar lo leido en la tabla2)

campo2
campo3
estado
con 20 mil registros


tabla2(solo para insertar lo que ya se leyo en la tabla 1)

campo2
campo3
estado
con 480 mil registros ya leidos que no se consultaran

[minombreesmm]

Cabe destacar que la tabla seria un registro por cada notificacion de usuario..por ejemplo

si usuario A comenta un tema del usuario B, en donde hay comentarios del usuario C,D,E,F,G.

serian 6 registros los que habria.
uno por cada usuario notificado, y asi cada vez que alguien comente, los registros irian multiplicandose.

[gnzsoloyo]

Visto a vuelo de pájaro, es un esquema que sólo requiere de dos tablas.
Una tabla de comentarios, con una FK nulable que apunta a si misma, FK que se usaría para saber cual es el inicio de cada hilo (el inicio sería NULL).
Una tabla de comentarios leídos, donde solo se requerirían dos campos: uno para el ID del mensaje y otro para el ID del que lo leyó y posiblemente un tercer campo con la fecha y hora en que ocurriera. De esa forma cuando un usuario accede se pueden buscar los hilos leídos y los no leídos, así como los mensajes que se leyeron o no.

El esquema que describes se parece bastante al funcionamiento de este mismo foro... ¿te diste cuenta?

[minombreesmm]

Iniciado por gnzsoloyo

Visto a vuelo de pájaro, es un esquema que sólo requiere de dos tablas.
Una tabla de comentarios, con una FK nulable que apunta a si misma, FK que se usaría para saber cual es el inicio de cada hilo (el inicio sería NULL).
Una tabla de comentarios leídos, donde solo se requerirían dos campos: uno para el ID del mensaje y otro para el ID del que lo leyó y posiblemente un tercer campo con la fecha y hora en que ocurriera. De esa forma cuando un usuario accede se pueden buscar los hilos leídos y los no leídos, así como los mensajes que se leyeron o no.

El esquema que describes se parece bastante al funcionamiento de este mismo foro... ¿te diste cuenta?

Ajam. osea tengo
una tabla comentarios con su iddetema, esa es independiente de las notificaciones

tengo una de notificaciones donde guardo id del comentario o tema segun el valor de otro campo, y actualmente hay un campo que se llama, estado(leido o no leido).
esa tabla inserta registros tantos usuarios notificados sean.

aqui el problema que veo es que esta tabla crecera muy rapidamente.
y por eso pensaba a tener una segunda tabla donde inserte los comentarios ya leidos y borrarlos fisicamente de la de notificaciones, y asi poder hacer las consultas mas rapidas en esa tabla.

y si me doy cuenta que es igual al esquema de este foro, de face y de otros.
pero no tanto al de este, ya que aqui se necesita suscribirse al tema para recibir notificaciones de donde el usuario a comentado.
en mi caso la suscripcion no hace falta, el usuario recibira notificaciones del tema donde halla comentado, pues se deduce que es de su interes el tema y las respuestas en el.
de hecho busque esa opcion aqui pero no la haye jejes, por eso es que me suscribo a todos los temas que comento.