Оптимизация базы данных: что быстрее поиск по целым числам ИЛИ коротким строкам?

Question

Меня интересует вопрос о базовом дизайне базы данных / типе данных.

У меня есть таблица porjects с полем с именем «experience_required». Я знаю, что это поле всегда будет заполняться одним из следующих вариантов: стажер, младший, старший или директор. Этот список может немного меняться с течением времени, но я не ожидаю кардинальных изменений в предметах на нем.

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

Answer 1

Вам может понравиться это поле, проиндексированное. Однажды проиндексированные Integer и маленькая строка Char не имеют большой (ничтожно малой разницы) производительности.

Answer 2

Определенно используйте Integer для String.

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

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

Это будет гораздо более сильный дизайн и будет более щадящим в случае, если вы измените доступные уровни опыта или решите переименовать уровень опыта.

Подробнее о нормализации можно прочитать здесь .

Answer 3

Не имеет значения.Разница будет незначительной.Какая разница будет в пользу выбора целого числа, но это один из немногих случаев, когда я предпочитаю короткий текстовый ключ, поскольку во многих ситуациях создания отчетов он сохраняет JOIN обратно в таблицу поиска.

Answer 4

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

Answer 5

Целые. Строки должны ИМХО использоваться только для хранения текстовых данных (имен, адресов, текста и т. Д.).

Кроме того, целые числа в этом случае лучше для сортировки, хранения и обслуживания.

Answer 6

Чтобы мутить воду, я предложу смесь.Начните с идеи @ GregSansom (upvoted), но вместо целых используйте тип данных CHAR(1) со значениями I, J, S и D. Это даст вам ту же производительность, что и tinyint, и даст дополнительное преимущество простогопомнить мнемонику, когда (если) работает напрямую с данными.С небольшим количеством использования легко помнить, что «S» означает «старший», тогда как 3 не несет никакого встроенного значения - особенно если, как вы предлагаете, дополнительные значения добавляются со временем.(Добавьте «Испытательный», скажем, 5, и парадигма «низкий ранг = низкое значение» отсутствует в окне.)

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

Конечно, что если это последовательные значения?Конечно, звучит так, как здесь.В этом случае не делайте их 1,2,3,4, делайте их 10, 20, 30, 40, чтобы вы могли вставить новые классификации позже.Это также позволит вам легко реализовать диапазоны, такие как «все <30» (что означает «меньше, чем« старший »)». </p>

Я предполагаю, что моя главная мысль такова: знать ваши данные, как они будут использоваться, каксо временем оно может измениться или будет меняться, и соответственно планировать и кодировать!