Как мне структурировать эту схему группы / роли?

Question

Я пишу приложение, которое имеет определенные функции, похожие на список друзей в Google Circle / FB.

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

На данный момент мы используем реляционную базу данных (mysql) из-занекоторое ограничение со временем и ресурсом.В любом случае я пытаюсь найти лучший способ структурировать нашу базу данных, чтобы сбалансировать производительность и ясность.Вот что у нас сейчас:

users:
  user_id
  default_group_id
  friend_group_id

groups:
  group_id

groups_to_users:
  user_id
  group_id

messages:
  message_id

messages_to_groups:
  message_id
  group_id

galleries_to_groups:
  gallery_id
  group_id

Когда пользователь создается впервые, у него / нее будет 2 базовые группы:

1. группа по умолчанию, которая будет содержать только этот единственныйuser
2. группа друзей, которая будет содержать всех, с кем он / она дружит

Мы просто будем использовать group_id для определения «разрешения» вместо использования user_id.Таким образом, мы можем пропустить сложность запроса 2 таблиц.

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

, если пользователь отправляет сообщение группе, мы просматриваем список участников этой группы и сохраняем запись для каждого пользователя (message_id,(default_) group_id).Проблема в том, что, если в этой группе более 1000 участников, нам придется вставлять более 1000 записей для каждого нового сообщения, отправляемого в эту группу, а также когда этот пользователь вносит какие-либо изменения в члена группы, нам также необходимо обновитьогромное количество записей.

Интересно, есть ли лучший способ структурировать нашу базу данных для повышения производительности?

Answer 1

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

Я думаю, что вы должны придерживаться оригинального дизайна и убедиться, что ваши таблицы правильно проиндексированы, чтобы СУБД могла делать то, для чего она построена, - то есть быстро и эффективно объединять наборы данных.

Если вы разрабатываете для своих таблиц правильный вид первичных и внешних ключей, и если вы разрабатываете свои запросы таким образом, чтобы они использовали преимущества индексов PK / FK, то таким образом вы оптимизируете свою производительность.

Answer 2

Древовидная структура подходит для представления этого вида иерархических данных

Например, { uid1 msgid2 uid2 groupid1 uid1 groupid2 uid1 uid2 msgid1 } Так что модель данных может быть гибкой для поиска

• целевого сообщения для отдельного пользователя или группы
• список сообщений aконкретный пользователь - совокупность сообщений, адресованных списку групп, членом которых он является, и сообщений, адресованных непосредственно пользователю