Проектирование архитектуры базы данных тегов T-SQL?

Question

Сценарий

Я строю базу данных, которая содержит ряд различных таблиц. Они состоят из таблицы COMMENTS, таблицы BLOGS и таблицы ARTICLES. Я хочу иметь возможность добавлять новые элементы в каждую таблицу и отмечать их тегами от 0 до 5, чтобы помочь пользователю легче находить нужную информацию.

Начальные мысли для архитектуры

Моими первыми мыслями было иметь централизованную таблицу TAGS. В этой таблице будут перечислены все доступные теги с использованием поля TagID и поля TagName. Поскольку у каждого элемента может быть много тегов, а у каждого тега может быть много элементов, мне потребуется отношение MANY-TO-MANY между каждой таблицей элементов и таблицей TAGS.

Например:

Многие комментарии могут иметь много тегов. Многие теги могут иметь много комментариев.

Многие СТАТЬИ могут иметь много тегов. Многие теги могут иметь много статей.

и т.д .....

Текущее понимание

Из предыдущего опыта я понимаю, что одним из способов реализации этой структуры в T-SQL является объединение таблицы между таблицей COMMENTS и таблицей TAG. Эта объединяющая таблица будет содержать CommentID и TagID, а также собственный уникальный CommentTagID. Эта структура также будет применяться ко всем остальным предметам.

Вопросы

Во-первых, это правильный путь для реализации такой архитектуры базы данных? Если нет, то какие другие методы были бы возможны? Поскольку база данных в конечном итоге будет содержать много информации, я должен обеспечить ее масштабируемость. Это масштабируемая реализация? Если бы у меня было много этих таблиц, эта архитектура сделала бы операции CRUD очень медленными? Должен ли я использовать GUID или инкрементные INT для полей идентификаторов?

Помощь и предложения будут высоко оценены.

Thankyou.

Answer 1

Вы также можете посмотреть схему WordPress и описание базы данных , чтобы увидеть, как другие решают подобную проблему.

Answer 2

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

1. Создайте полный список всех тегов (то есть, теги блога, теги комментариев и теги статьи)
   • Обновите теги так, чтобы они обновлялись повсеместно: чтобы при изменении sqlserver на sql-server оно менялось где угодно: в блогах, статьях и комментариях.

Опция 1 очень полезна для создания облаков тегов, поэтому я рекомендую создать таблицу тегов и ссылаться на нее из ваших таблиц.

Если вам никогда не потребуется обновлять теги, как описано в варианте 2, вам никогда не понадобится суррогатный ключ для них.

Скорее всего, вам все равно понадобится ограничение UNIQUE, и нет смысла не делать его PRIMARY KEY, если вы не собираетесь их обновлять.

Это также сэкономит вам много объединений: вам не нужно объединяться с таблицей тегов, чтобы показать теги.

GUIDs более прост в управлении, но они делают индексы и таблицы ссылок достаточно большими по размеру.

Вы можете присваивать числовой идентификатор каждой таблице и ссылаться следующим образом:

tTag (tag VARCHAR(30) NOT NULL PRIMARY KEY)

tTaggable (type INT NOT NULL, id INT NOT NULL, PRIMARY KEY (type, id))

tTagLink (
        tag VARCHAR(30) NOT NULL FOREIGN KEY REFERENCES tTag,
        type INT NOT NULL, id INT NOT NULL,
        PRIMARY KEY (tag, type, id),
        FOREIGN KEY (type, id) REFERENCES tTaggable
        )

tBlog (
        id INT NOT NULL PRIMARY KEY,
        type INT NOT NULL, CHECK(type = 1),
        FOREIGN KEY (type, id) REFERENCES tTaggable,
        …)

tArticle (
        id INT NOT NULL,
        blog INT NOT NULL FOREIGN KEY REFERENCES tBlog,
        type INT NOT NULL, CHECK(type = 2),
        FOREIGN KEY (type, id) REFERENCES tTaggable,
        …)


tComment (
        id INT NOT NULL PRIMARY KEY,
        article INT NOT NULL FOREIGN KEY REFERENCES tArticle,
        type INT NOT NULL, CHECK(type = 3),
        FOREIGN KEY (type, id) REFERENCES tTaggable,
        …)

Обратите внимание, что если вы хотите удалить блог, статью или комментарий, вы должны удалить также из tTaggable.

Таким образом, tTaggable используется только для обеспечения ссылочной целостности. Чтобы запросить все теги для статьи, вы просто выполните этот запрос:

SELECT  tag
FROM    tTagLink
WHERE   type = 2
        AND id = 1234567

, поэтому все теги можно получить, запросив одну таблицу без каких-либо объединений.

Answer 3

обычно отношения многие ко многим реализуются именно так, как вы это описываете.

Автоинкрементные идентификаторы - это хорошая идея, поскольку они гарантируют, что они будут уникальными.

И вы можете использовать направляющие, если хотите пометить комментарии и статьи одним и тем же тегом (вместо 6 таблиц вам нужно всего 5). Но поиск по гидам может быть более медленным.