Насколько медленный DISTINCT?

Question

У меня есть возможность написать два разных формата для структуры базы данных:

Article
-------
ArticleID int FK

Article_Tags
------------
ArticleTagID int FK
ArticleID int FK
TagText varchar(50)

или

Article
-------
ArticleID int PK

Article_Tags
------------
ArticleTagID int PK
ArticleID int FK
TagText varchar(50) FK

Tag
---
TagText varchar(50) PK

Если я хочу получить список всех тегов в базе данных, я мог бы использовать:

select distinct tagtext from article_tags

или

select tagtext from tag

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

Answer 1

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

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

Answer 2

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

Было бы достаточно просто проверить это обоими способами, если вы действительно беспокоитесь об этом, но из моего большого опыта нет сомнений, что это правда.

Answer 3

Чтобы ответить на основной вопрос из заголовка: a DISTINCT обычно означает сортировку данных. В зависимости от индексов, структура запроса и объем возвращаемых данных могут быть бесплатными (правильный индекс для tagtext, ORDER BY tagtext, небольшой набор возвращаемых данных) или нет (отсутствующий индекс, порядок не имеет значения, массивный набор возвращаемых данных).

Answer 4

Я бы пошел с

Article
-------
ArticleID int PK

Article_Tags
------------
ArticleTagID int PK
ArticleID int FK
TagId int FK

Tag
---
TagId int identity(1,1) PK
TagText varchar(50) 

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

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

Производительность, если любой из 3 вариантов будет работать примерно одинаково при условии правильного индексирования.

Answer 5

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

Первый запрос даст вам уникальный список всех используемых в настоящее время тегов.

Второй запрос предоставит вам все возможные теги, которые можно использовать, включая те, которые еще не использовались.

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