Points forts du premier
Le premier schéma obéit à de meilleures règles de normalisation, et est donc probablement meilleur dans la plupart des cas.
Avoir un thread_id , qui est fondamentalement une clé naturelle, qui n'est pas un FK vers une autre table pose probablement des problèmes. Il sera très difficile d'imposer qu'il est unique quand vous le souhaitez, et le même quand vous le souhaitez. Pour cette raison, j'encouragerais le premier schéma suggéré.
Atouts de la seconde
Votre deuxième schéma permet de modifier le sujet pour chaque message du fil de discussion. S'il s'agit d'une fonctionnalité que vous souhaitez, vous ne pouvez pas utiliser la première option, telle que vous l'avez écrite (mais voir ci-dessous).
Autres choix
Message
- id
- parent (fk to Message.id)
- subject
- content
- timestamp
- sender (fk)
MessageRecipient
- message_id (fk)
- recipient (fk)
- status (read, unread, deleted)
Au lieu d'avoir un thread_id concept, vous pouvez plutôt avoir un parent concept. Ensuite, chaque réponse pointera vers l'enregistrement du message d'origine. Cela permet le threading, sans table 'thread'. Un autre avantage possible de ceci est qu'il permet les arbres de threads aussi bien. En termes simples, vous pouvez représenter des relations beaucoup plus compliquées entre les messages et les réponses de cette façon. Si cela ne vous intéresse pas, ce ne sera pas un bonus pour votre application.
Si vous ne vous souciez pas des avantages du threading que je viens de mentionner, je recommanderais probablement un hybride de vos deux schémas :
MessageThread(models.Model):
- id
Message(models.Model):
- thread (pk)
- subject
- content
- timestamp
- sender
MessageRecipient
- message_id (pk)
- recipient (pk)
- status (read, unread, deleted)
Ceci est similaire au premier schéma, sauf que j'ai déplacé la colonne 'sujet' du MessageThread au Message table, pour permettre au sujet de changer au fur et à mesure que le fil progresse... J'utilise simplement la table MessageThread pour agir comme une contrainte sur l'ID de fil utilisé dans Message (qui surmonte les limitations que j'ai mentionnées au début de ma réponse). Vous pouvez également avoir des métadonnées supplémentaires que vous souhaitez inclure dans la table MessageThread, mais je vous laisse le choix entre vous et votre application.
