Как спроектировать таблицу, которой нужен только столбец?

Question

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

В настоящее время у меня нет ничего связанного с каждым тегом (и явероятно, никогда не будет), поэтому моя идея заключалась в том, чтобы иметь что-то вроде

Tags (Tag(pk) : string)

Должен ли это быть способ сделать это?Или я должен вместо этого сделать что-то вроде

Tags (tag_id(pk) : int, tag : string)

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

Спасибо

Answer 1

Я бы пошел на второй вариант с суррогатным ключом.

Это будет означать, что таблица занимает больше места, но, вероятно, уменьшит пространство над всеми, если предположить, что у вас есть информация тега как внешний ключ в других таблицах (например, таблица posts / tags)

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

Answer 2

Вы должны пойти на второй вариант. Во-первых, вы никогда не знаете, что нас ждет в будущем. Во-вторых, позже вам может понадобиться поддержка нескольких языков или другие вещи, которые вызывают странные ощущения у строки-первичного ключа. В-третьих, мне нравится идея использования стандартной процедуры для определения таблицы, т.е. что всегда есть столбец «id» или «pk». Это отделяет бизнес от технологий.

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

Я бы не стал особо подчеркивать проблему производительности. Как только программа начинает общаться с базой данных через Интернет, у вас гораздо большая задержка, чем у 99% всех запросов вашей базы данных (конечно, за исключением отчетов о запросах!).

Answer 3

Индексы работают лучше с целыми числами, чем CHAR / VARCHAR, идут с выделенным целочисленным столбцом первичного ключа.Если вам нужно, чтобы имена тегов были уникальными, вы можете добавить ограничение, но, вероятно, оно не стоит хлопот.

Answer 4

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