Как реализовать в MySQL топики форума, которые участвуют сразу в нескольких разделах?

Question

[smallreg]

Обычно каждая новая тема (топик) на форуме относится к одному разделу форума. Но иногда необходимо добавить несколько тегов, чтобы по ним можно было искать эту тему на форуме. Чтобы не вводить дополнительную сущность - теги - хочется реализовать возможность создавать тему сразу в нескольких разделах (сам интерфейс добавления разделов при создании темы пока не важен). Фактически тут теговая система получается, но в отличие от тегов, все разделы заранее известны - новые не добавляются пользователем, а также раздел будет всегда (тегов иногда может не быть). Вопрос такой: можно ли использовать какую-то иную структуры таблицы, чтобы не делать список тегов и таблицу где прописывается соотетветствие темы (топика) каждому тегу? То есть все уложить в одну таблицу, а не в три? Мне почему-то кажется, что 'поиск Fulltext' должен подойти для такой задачи, либо что-то подобное, так как в одном поле таблицы можно просто добавлять обозначения раздела: численное или текстовое, например через запятую или пробел. Нужно, чтобы можно было быстро находить все темы (топики) для одного заданного раздела (искать тему, которая относится сразу к двум и более разделам не нужно).
Как такое реализовать максимально просто? Какую структуру таблицы использовать?

Answer 1

[ThunderCat]

Мне почему-то кажется, что 'поиск Fulltext' должен подойти для такой задачи,

Вам кажется. Кроме того что фуллтекст вообще не для этого, он еще и работать будет относительно медленно, так как вариативность значений будет низкая. Про "удобство" работы со строкой вместо нормального индекса вообще молчу.

Нужно, чтобы можно было быстро находить все темы (топики) для одного заданного раздела (искать тему, которая относится сразу к двум и более разделам не нужно).

м2м, это надежно и быстро, достаточно знать индекс раздела.

Как такое реализовать максимально просто?

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

Comments

[smallreg]

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

[Ипатьев]

smallreg, если для вас банальное м2м - это что-то ужасно сложное, то над пока забыть про форумы и пойти учиться. Курсы какие-нибудь закончить. Школу, опять же, хотя бы 9 классов.

[ThunderCat]

smallreg,

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

селект а.*,ц.* 
фром а 
лефт джоин б
он а.ид = б.а_ид
лефт джоин ц
он ц.ид = б.ц_ид
вэа ц.ид = 666
ордер бай а.дата деск
лимит скока_надо

Где тут сложность?

Answer 2

[Antonio Solo]

если количество разделов постоянное и небольшое (т.е не будет проблем с индексами) то можете для каждого раздела завести отдельное BOOL поле в таблице

но это конечно изврат и единственное нормальное решение - это M2M (использование таблицы).

а Fulltext по своей сути это такое-же создание M2M индекса, только скрытое с недрах mysql

Comments

[smallreg]

Мысль интересная! Наверное, около десятка разделов так действительно обрабатывать проще.

[Ипатьев]

smallreg, это дурацкая мысль. на редкость дурацкая.
Не надо слушать свою лень и тупые советы.

[smallreg]

Ипатьев, почему дурацкая?

[Ипатьев]

smallreg, потому что добавлять колонку в таблице чтобы сделать новую категорию - это идиотизм.
А воображать, что это ваще никагда не понадобится!!!111 - это совсем детский сад, кругозор на уровне бортика песочницы.

[smallreg]

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

[Ипатьев]

smallreg, не понимаю, при чем здесь мой кругозор.
Вы спросили, почему идея идиотская, я ответил.
Даже и раз в 5 лет идея всё равно идиотская.
Но с вашим опытом разработки в 5 дней, разумеется, 5 лет примерно равно "никогда" :)

С вами-то всё ясно, а вот Antonio Solo должно быть стыдно

[Antonio Solo]

Ипатьев, мне стыдно? за что ?

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

[Ипатьев]

но это конечно изврат и единственное нормальное решение - это M2M (использование таблицы).

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

Answer 3

[Artem Mamaev]

Когда-то я делал так. В таблицу добавлял поле, в которое помещал id в md5. Далее, когда пользователь отмечает какие ему нужно категории и в топик вписывал этот md5 разделенный вертикальной чертой. На странице самого топика я брал поле, в котором хранился md5 и через explode разделял и подготавливал запрос, чтобы вывести категории. Такую систему я применял для блогов и фотоальбомав на сайте. Но сайт маленький был, то есть не с такой аудиторией как вк. Так что за скорость работы такого подхода я ничего не могу сказать, лично меня он устраивал.

Comments

[smallreg]

md5 от id раздела или топика? И как бы вопрос, зачем именно md5, если просто номер раздела меньше места занимает?
Запрос был с LIKE?

[Artem Mamaev]

smallreg, Почему md5, Потому что если хранить id, то через like может выдать не те категории, которые вам нужны. К примеру в вашем топике есть категории с id 1, 11,21 но нет категории с номером 10. Если в like поставить 1, то вам выдаст все варианты, где есть 1. То есть, 1, 11-19,21,31 и тд. Вот почему я использовал md5

[smallreg]

grek_cheburek, спасибо

[Ипатьев]

аааааааааааааааааааааааааа!!!!
Это самый смешной ответ месяца
Я много повидал на своем веку, но вам удалось меня удивить.
grek_cheburek, вы теперь мой кумир!

[Ипатьев]

то есть идея подставить в лайк ,1, вам в голову так за всё это время и не пришла?
если уж говорить про этот адский "я не программист, ваще ничего не знаю про хранение данных, просто мимо проходил, вот придумал на коленке через запятую" способ