Таблица нормальных отношений запроса MySQL против объединенной таблицы отношений

Question

У меня есть вопрос об отношениях между двумя таблицами.

Допустим, у нас есть таблица пользователей и ссылки.

users
+++++++++
id name
1  name1
2  name2
3  name3
+++++++++

---

links
+++++++++
id link
1  link1
2  link1
3  link1
+++++++++

Теперь нормальный способ связать эти два с таблицей name_links. Например:

name_links
++++++++++++
uid  lid
1    1
1    3
2    3
2    1
2    2
3    2
++++++++++++

Теперь мне стало интересно, будет ли хорошей идеей сделать такой стол

name_links
++++++++++++
uid  lid
1    1,3
2    1,2,3
3    2
++++++++++++

Плюсы и минусы, о которых я могу думать:

pros1:

Вы всегда будете искать по индексам, быстрее запросов Например, выберите где UID = 1, а затем выберите ссылки 1,3. Оба являются индексами, поэтому это будет быстрая загрузка.

Если у вас 1000 пользователей, и у каждого из них есть 20 ссылок, это означает, что вам нужно пройти 20 000 записей, чтобы получить все ссылки (я думаю, не уверен в этом). Используя этот метод, вы берете только один индекс, и все готово.

cons1:

Вам придется чаще обновлять таблицу name_links, читать, редактировать и писать пример пользователя 2 удаляет ссылку2 метод будет:
+ получить строку пользователя 1
+ убрать номер из строки
+ вставить новую строку

Здесь все сделано для индекса, поэтому я предполагаю, что это будет быстро.

cons2:

Еще один минус - когда вы удаляете ссылку 2, вам нужно пройти через все строки, но допустим, что это не такая большая проблема, так как это случается не часто.

Это то, что я могу придумать до сих пор, и я нахожусь в точке моего проекта, где я должен решить, куда идти.

Я хотел бы получить совет, какой метод выбрать. У меня есть свои плюсы и минусы, верно? Есть вещи, которые я не принимаю во внимание. Любая помощь по этой теме будет высоко оценена.

Спасибо, ребята!

Answer 1

Денормализованное решение имеет следующие недостатки:

• Вы не можете эффективно объединить имена и ссылки (FIND_IN_SET не может быть sargable)

• Вы не можете применить ссылочную целостность, используя FOREIGN KEYs (в InnoDB)

• Удаление и добавление отношения имя-ссылка более сложное

Если вы никогда не выполняете поиск имен по указанной ссылке, а ссылок мало, возможно, вы выиграете, избавившись от дополнительного объединения.

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

Если фиксированный links установлен, вы можете вместо него использовать собственный тип данных SET.

Answer 2

Я ни в коем случае не эксперт по базам данных, но ваш второй вариант кажется мне очень плохой идеей. Даже если предположить, что вам никогда не потребуется, скажем, выполнять поиск по ссылке в таблице name_link, выполнение каких-либо действий со ссылками будет большой (ненужной, IMO) дополнительной работой.

Answer 3

Вы абсолютно НЕ ДОЛЖНЫ объединять записи, если в этом нет необходимости. Подумайте о будущих возможностях, допустим, вы хотите посчитать, сколько пользователей имеют ссылку 3. Это неприятно для вашего второго метода.

Итак, я предполагаю, что на вашем примере это будет соединение «многие ко многим», то есть ссылка может быть связана со многими пользователями, и многие пользователи могут быть связаны со ссылкой. Таким образом, у вас потенциально есть атрибуты, связанные с пользователями, подключающимися к ссылке, например time_linked Это может пойти на вашу таблицу name_links.