Таблица сообщений:
message_id | |message_author | message_text |Таблица тегов:
tag_id | tag_name |Таблица связей:
id | tag_id | message_id |Хочу реализовать такую фишку, как релевантность тегов. То есть, один человек напишет метку «пыха», а другой — «pyha». Нужно, чтобы при просмотре сообщений по одному из этих тегов выводились сообщения, которые относятся также и ко второму (третьему, десятому) тегу. «Релевантность», естественно, назначается вручную админом.
Вопрос — как это реализовать на уровне БД?
Мой вариант — еще одна таблица для релевантности:
id | main_tag_id | related_tag_id |Но, мне кажется, при большом количестве релевантных тегов начнутся проблемы с выборкой, ведь можно отнести тег B как релевантный А, а тег С — как релевантный B, но для А он же тоже релевантный!
2. Опять же, те ще сущности, пусть будут сообщения. Пользователь через форму их фигачит. Все сообщения, которые прислал пользователь, видны у него в профиле в разделе «Мои сообщения». Но, дальше идет премодерация, и некоторые из этих сообщений попадают, скажем так, на главную, то есть становятся видны всем. А в «моих сообщениях» пользователь все равно видит все, им присланные, только с пометками — утверждено, не утверждено, в ожидании проверки.
Вопрос — нужно ли две таблицы — одну для присланных, вторую для утвержденных, или достаточно одной таблицы с полем `approved`?
Мой вариант — да, нужно, потому что это почти что разные сущности, кроме того, для выборки лучше тянуть из таблицы утвержденных без всяких условий, чем тянуть из общей таблицы WHERE `approved`=1.
