Мне нужно больше, чем мои текущие 3 таблицы, чтобы создать отношения, описанные в моем сообщении?

Question

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

Discord позволяет каждому пользователю создавать свои собственные серверы и приглашать люди к ним. Чтобы пользователи могли создавать серверы, я сначала создал 2 таблицы - users и servers

Users table:
id, username, password

и

Servers table:
id, name, image, userId

Таким образом, связь между этими двумя таблицами такова. user может создавать и иметь много servers, а server принадлежит user. Пока все хорошо.

После создания server, users может присоединиться к server в качестве членов этого server. A user может присоединиться к любому количеству servers, а server может иметь много участников. Я добился этого путем создания таблицы соединений server_users и отношения «многие ко многим» между users и servers:

Server_Users table:
id, userId, serverId

Это работает нормально, однако я не уверен, что logi c за отношениями «многие ко многим» между users и servers является правильным. Мне кажется, что я применяю 2 отношения между пользователями и серверами, и я не знаю, правильно ли это. Может мне нужно больше таблиц, чтобы прояснить отношения?

1. User имеет много servers, а server принадлежит user (потому что user является владельцем / создателем server, а server принадлежит только 1 user - его создателю)
2. Server имеет много users и users имеет много servers (Как и в каждом server может иметь много участников, и каждый участник может быть частью многих серверов)

Answer 1

Я думаю, что ваши подходы хороши.

Как описано ранее, это зависит от ваших вариантов использования или будущих функций.

На мой взгляд, у вас есть следующие возможности:

Возможность 1

пользователь

• id
• имя пользователя
• пароль

сервер

• id
• имя
• изображение
• userId
• adminId (ссылается на идентификатор пользователя admin / owner / creator)

user_server

• id
• userId
• serverId

Возможность 2

user

• id
• имя пользователя
• пароль

сервер

• id
• имя
• изображение
• userId

user_server

• id
• userId
• serverId
• admin (null, если не a dmin и истина, если администратор / владелец / создатель)

Возможность 3

пользователь

• id
• имя пользователя
• пароль

сервер

• id
• имя
• изображение
• userId
• roleId (1 = обычный пользователь, 2 = admin, 3 = модератор)

user_server

• id
• userId
• serverId

роль

• id
• имя роли

При возможности 1 вы ограничены одним владельцем сервера.
При возможности 2 вы можете добавить «флаг администратора» для каждого пользователя, который разрешено управлять сервером. (как в чат-группах мессенджера, где существует несколько администраторов группы)
С возможностью 3 вы можете добавить систему для управления правами соответствующих пользователей.

Answer 2

Думаю, это хороший дизайн, почти хрестоматийный пример. Цель состоит в том, чтобы таблицы имели нормальную форму , как и здесь.

Альтернативный дизайн также с тремя таблицами, если вы хотите «объединить» эти две связи, - это также использовать Server_Users для хранения пользователя, владеющего сервером, помеченного как таковой с помощью логического столбца. Однако я думаю, что это более эффективно, как вы сделали это с внешним ключом (userId), так как вам понадобится только одно соединение для отношения 1 к N.

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

Другой аспект - ограничения целостности: требуется ли, чтобы владелец сервера также член этого сервера, или он полностью независим? Это также влияет на дизайн.

Альтернативой в контексте больших объемов данных, которые не обновляются часто, является денормализация всего, путем вложения пользователей (реплицируемых) в кортежи сервера.