Сравняване на два дизайна на db за вътрешни съобщения

Силни страни на първия

Първата схема се подчинява на по-добри правила за нормализиране и така вероятно е по-добра в повечето случаи.

Имате thread_id , който по същество е естествен ключ, който не е FK към друга маса вероятно иска проблеми. Ще бъде много трудно да се наложи, че е уникален, когато искате да бъде, и същият, когато искате да бъде. Поради тази причина бих насърчил първата предложена схема.

Силни страни на второто

Втората ви схема позволява да се променя темата за всяко съобщение в нишката. Ако това е функция, която искате, не можете да използвате първата опция, както сте я написали (но вижте по-долу).

Други опции

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

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

Вместо да имате thread_id концепция, можете вместо това да имате parent концепция. Тогава всеки отговор ще сочи към записа на оригиналното съобщение. Това позволява врязване на нишки, без таблица с "нишки". Друго възможно предимство на това е, че позволява дървета на нишки както и Просто казано, по този начин можете да представите много по-сложни връзки между съобщения и отговори. Ако не ви пука за това, тогава това няма да бъде бонус за вашето приложение.

Ако не ви пука за предимствата на нишките, които току-що споменах, вероятно бих препоръчал хибрид от двете ви схеми:

MessageThread(models.Model):
    - id

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

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

Това е подобно на първата схема, с изключение на това, че преместих колоната 'subject' от MessageThread към Message таблица, за да позволя на темата да се променя с напредването на нишката... Просто използвам таблицата MessageThread, за да действа като ограничение за идентификатора на нишката, използван в Message (което преодолява ограниченията, които споменах в началото на моя отговор). Може да имате и допълнителни метаданни, които искате да включите в таблицата MessageThread, но ще оставя това на вас и вашето приложение.