Использование 1-значных кодов VS описательных строк для ENUM в базе данных? - PullRequest
1 голос
/ 23 мая 2011

В моей таблице user_accounts есть поле с именем source, которое является ENUM. Это указывает, как пользователь был направлен на сайт. Возможные значения: через Facebook, по электронной почте или через обычную регистрацию на сайте.

Существует 3 возможных варианта сохранения этих значений в базе данных:

  • Как полная строка, т.е. facebook, email , website

  • в виде 1-буквенного кода, например, F, E, W

  • в виде 1-значного кода, например, 1, 2, 3

Какой подход является лучшим подходом с точки зрения производительности / поддержки базы данных? Будет ли какое-либо влияние (например, более быстрые запросы), если я сохраню значения в виде буквенно-цифровых кодов, а не полных строк? Этот столбец будет использоваться в WHERE выражениях.

Ответы [ 3 ]

2 голосов
/ 23 мая 2011

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

Однако, как говорится, ENUM - беспорядок в использовании. Если в будущем вы решите что-то изменить, это трудно изменить. Кроме того, если вы передадите неверные данные, если у вас нет строгого SQL, вы просто получите NULL в этом поле. Вы также не можете добавить другие атрибуты к данным ENUM, такие как, являются ли они активными или унаследованными и т. Д. Наконец, гораздо труднее напрямую использовать информацию ENUM в ваших приложениях (например, заполнение раскрывающегося меню с помощью ваших вариантов ENUM). ).

Вот хороший SO вопрос по этой теме:

Тип MySQL ENUM против таблиц объединения

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

2 голосов
/ 23 мая 2011

С точки зрения производительности, ENUMS действительно стремятся к наиболее оптимизированным (поскольку система знает возможный набор значений, она использует различные алгоритмы при поиске и т. Д. И т. Д.).Вы можете сохранить полную строку с помощью ENUMS ('FACEBOOK' и т. Д.), И они будут занимать только 1 байт пространства на строку!(при условии, что всего менее 256 перечислений).Однако используйте перечисления, только если вы точно знаете, что F, E, W - единственные опции, которые вы увидите.Добавление новых ENUMS является трудной задачей, так как вам придется изменить таблицу, чтобы обновить значения перечисления, и вам нужно будет обеспечить порядок перечисления.

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

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

2 голосов
/ 23 мая 2011

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...