Vergelijking van twee db-ontwerpen voor interne berichten

Krachten van de eerste

Het eerste schema voldoet aan betere normalisatieregels en is dus in de meeste gevallen waarschijnlijk beter.

Een thread_id . hebben , wat in feite een natuurlijke sleutel is, die geen FK is naar een andere tafel, is waarschijnlijk vragen om problemen. Het zal heel moeilijk zijn om af te dwingen dat het uniek is wanneer u dat wilt, en hetzelfde wanneer u dat wilt. Om deze reden zou ik het eerste voorgestelde schema aanmoedigen.

Krachten van de tweede

Met uw tweede schema kan het onderwerp voor elk bericht in de thread worden gewijzigd. Als dit een functie is die je wilt, kun je de eerste optie niet gebruiken, zoals je die hebt geschreven (maar zie hieronder).

Andere opties

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

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

In plaats van een thread_id concept, kunt u in plaats daarvan een parent . hebben concept. Dan zal elk antwoord verwijzen naar het record van het oorspronkelijke bericht. Hierdoor is draadsnijden mogelijk, zonder een 'draad'-tabel. Een ander mogelijk voordeel hiervan is dat het thread-trees toestaat ook. Simpel gezegd, u kunt op deze manier veel gecompliceerdere relaties tussen berichten en antwoorden weergeven. Als je daar niet om geeft, dan is dit geen bonus voor je sollicitatie.

Als je niet geïnteresseerd bent in de voordelen van threading die ik zojuist noemde, zou ik waarschijnlijk een hybride van je twee schema's aanbevelen:

MessageThread(models.Model):
    - id

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

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

Dit is vergelijkbaar met het eerste schema, behalve dat ik de kolom 'onderwerp' heb verplaatst van de MessageThread naar het Message tabel, om het onderwerp te laten veranderen naarmate de thread vordert... Ik gebruik gewoon de MessageThread-tabel om op te treden als een beperking op de thread-ID die in Message wordt gebruikt (die de beperkingen overwint die ik aan het begin van mijn antwoord noemde). Mogelijk hebt u aanvullende metagegevens die u ook in de MessageThread-tabel wilt opnemen, maar dat laat ik aan u en uw toepassing over.