#php #mysql #database #database-design
#php #mysql #База данных #database-design
Вопрос:
Я разрабатываю систему обмена сообщениями, которая должна будет поддерживать огромное количество сообщений и пользователей.
Я думал о двух решениях.
Usertable -> id, username ....
Messagetable -> id, from_id, to_id, message ...
Или:
Usertable -> id, username ....
Messagetable -> id, message ...
HasMessagetable -> id, from_id, to_id...
Мне интересно, каков наилучший подход к этому и почему.
Кроме того, существуют ли хорошие публикации (бесплатные или нет) о проектировании больших баз данных и лучших практиках?
Спасибо
Комментарии:
1. Пожалуйста, не используйте базу данных в качестве очереди сообщений. Пожалуйста, используйте очередь сообщений в качестве очереди сообщений. Существует множество надежных решений для очереди сообщений, которые работают прямо из коробки, без необходимости что-либо создавать.
2. Вопросы, которые вы задаете, довольно простые, поэтому я думаю, вам было бы лучше использовать готовую к использованию систему обмена сообщениями, такую как ActiveMQ.
3. Мне все равно нужно сохранить их в базе данных для дальнейшего использования, это не чат, это что-то более похожее на систему рассылки .. если я чего-то не понимаю, можете ли вы предоставить ссылку с примером того, что вы имеете в виду?
Ответ №1:
Я сделал то же самое не так давно и начал с подхода 1. Но тогда предполагалось, что пользователи смогут отправлять сообщения нескольким пользователям. Внезапно подход 1 сохранял каждое сообщение n раз, если было адресовано n получателям. Так что, если это когда-либо возможно, я думаю, что 2 лучше.
Ответ №2:
Ваша вторая схема более нормализована. Оба варианта приемлемы. Правильно нормализованный дизайн базы данных более чистый, но по соображениям производительности многие администраторы баз данных прибегают к денормализации. Я бы использовал вторую схему, пока вы не столкнетесь с проблемами производительности, это был бы лучший подход, по моему очень скромному мнению.
Обратите внимание, что нормализация до такой степени часто считается многими излишеством, как писали другие. Я делаю это таким образом по привычке и из старых (ныне устаревших) курсов по теории БД, которые я изучил 12 лет назад.
Happy-coding
Ответ №3:
В общем, чем меньше соединений вам нужно выполнить, тем лучше будут выполняться ваши запросы. Таким образом, первый вариант, вероятно, будет лучшим выбором, поскольку у вас будет очень большая база данных.
В принципе, вам нужно будет игнорировать некоторые методы нормализации базы данных, чтобы получить необходимую производительность. Однако, постарайтесь также не ограничивать себя. Например, если у вас есть сообщения, которые отправляются нескольким пользователям, вам нужно будет либо выбрать второй вариант, либо придумать другой способ справиться с этим.
Что касается ресурсов для проектирования больших баз данных, вот один для Microsoft SQL Server, но многое из того, что в нем обсуждается, будет применимо: