Как правильно реализовать таблицу БД для создания тегов на сайте?

Question

[NewTypes]

У меня нет практики написания backend"а сайтов, а потому прошу помощи.

Как я вижу:
- таблица tags с полями id, title и slug;
- таблица связи с полями tag_id и article_id;
- ну и конечно таблица articles с кучей полей и полем id;

Посоветуйте лучшие практики (статьи или прямо тут), где я мог бы посмотреть как это реализовывается. Ищу быстрое решение. Под тегами подразумеваются теги под статьями (как например на тостере). Я б нагуглил, да не могу. Спасибо за ответы

Answer 1

[_ _]

А на кой такой оверхед-то?
В таблицу object добавляете строковый "tags", где в строке теги через разделитель какой-нибудь.
Это поле используете для вывода тегов на странице
В таблице tag_object строковое поле tag, и id объекта, чтобы искать по конкретным тегам.
Плюс я бы еще держал таблицу tags, где был бы список всех уникальных тегов с количествами использований.

Зачем вам id для тегов? Про slug - если вам надо искать по транслитерованному тегу, то туда же в tag_object его пихайте.

Если у вас 10000 объектов и 1000 тегов, посчитайте, сколько в худшем случае записей у вас будет в таблице tag_object? В вашем случае, для того, чтобы просто получить список тегов к объекту, нужно будет столько геммороя поиметь - ладно, если к одной записи (и то ничего хорошего). А если к списку? Да с пагинацией? Присоединять таблицу с 10000000 ради списка тегов?

Comments

[Melkij]

А теперь выберите мне, пожалуйста, все записи с определённым тегом. Что, fullscan получился? Конечно, fullscan.
А в нормальной форме - тупой поиск по индексу.

10 лямов чисел - пустяк. Любая даже дохлая виртуалка справится.

[_ _]

Какой фуллскан? SELECT objects.* FROM tag_object LEFT JOIN objects ON tag_object.id = objects.id WHERE tag=:tag
То, что тег в tag_object стоит проиндексировать, упоминать, я думаю, не стоит?

[_ _]

Я в шоке. Не программируйте никогда, пожалуйста.

[NewTypes]

Интересный вариант. Я на самом деле думал о нем, но отмел на лету ввиду страха, что базу раздует по самое не балуй (тегов планируется не менее 200к, объектов на первое время - порядка 100к), а соответственно (теоретически) упадет скорость (хотя я сомневаюсь, ведь mysql спроектирована и для большего).

[Melkij]

@AMar4enko , прощу прощения, среагировал на "где в строке теги через разделитель какой-нибудь." и не заметил с утра, что эта денормализация только для вывода подразумевается. Не будете же спорить, что находятся умники, именно в одном поле через запятую и хранить данные, а потом по like '%,n,%' искать?

[_ _]

@Melkij Спорить не буду, клинических товарищей хватает во всех областях.

[bushart]

Наглядная инструкция на нарушить концепцию KISS и поиметь проблем с избыточностью данных и усложненной поддержкой.

Answer 2

[Руслан Касымов]

Вы описали классическую связь многие ко многим через промежуточную таблицу, что тут еще придумаешь? Это и есть best practices... Только не забываем в mysql настроить ограничения foreign keys на промежуточной таблице.

Answer 3

[xaja]

Wordpress посмотрите как сделан