Объясните способ хранения тегов БД

Question

из этого поста Какой самый эффективный способ хранения тегов в базе данных?

Было рекомендовано хранить таблицы тегов следующим образом.

Table: Item
Columns: ItemID, Title, Content

Table: Tag
Columns: TagID, Title

Table: ItemTag
Columns: ItemID, TagID

И еще один пост ТАК сказал то же самое. Может кто-нибудь объяснить, почему теги должны храниться так? Я предполагаю, что ItemID это какой-то внутренний val, title это имя тега (c ++, sql, noob и т. Д.) контент - это любые другие данные, которые я хочу сохранить с моим товаром. почему не что-то вроде

Table: Item
Columns: ItemID, Title, <more data i want>

Table: TagList
Columns: ItemID, Title

заголовок в элементе - «имя элемента», а заголовок тега - «c ++», «sql», «noob», «etc»

Answer 1

Нет ничего плохого во втором изображенном вами дизайне, с таблицей TagList, за исключением того, что он занимает больше места.

То есть, если вы помечаете 10 000 элементов тегом «database-design», то в схеме с двумя таблицами вы должны хранить эту строку 10 000 раз. Если эффективность использования пространства более важна, вы можете использовать трехсторонний дизайн, который будет хранить только 4-байтовый целочисленный идентификатор для «дизайна базы данных» 10000 раз. Экономия 10 * 10000 байт.

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

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

И, наконец, если вам обычно требуется список уникальных тегов, более быстрый запрос таблицы Tags в схеме с тремя таблицами, вместо необходимости SELECT DISTINCT tag FROM TagList каждый раз, когда вам нужен уникальный список. И последний дает вам только список используемых тегов , а не список всех подходящих тегов.

Answer 2

Почему? Это нормализовано. ItemID будет первичным ключом (возможно, суррогатом или идентификатором), TagID почти наверняка будет суррогатом / идентификацией, а для ограничений / производительности у вас будут уникальные ограничения и / или индекс (возможно, даже кластеризованный в tag.title).

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