Денормализуйте Многие ко многим, но не хотите хранить избыточные данные в мире SQL

#sql #database-design #denormalization #redundancy

#sql #database-design #денормализация #избыточность

Вопрос:

Скажем, у меня есть newsletters , а затем subscribers :

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

Должен ли я хранить это в newsletter table или в user table ? Т.е. Должен ли информационный бюллетень хранить список подписчиков или пользователь должен хранить список информационных бюллетеней, на которые он тоже подписался? Оба случая будут широко использоваться. Пользователю также нужно будет показывать информационные бюллетени, на которые он подписался, а информационные бюллетени должны будут показывать пользователей, подписавшихся на него.

Как я могу спроектировать структуру таблицы для оптимизации для чтения? Я не хочу идти по маршруту NoSQL.

Комментарии:

1. Почему / как вы определили, что вам вообще нужно хранить это в избыточном виде? Если many-to-many таблица соответствующим образом проиндексирована, поиск должен быть довольно простым.

Ответ №1:

Совпадают ли ваши Users таблицы и Subscribers таблицы? Если нет, то они должны быть такими. Users Таблица должна содержать ваших пользователей, Newsletters таблицу, ваши информационные бюллетени и вашу Subscribers связь между ними.

Скажем, у вас есть:

Пользователи

 user_id    name
1          a
2          b
3          c
  

Информационные бюллетени

 newsletter_id   name
1               x
2               y
3               z   
  

Подписчики

 user_id   newsletter_id
1         1
1         2
2         2
  

Пользователь a подписан на x и y, пользователь b подписан на y. Вы также должны добавить индексацию после user_id и newsletter_id в таблицу Подписчиков , и PK должен быть (user_id,newsletter_id) .

Ответ №2:

Для этого и существуют таблицы «многие ко многим». Вы сохраняете связь между ними в отдельной таблице. Пример:

 newsletter
 id,
 name,
 etc.

subscriber
  id,
  last, 
  first,
  etc.

newsletter_subscriber
  id,
  subscriber_id,
  newsletter_id,
  other attributes, etc.