- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Что делать, если ваша email-рассылка попала в спам
10 распространенных причин и решений
Екатерина Ткаченко
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
это самый неправильный способ хранения друзей! текстовые столбцы неограниченной длинны это вообще не гуд для производительности.
нужна отдельная связывающая таблица
и как вы джойнить будете храня друзей в текстовом поле?
При таком случае про поиск, и, например, друзья друзей, можно забыть. И, кстати, в чем проблема сделать индексы в таблице друзей, ну миллион записей, ну два, ну три... чего такого, радуйтесь, когда у вас будет такая активность на сайте.
Ну, таблица связей — единственный верный вариант на мой взгляд.
это самый неправильный способ хранения друзей! текстовые столбцы неограниченной длинны это вообще не гуд для производительности.
нужна отдельная связывающая таблица
и как вы джойнить будете храня друзей в текстовом поле?
Вы говорите с точки зрения классическое реляционной модели. К вашему сведению, при проектировании высоко нагруженных систем, работающих с БД, почти всегда сознательно закладываются те или иные отклонения от "классики".
В данном случае вполне может быть выгодно, иметь 3 текстовых поля - друзья, в друзьях, друзья друзей - а логическую целостность обеспечить на уровне программного кода.
Потому что в данном случае всегда нужно одновременно работать только с одной записью. А выбрать одну запись по айдишнику из таблицы с индексом + explode/implode + изменить два поля не трогая индекса будет быстрее, нежели вставить пяток затрагивающих индекс строк в таблицу с миллионом строк... Мне так представляется, по крайней мере.
как же быть
Вы говорите с точки зрения классическое реляционной модели. К вашему сведению, при проектировании высоко нагруженных систем, работающих с БД, почти всегда сознательно закладываются те или иные отклонения от "классики".
В данном случае вполне может быть выгодно, иметь 3 текстовых поля - друзья, в друзьях, друзья друзей - а логическую целостность обеспечить на уровне программного кода.
Потому что в данном случае всегда нужно одновременно работать только с одной записью. А выбрать одну запись по айдишнику из таблицы с индексом + explode/implode + изменить два поля не трогая индекса будет быстрее, нежели вставить пяток затрагивающих индекс строк в таблицу с миллионом строк... Мне так представляется, по крайней мере.
про сознательную денормализацию я в курсе, но это на мой взгляд не тот случай когда она нужна
В высоконагруженных проектах большие таблицы обычно разбивают на несколько. Например друзья юзеров с id меньше 1 миллиона хранятся в одной таблице, с id от 1 до 2 миллионов в другой. Критерий в миллион просто для примера, это совсем не большое количество данных.
Таблица
user_id
friend_id
+ индексы
единственный реальный вариант. и миллион записей это фигня.
как же быть
Для начала корректно описать задачу. Ответ на вопрос "как хранить данные" зависит от того, как вы собираетесь их использовать.
Таблица
user_id
friend_id
+ индексы
единственный реальный вариант. и миллион записей это фигня.
+1
А вариант (id, "список друзей через запятую") не самый удобны для дальнейшей обработки