Рекомендуемый дизайн базы данных SQL для тегов или тегов

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

Table: Item
Columns: ItemID, Title, Content

Table: Tag
Columns: TagID, Title

Table: ItemTag
Columns: ItemID, TagID

Обычно я соглашусь с Яаковом Эллисом, но в этом частном случае есть другое жизнеспособное решение:

Используйте две таблицы:

Table: Item
Columns: ItemID, Title, Content
Indexes: ItemID

Table: Tag
Columns: ItemID, Title
Indexes: ItemId, Title

У этого есть несколько основных преимуществ:

Во-первых, это значительно упрощает разработку: в решении с тремя таблицами для вставки и обновления item вам нужно найти Tag таблицу, чтобы увидеть, есть ли уже записи. Затем вы должны присоединить к ним новые. Это нетривиальная задача.

Затем он делает запросы проще (и, возможно, быстрее). Вам нужно выполнить три основных запроса к базе данных: вывести все Tags для одного Item, нарисовать облако тегов и выбрать все элементы для одного заголовка тега.

Все теги для одного элемента:

3-таблица:

SELECT Tag.Title 
  FROM Tag 
  JOIN ItemTag ON Tag.TagID = ItemTag.TagID
 WHERE ItemTag.ItemID = :id

2-таблица:

SELECT Tag.Title
FROM Tag
WHERE Tag.ItemID = :id

Облако тегов:

3-таблица:

SELECT Tag.Title, count(*)
  FROM Tag
  JOIN ItemTag ON Tag.TagID = ItemTag.TagID
 GROUP BY Tag.Title

2-таблица:

SELECT Tag.Title, count(*)
  FROM Tag
 GROUP BY Tag.Title

Элементы для одного тега:

3-таблица:

SELECT Item.*
  FROM Item
  JOIN ItemTag ON Item.ItemID = ItemTag.ItemID
  JOIN Tag ON ItemTag.TagID = Tag.TagID
 WHERE Tag.Title = :title

2-таблица:

SELECT Item.*
  FROM Item
  JOIN Tag ON Item.ItemID = Tag.ItemID
 WHERE Tag.Title = :title

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

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

Аргумент непоследовательности тоже немного спорен. Теги - это поля с произвольным текстом, и здесь нет ожидаемой операции типа «переименовать все теги с« foo »в« bar »».

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

Если вы используете базу данных, которая поддерживает map-reduce, например couchdb, хранение тегов в текстовом поле или поле списка действительно лучший способ. Пример:

tagcloud: {
  map: function(doc){ 
    for(tag in doc.tags){ 
      emit(doc.tags[tag],1) 
    }
  }
  reduce: function(keys,values){
    return values.length
  }
}

Выполнение этого с помощью group = true сгруппирует результаты по имени тега и даже вернет количество встреч с этим тегом. Это очень похоже на подсчет вхождений слова в текст.

Используйте один столбец форматированного текста [1] для хранения тегов и используйте способную систему полнотекстового поиска для его индексации. В противном случае вы столкнетесь с проблемами масштабирования при попытке реализовать логические запросы.

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

[1] Некоторые СУБД даже предоставляют собственный тип массива, который может даже лучше подходить для хранения, поскольку не требует этапа синтаксического анализа, но может вызвать проблемы с полнотекстовым поиском.

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

Наличие таблицы «тегов» и таблицы карты делает довольно тривиальным создание облаков тегов и тому подобного, поскольку вы можете легко собрать SQL, чтобы получить список тегов с подсчетом того, как часто каждый тег используется.

Я бы предложил следующий дизайн: Таблица элементов: Itemid, taglist1, taglist2 - это будет быстро и упростит сохранение и извлечение данных на уровне элемента.

Параллельно создайте другую таблицу: тег тегов не делает тег уникальным идентификатором, и если у вас заканчивается место во 2-м столбце, который содержит, скажем, 100 элементов, создайте еще одну строку.

Теперь поиск предметов по тегу будет очень быстрым.