Лучшая схема базы данных для системы тегов с тегами низкого и постоянного числа

Question

В настоящее время в системах тегов используются три популярные схемы базы данных.

• MySQLicious
• Scuttle
• Toxi

В целом, наиболее часто рекомендуемая схема - это соотношение «многие ко многим» таблицы Toxi 3.

Однако я столкнулся с особой потребностью, когда количество тегов будет ограничено не более 100. Это число всегда будет постоянным, и теги никогда не будут добавлены в базу данных. Каждый отдельный элемент, скорее всего, будет содержать не более 20 тегов.

В этой ситуации какую схему вы бы порекомендовали и почему? Я впервые рассматриваю возможность использования полностью денормализованной схемы MySQLicious и использования FULLTEXT / LIKE для поиска / фильтрации.

Сам набор данных, вероятно, никогда не превысит 100 000.

Answer 1

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

Например, вам нужно искать определенные теги?Если это так, вам нужен способ найти теги по индексу.Не используйте LIKE '%word%' запросов для поиска подстрок;он будет выполняться в в сотни или тысячи раз медленнее , чем запрос, использующий индекс.

Нужно ли подсчитывать вхождения тегов?Если это так, вам нужно решение, которое ограничивает дубликаты.Единственный проект, который вы перечислили, который предотвращает дублирование, это Toxi.

Я бы не использовал ни одно решение, которое требует использования индексов MyISAM FULLTEXT.MyISAM слишком хрупок и подвержен повреждению данных.Не храните в MyISAM данные, которые вы не готовы регулярно восстанавливать или восстанавливать из резервной копии.

Answer 2

Если ваши теги действительно фиксированы и никогда не будут редактироваться, вы могли бы сойти с рук, просто используя 2 таблицы.Ваша основная таблица данных, затем таблица, которая сопоставляет записи в вашей таблице данных с идентификатором тега.Фактические значения тега будут храниться в вашем приложении (возможно, в константе).Это может оказаться немного быстрее, чем дополнительный JOIN, но имеет очевидную негибкость, так как вам потребуется изменить код приложения, чтобы изменить доступные теги.

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