Создание смешанного числа и буквы первичного ключа

Question

У меня есть база данных рабочего стола, которую я воспроизводю на сервере MySQL. В текущей базе данных есть таблица клиентов, а одно из полей представляет зоны или зоны, которые обслуживает компания. Зоны являются следующими: 1А, 1В, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12,13,14,15,16,17.

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

Проблема в том, что зоны "1A" и "1B" не позволяют мне установить первичный ключ int в таблице customer_zones. Я должен использовать varchar (2) в качестве первичного ключа. Это хорошая практика? или лучшее решение?

Answer 1

Первичный ключ - это кластеризованный индекс, а физическое представление данных в таблице обусловлено тем, что первичный ключ и поиск по номерам быстрее, чем строки.

Согласно вашему случаю ниже приведены подходы.

Подход A

Если вы выберете идентификатор зоны как varchar(2) для поля первичного ключа в таблице customer_zones, тогда вы можете сослаться на это поле внешнего ключа в таблице customer, и ваша проблема будет решена.

Подход B

Если вы будете использовать первичный ключ как integer в таблице customer_zone, то для хранения зон, таких как 1A, 1B и т. Д., Вам нужно иметь еще одно поле, и в этом поле вам потребуется уникальный ключ, также избегайте Дублирование данных.

Было бы лучше, если бы вы следовали подходу А, поскольку одно ограничение было бы проще для той же функциональности.

Answer 2

Я утверждаю в пользу PRIMARY KEY(zone) и VARCHAR(2), а не суррогатного AUTO_INCREMENT:

• Количество строк, затронутых запросом, является гораздо большим фактором производительности, чем детали арифметики / сравнения строк / функций / и т. Д.
• Даже при миллионах строк «числа быстрее строк» ​​вряд ли будут заметны.
• Если переход на суррогат включает дополнительные JOIN, то есть дополнительные издержки.
• Удобнее (при просмотре данных вручную) видеть «1А», «16» и т. Д.
• Я нахожу, что 2 раза из 3 я использую «натуральный» PRIMARY KEY, а не «суррогат» (AUTO_INCREMENT). Для таблицы сопоставления многие: многие использование составного ПК вместо суррогата является явно более эффективным.

Я бы предложил в вашем случае эту незначительную оптимизацию:

 VARCHAR(2) CHARACTER SET ascii

это позволяет избежать незначительных накладных расходов на utf8.

Я привожу аналогичные аргументы для GUID, UUID, sha1, md5, ip_address, кода страны, почтового индекса, номеров почтовых индексов и т. Д. Для полей с действительно фиксированной длиной, таких как двухбуквенный код страны, используйте CHAR(2) вместо VARCHAR(2) .