Тут нету двух вариантов. Кросс-таблица многие ко многим тут единственный возможный вариант.
И я все еще не понимаю, что именно в этом детсадовском примере такого, для чего нужен обязательно постгрес и не годится мускуль.
-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
Хранение меток в MySQL
- Автор темы Vorobyov1996
- Дата начала
И я все еще не понимаю, что именно в этом детсадовском примере такого, для чего нужен обязательно постгрес и не годится мускуль.
Vorobyov1996
Новичок
Vorobyov1996
Новичок
Тоже верно)
им еще не рассказали, что эти медленные СУБД - прошлый век, а есть простой удобный редис или монга, которая в 10 раз быстрее, и не надо никаких википедий, ненормальных форм, просто тык - и все, в разы быстрее, и ноду к ней, конечно, и за пару дней на ангуляре все написать, закатить штанины, выпить смузи и поехать на скутере в barber shop )))
Последнее редактирование:
мои 5 копеек
в базе 3 нормальная форма
юзеры , метки, таблица связей(ид_юзер,ид_метки)
поиск быстрый до 3х тысяч результатов через сфинкс
для сфинкса основной индекс строим через запрос вида
выбрать ид_юзер, group_concat(метка.название) as метки from связи left join метки on ... group by ид_юзер ну и дальше хвостик из примера ,чтобы порциями
диф индекс завязать например на дату добавления метки или ид_связи (введя соответствующие поля)
можно еще мультивалуе у сфинкса заюзать, но мой опыт говорит, что в текстовом поле ищется быстрее
в базе 3 нормальная форма
юзеры , метки, таблица связей(ид_юзер,ид_метки)
поиск быстрый до 3х тысяч результатов через сфинкс
для сфинкса основной индекс строим через запрос вида
выбрать ид_юзер, group_concat(метка.название) as метки from связи left join метки on ... group by ид_юзер ну и дальше хвостик из примера ,чтобы порциями
диф индекс завязать например на дату добавления метки или ид_связи (введя соответствующие поля)
можно еще мультивалуе у сфинкса заюзать, но мой опыт говорит, что в текстовом поле ищется быстрее
Vorobyov1996
Новичок
FSA
Новичок
MySQL годится. Но в PostgreSQL есть такая вещь, как массивы. Это немного упрощает задачу.
Когда нуб спрашивает, как решить хрестоматийную задачу, двух вариантов нет.
Пока не освоил джойны, не лезь в саб-селекты.
Пока не освоил хотя бы первую нормальную форму - не лезь в массивы.
Иначе на выходе мы получаем ад.
stopkran
Дилетант
Третий раз смотрю эту тему, и наконец дошло: не могу себе представить эту "картотеку меток". Там что, на каждой карточке метки находится список всех пользователей с данной меткой? Тогда это уже не "карточка метки" будет, а какая-то "брошюра метки", или "томик метки"... гм, некстати вспомнилась "метка тома"...
Потом, как это "сразу открываешь нужный ящик"? их же больше одного? Всё равно надо хотя бы "первые буквы ящика" просмотреть, сличить с заданием. И один пользователь в "томе метки" будет на "А", а другой обязательно будет на "Ю" (разные ящики). Потом так же карточки перебирать, по одной. В общем, слабовата метафора.
Разница скорее в том, что во втором случае надо просматривать только "заголовки" (идентификаторы) карточек юзеров, а в первом - текст "мультиметки". А если "заголовки" - primary key, то карточки ни в каких ни в "ящиках", а вытянуты по подземелью в один длинный-длинный ряд, и библиотекарь как бы скользит между карточками на хорошо смазанных вазелином лыжах - вот где выигрыш в скорости. Н-да. А ещё у него в руках какбы лазерный дальномер, и на нужных числах расстояний (в соответствии с primary key) он "щёлк, щёлк" - отмечает выбранные объекты, не останавливаясь. А для просмотра текста "мультиметки" ему придётся останавливаться, тормозить - вот где потери.
Я нуб (или недалеко ушёл от него). Работаю с объёмами в десятки тысяч записей (ну, иногда 100 тысяч бывает). У меня сложилась типичная структура работы с такими "метками" - именно "через пробел". Скорость выборки обычно нормальная. Если нет, делаю полнотекстовый индекс для "многометочного" поля (и тогда опять нормальная).
@stopkran, представь себе записную книжку, где есть прорези не только для первой буквы, но и для второй и так далее.
Но это все очень грубые аналогии, конечно. Хочешь понимать, как все на самом деле - читай тут http://use-the-index-luke.com/sql/anatomy/the-tree
Но это все очень грубые аналогии, конечно. Хочешь понимать, как все на самом деле - читай тут http://use-the-index-luke.com/sql/anatomy/the-tree
Хорошие вопросы, на самом деле.
> Тогда это уже не "карточка метки" будет, а какая-то "брошюра метки", или "томик метки"... гм, некстати вспомнилась "метка тома"...
Не важно. Количество в данном случае нам не важно. Главное что все фамилии собраны в одном месте, и не надо перебирать каждую карточку в картотеке.
> Потом, как это "сразу открываешь нужный ящик"? их же больше одного? Всё равно надо хотя бы "первые буквы ящика" просмотреть, сличить с заданием.
Верно. Но это все равно быстро. Ты просто не хочешь представить себе разницу между перебором ВСЕХ карточек во ВСЕХ ящиках и открытие только нужных ящиков.
Примечание. Если ситуация именно такая, как ты намекаешь - то есть БД сочтет, что пользователей, относящихся к данной метке подавляющее большинство, то она будет таки перебирать пользователей по одному. Так работает оптимизатор запросов.
Но если это достаточно редкая метка, то выигрыш будет очень значительный.
> Потом так же карточки перебирать, по одной.
Неверно. У хорошего конторщика карточки в ящике тоже отсортированы по алфавиту. И поиск нужной фамилии занимает минимальное время.Никаким перебором по одной здесь и не пахнет. Аналогия именно что идеальная, с поправкой на то что компьютер находит карточку еще быстрее.
> У меня сложилась типичная структура работы с такими "метками" - именно "через пробел".
Мощность современных компьютеров до поры до времени прощает тебе кривую архитектуру. И возможно ты никогда не выйдешь на те объемы, когда это станет критичным для скорости. В конце концов, тот факт что сейчас пышным цветом расцвели noSQL датабазы, в которых данные так и лежат навалом, как раз и является следствием возросшей мощности компьютеров - кидай, перемолотят.
Но если ты выходишь за пределы возможностей сервера, система встает колом.
Собственно,если ты до сих пор не интересовался результатом EXPLAIN для твоих запросов, то разговаривать с тобой, в сущности, не о чем. Ты так и будешь считать то твоя система идеальна. Так что давай вернемся к этому вопросу позже. В конце концов, на работающей под большой нагрузкой системе с большим количеством уже написанного кода переделывать структуру БД гораздо увлекательнее.
> Если нет, делаю полнотекстовый индекс для "многометочного" поля (и тогда опять нормальная).
Ну, если никогда не приходится редактировать метки - сливать например дубликаты или удалять ненужные - то и хорошо. В каком-то смысле я люблю любителей работать руками. Ведь есть же конструкторы-моделисты, которые тратят годы на то чтобы своими руками собрать какую-нибудь модель, которую можно купить за недельную зарплату. Или писать кропотливо отдельную программу для операции, которую можно выполнить простым SQL запросом.
> Тогда это уже не "карточка метки" будет, а какая-то "брошюра метки", или "томик метки"... гм, некстати вспомнилась "метка тома"...
Не важно. Количество в данном случае нам не важно. Главное что все фамилии собраны в одном месте, и не надо перебирать каждую карточку в картотеке.
> Потом, как это "сразу открываешь нужный ящик"? их же больше одного? Всё равно надо хотя бы "первые буквы ящика" просмотреть, сличить с заданием.
Верно. Но это все равно быстро. Ты просто не хочешь представить себе разницу между перебором ВСЕХ карточек во ВСЕХ ящиках и открытие только нужных ящиков.
Примечание. Если ситуация именно такая, как ты намекаешь - то есть БД сочтет, что пользователей, относящихся к данной метке подавляющее большинство, то она будет таки перебирать пользователей по одному. Так работает оптимизатор запросов.
Но если это достаточно редкая метка, то выигрыш будет очень значительный.
> Потом так же карточки перебирать, по одной.
Неверно. У хорошего конторщика карточки в ящике тоже отсортированы по алфавиту. И поиск нужной фамилии занимает минимальное время.Никаким перебором по одной здесь и не пахнет. Аналогия именно что идеальная, с поправкой на то что компьютер находит карточку еще быстрее.
> У меня сложилась типичная структура работы с такими "метками" - именно "через пробел".
Мощность современных компьютеров до поры до времени прощает тебе кривую архитектуру. И возможно ты никогда не выйдешь на те объемы, когда это станет критичным для скорости. В конце концов, тот факт что сейчас пышным цветом расцвели noSQL датабазы, в которых данные так и лежат навалом, как раз и является следствием возросшей мощности компьютеров - кидай, перемолотят.
Но если ты выходишь за пределы возможностей сервера, система встает колом.
Собственно,если ты до сих пор не интересовался результатом EXPLAIN для твоих запросов, то разговаривать с тобой, в сущности, не о чем. Ты так и будешь считать то твоя система идеальна. Так что давай вернемся к этому вопросу позже. В конце концов, на работающей под большой нагрузкой системе с большим количеством уже написанного кода переделывать структуру БД гораздо увлекательнее.
> Если нет, делаю полнотекстовый индекс для "многометочного" поля (и тогда опять нормальная).
Ну, если никогда не приходится редактировать метки - сливать например дубликаты или удалять ненужные - то и хорошо. В каком-то смысле я люблю любителей работать руками. Ведь есть же конструкторы-моделисты, которые тратят годы на то чтобы своими руками собрать какую-нибудь модель, которую можно купить за недельную зарплату. Или писать кропотливо отдельную программу для операции, которую можно выполнить простым SQL запросом.
Последнее редактирование: