Fortalezas de la primera
El primer esquema obedece a mejores reglas de normalización, por lo que probablemente sea mejor en la mayoría de los casos.
Tener un thread_id , que es básicamente una clave natural, que no es un FK a otra tabla, probablemente esté buscando problemas. Será muy difícil hacer cumplir que es único cuando tú quieres que lo sea, y lo mismo cuando tú quieres que lo sea. Por esta razón, recomendaría el primer esquema sugerido.
Fortalezas del segundo
Su segundo esquema permite modificar el asunto para cada mensaje en el hilo. Si esta es una característica que desea, no puede usar la primera opción, como lo ha escrito (pero vea a continuación).
Otras opciones
Message
- id
- parent (fk to Message.id)
- subject
- content
- timestamp
- sender (fk)
MessageRecipient
- message_id (fk)
- recipient (fk)
- status (read, unread, deleted)
En lugar de tener un thread_id concepto, puedes tener un parent concepto. Luego, cada respuesta apuntará al registro del mensaje original. Esto permite enhebrar, sin una tabla de 'hilos'. Otra posible ventaja de esto es que permite árboles de rosca también. En pocas palabras, puede representar relaciones mucho más complicadas entre mensajes y respuestas de esta manera. Si no le importa eso, entonces esto no será una bonificación para su aplicación.
Si no le importan las ventajas de subprocesamiento que acabo de mencionar, probablemente recomendaría un híbrido de sus dos esquemas:
MessageThread(models.Model):
- id
Message(models.Model):
- thread (pk)
- subject
- content
- timestamp
- sender
MessageRecipient
- message_id (pk)
- recipient (pk)
- status (read, unread, deleted)
Esto es similar al primer esquema, excepto que moví la columna 'asunto' del MessageThread al Message table, para permitir que el tema cambie a medida que avanza el hilo ... Simplemente estoy usando la tabla MessageThread para actuar como una restricción en la identificación del hilo utilizada en Message (que supera las limitaciones que mencioné al comienzo de mi respuesta). Es posible que también tenga metadatos adicionales que desee incluir en la tabla MessageThread, pero eso se lo dejo a usted y a su aplicación.
