Система обмена сообщениями. Вопрос по дизайну базы данных

Question

Я разрабатываю систему обмена сообщениями, которая будет поддерживать огромное количество сообщений и пользователей.

Я думал о двух решениях.

Usertable -> id, username ....
Messagetable -> id, from_id, to_id, message ...

Или:

Usertable -> id, username ....
Messagetable -> id, message ...
HasMessagetable -> id, from_id, to_id...

Мне интересно, как лучше и почему.

Кроме того, есть хорошие публикации (бесплатные или нет) о дизайне больших баз данных и передовом опыте?

Спасибо

Answer 1

Ваша вторая схема более нормализована.Оба приемлемы.Правильно нормализованный дизайн базы данных более чистый, но по причинам производительности многие администраторы баз данных прибегают к денормализации .Я бы использовал вторую схему, пока вы не столкнетесь с проблемами производительности, это будет лучшим подходом, по моему скромному мнению.

Обратите внимание, что нормализация в такой степени часто считается чрезмерной для многих, как и другие.Я делаю это по привычке и на старых (ныне устаревших) курсах теории БД, которые я изучил 12 лет назад.

Happy-coding

Answer 2

Я сделал то же самое не так давно и начал с подхода 1. Но тогда пользователи должны были иметь возможность отправлять сообщения нескольким пользователям.Внезапно подход 1 сохранил каждое сообщение n раз, если n получателей были адресованы.Так что, если это когда-либо возможно, я думаю, что 2 лучше.

Answer 3

В общем, чем меньше нужно выполнить соединений, тем лучше будут выполняться ваши запросы.Поэтому первый вариант, вероятно, будет лучшим выбором, поскольку у вас будет очень большая база данных.

По сути, вам придется игнорировать некоторые методы нормализации базы данных, чтобы получить необходимую производительность.Однако постарайтесь не ограничивать себя.Например, если у вас есть сообщения, адресованные нескольким людям, вам нужно будет либо выбрать второй вариант, либо найти другой способ справиться с этим.

Что касается ресурсов для проектирования больших баз данных, вот одиндля Microsoft SQL Server, но многое из того, что обсуждается, применимо:

http://sqlcat.com/