Jämför två db-designer för intern meddelandehantering

Det förstas styrkor

Det första schemat följer bättre normaliseringsregler, och det är förmodligen bättre i de flesta fall.

Att ha ett thread_id , som i grunden är en naturlig nyckel, som inte är en FK till ett annat bord ber förmodligen om problem. Det kommer att vara väldigt svårt att genomdriva att det är unikt när du vill att det ska vara, och detsamma när du vill att det ska vara det. Av denna anledning skulle jag uppmuntra det första föreslagna schemat.

Styrker av tvåan

Ditt andra schema tillåter att ämnet ändras för varje meddelande i tråden. Om det här är en funktion du vill ha kan du inte använda det första alternativet, som du har skrivit det (men se nedan).

Andra alternativ

Message
    - id
    - parent (fk to Message.id)
    - subject
    - content
    - timestamp
    - sender (fk)

MessageRecipient
    - message_id (fk)
    - recipient (fk)
    - status (read, unread, deleted)

Istället för att ha ett thread_id koncept kan du inte ha en parent begrepp. Då kommer varje svar att peka på det ursprungliga meddelandets post. Detta tillåter trådning, utan en "trådtabell". En annan möjlig fördel med detta är att det tillåter trådträd också. Enkelt uttryckt kan du representera mycket mer komplicerade relationer mellan meddelanden och svar på detta sätt. Om du inte bryr dig om det kommer detta inte att vara en bonus för din ansökan.

Om du inte bryr dig om trådfördelarna jag just nämnde, skulle jag förmodligen rekommendera en hybrid av dina två scheman:

MessageThread(models.Model):
    - id

Message(models.Model):
    - thread (pk)
    - subject
    - content
    - timestamp
    - sender

MessageRecipient
    - message_id (pk)
    - recipient (pk)
    - status (read, unread, deleted)

Detta liknar det första schemat, förutom att jag flyttade "ämne"-kolumnen från MessageThread till Message tabell, för att tillåta att ämnet ändras allt eftersom tråden fortskrider... Jag använder helt enkelt MessageThread-tabellen för att fungera som en begränsning av tråd-ID:t som används i Message (vilket övervinner begränsningarna jag nämnde i början av mitt svar). Du kan ha ytterligare metadata som du vill inkludera i MessageThread-tabellen också, men jag överlåter det till dig och din ansökan.