Хранение меток в MySQL

[Vorobyov1996]

Привет всем форумчанам, с прошедшим праздником!) Друзья, такая тема. Мое будущее приложение будет многопользовательским.. Каждый пользователь сможет найти другого пользователя по меткам, типо #хештегов.На одного пользователя, к примеру по 10 #меток. Вопрос следующий.. Как лучше хранить эти метки?

1. Для каждого пользователя создать столбец с метками и туда запихать метки через пробел?

или

2. Таблица меток => пользователь - метка - отдельная строка. То есть создать таблицу с метками и туда сувать: 1 метка - 1 строка?

Или может у кого свои варианты? Буду рад прочитать Ваше мнение)

 

[AnrDaemon]

Встречный вопрос - вы вообще в курсе, чем первая нормальная форма отличается от второй?

 

[Vorobyov1996]

Встречный вопрос - вы вообще в курсе, чем первая нормальная форма отличается от второй?

Вы про какие формы говорите?

 

[WMix]

https://ru.wikipedia.org/wiki/Нормальная_форма

 

[c0dex]

1. Метку должно быть просто найти.
2. Метки пользователя должно быть просто найти и вывести
3. Нужно уметь быстро и просто выводить всех пользователей по метке.

Как ты будешь это делать в случае п.1 - я хрен знает.

 

[Vorobyov1996]

https://ru.wikipedia.org/wiki/Нормальная_форма

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

 

[Vorobyov1996]

1. Метку должно быть просто найти.
2. Метки пользователя должно быть просто найти и вывести
3. Нужно уметь быстро и просто выводить всех пользователей по метке.

Как ты будешь это делать в случае п.1 - я хрен знает.

Следовательно нужно делать по второму пункту.. я тоже к этому пункту пришел... Но есть сомнения, а если 100 000 пользователей. + 100 меток на пользователя...Mysql потянет выборку? (100000 пользователей пока нет, но вопрос на будущее
)

 

[AnrDaemon]

Лучше не смотри вообще на педивикию, а найди статью где-нибудь, на примерах показывающую логический переход от одной формы к другой.
Серверу пофиг, что ты там лепишь… Лишь бы памяти хватило. И потом, кто будет выбирать ВСЕ метки по ВСЕМ пользователям?

 

[fixxxer]

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

 

[Vorobyov1996]

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

Плюсую)) Я и сам такой)

 

[Vorobyov1996]

Серверу пофиг, что ты там лепишь… Лишь бы памяти хватило. И потом, кто будет выбирать ВСЕ метки по ВСЕМ пользователям?

Вопрос не в том что все метки по всем пользователям, но ведь даже 1 метку достать из 1 000 000 сложнее чем 1 метку из 1000? Или я не так понял? Просто никогда не работал с высоко-нагруженными приложениями...

 

[FSA]

Иногда я жалею, что брал MySQL для своих проектов, а не PostgreSQL.

 

[c0dex]

@Vorobyov1996, не работал и не будешь, если начинаешь с преждевременной оптимизации

 

[Vorobyov1996]

Иногда я жалею, что брал MySQL для своих проектов, а не PostgreSQL.

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

 

[Vorobyov1996]

@Vorobyov1996, не работал и не будешь, если начинаешь с преждевременной оптимизации

Может быть и есть какая то логика в этом.. Но я её не вижу.. и для меня это бредово.. оптимизировать после..

 

[c0dex]

@Vorobyov1996, откуда же ты узнаешь что именно оптимизировать, пока ты не уперся в производительность в каком-либо месте?

 

[FSA]

100 000 пользователей * 100 меток * 20 байт на метку (для примера) = 200 мегабайт. Накинем грубо накладных расходов в 5 раз индексы и прочее :-D Для ста тысяч пользователей вам жалко гигабайта оперативки дополнительной?
Я думаю стоит организовать для хранения ключевых слов отдельную таблицу + таблицу для связи слов и пользователей.

 

[Фанат]

100 000 пользователей * 100 меток * 20 байт на метку (для примера) = 200 мегабайт.

Тебе не за постгрес надо переживать, а за то что арифметику не учил.
100000 пользователей по 4 байта на 10 меток по 4 байта ~ 8 мегабайт.

 

[FSA]

@Фанат, у меня расчёт для случая когда одна таблица для меток+связь с пользователем. Понятно дело, что при том способе, что я указал ниже расчёта, памяти надо значительно меньше, но нужно больше таблиц связывать.

 

[Фанат]

Вопрос не в том что все метки по всем пользователям, но ведь даже 1 метку достать из 1 000 000 сложнее чем 1 метку из 1000? Или я не так понял? Просто никогда не работал с высоко-нагруженными приложениями...

Хороший вопрос на самом деле. Объясняю на пальцах.

Представь себе две картотеки. Знаешь что такое картотека? Ящички с карточками. На ящичках написана первая буква фамилии. В ящичке фамилии отсортированы по алфавиту.
По второму варианту ты лезешь в отдельную картотеку меток, сразу открываешь ящичек с нужной меткой, и там быстро находишь среди отсортированных карточек ту, которая соответствует нужной метке. Берешь эту карточку, идешь к картотеке фамилий и так же быстро находишь всех юзеров с этой карточки. И тебе не важно, сколько карточек в картотеке, потому что ты сразу открываешь нужный ящик и сразу находишь в нем нужную карточку.

По первому варианту тебе надо открывать все ящики в картотеке пользователей по очереди, перебирать все карточки в ящике по одной, и искать те, в которых встречается нужная метка.

что у тебя получится быстрее?