Как лучше расширять БД? В ширь или разделять по таблицам?
Например у меня есть таблица с пользователями (users), и я хочу ее расширить на ссылки(ссылка#1,ссылка#2,ссылка#3,ссылка#4,ссылка#5)
Что лучше, добавить поля у пользователей, либо создать отдельную таблицу ссылки(social) (с учетом того, что ссылок ограниченное количество(например 5), так что тут будет связь один ко многим, но есть ли в нем смысл)?
Что будет быстрее обрабатываться, таблицы с множеством полей, либо запросы с множеством JOIN'ов?
Пример 2
Допустим я хочу создать системную информацию для пользователей(которую нужно постоянно получать), например видимость_пользователя, возможность_комментариев, ... и еще полей 5
В таком случае лучше дополнить основную или создать отдельную и сделать связь одни-к-одному с первичным ключом в виде ИД пользователя?
UPD1:. Можешь и так и так сделать, но дело в том что широкие таблицы сложны в поддержке. Когда все разложено по полочкам, расширят проект бывает легко. А если все в одну кучу если пихать, то придет время, что даже рефакторинг не получится сделать, потому что все усложнилось, и ты начинаешь все заново с нуля писать.
UPD2:. И никогда не делай выбор ориентируясь на том, что у тебя будет ограниченное количество чего то. Это неправильный подход. Потому что идеи они такие, что каждый день меняются. Поэтому надо исходить из принципа, чтоб не было проблем для расширению.
UPD3:. Если интересно узнать больше по проектированию баз данных, посоветую книгу автора "Билла Карвина". Называет "Программирование баз данных SQL. Типичные ошибки и их устранение."
Artem0071: можешь и так и так сделать, но дело в том что широкие таблицы сложны в поддержке. Когда все разложено по полочкам, расширят проект бывает легко. А если все в одну кучу если пихать, то придет время, что даже рефакторинг не получится сделать, потому что все усложнилось, и ты начинаешь все заново с нуля писать.
Если не требуется поиска по колонкам, то современные версии MySQL умеют тип json колонок, в которой можно хранить всякие такого рода неструктурированные данные. Или сериализовывать дополнительные данные в строку json, и в текстовом поле сохранять.
А вообще, переходите на светлую сторону силы - PostgreSQL. У него это всё настолько развито, что запрос с join-ами и поиском в некоторых случаях даже существенно медленнее, против запроса по произвольному json. И есть индексы по json. А применительно к вашему вопросу - в PG из коробки есть типы массивов (т.е. поле может хранить массив значений произвольного размера), varchar[] например для списка ссылок вполне подойдет. И есть синтаксис, как массивы преобразовывать во что угодно, выводить произвольный элемент, делать запросы с их использованием и т.п.
Классическое решение вам уже подсказали, но в зависимости от конкретных запросов оно может быть очень неэффективно (и потребуется денормализация). Кроме того, да, ограничивать количество ссылок по колонкам - не очень умно (и код более громоздкий получится).
Простой
