#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.