Это зависит от вашего двигателя. Мудрость заключается в том, что чтение является дешевым, несколько байтов здесь и там не окажут существенного влияния на производительность базы данных малого и среднего размера.
Что еще более важно, это зависит от использования, к которому вы положите первичный ключ. Целочисленные сериалы имеют то преимущество, что они просты в использовании и реализации. Они также, в зависимости от конкретной реализации метода сериализации, имеют то преимущество, что их можно быстро получить , поскольку большинство баз данных просто хранят серийный номер в фиксированном месте, а не извлекают его Select max(ID)+1 from fooна лету.
Возникает вопрос: как 5-символьный ключ представляет «значимую ценность» для вас и для приложения? Как создается это значение и занимает ли оно больше или меньше времени, чем поиск инкрементного серийного номера. Хотя в некоторых целых числах сэкономлено тривиальное количество места, подавляющее большинство систем будет игнорировать эту экономию пространства.
Это не влияет на производительность, за исключением того, что схема персонажей требует, чтобы никогда не было автоматического движка, поскольку ваши «ключи» недостижимы. Для вашего конкретного домена не беспокойтесь о искусственных ключах, а просто используйте китайские, японские и тайские имена ключей. В то время как вы не можете гарантировать уникальность любого возможного приложения, в вашей области гораздо разумнее использовать их вместо ужасных и принудительных сокращений из 5 символов. Существенного влияния на производительность не будет, пока вы не получите миллионы кортежей.
В качестве альтернативы, если вы просто отслеживаете по стране происхождения, а не по конкретным региональным кухням (кантонская, сычуаньская, сицилийская, умбрийская, калабрийская, юкатеканская, оахаканская и т. Д.), Вы всегда можете просто использовать коды ISO 3166 .
Если у меня есть 10 000 рецептов, разница между 5-символьной и 20-символьной клавишей не начинает увеличиваться?
Пространство дешево . Когда вы говорите 10 000 000 рецептов, над которыми вы выполняете операции OLAP, тогда, возможно. С 10 тысячами рецептов вы получаете 150 тысяч места.
Но опять же, это зависит. Если у вас много миллионов записей и вы выполняете соединения с ними, то имеет смысл денормализовать поиск чего-то такого тривиального (в материализованное представление). Для всех практических целей относительная эффективность соединения на современном компьютере между 5-символьным ключом и ключом переменной длины настолько похожа, что она идентична. К счастью, мы живем в мире обильных процессоров и обильных дисков. Противные - это слишком много объединений и неэффективность запросов, а не посимвольное сравнение. При этом всегда проверяйте .
P & T вещи этого уровня настолько зависимы от базы данных, что обобщения чрезвычайно сложны. Создайте две примерные модели базы данных, заполните их предполагаемым количеством записей, а затем посмотрите, какая из них быстрее. По моему опыту, длина символа не имеет большого значения по сравнению с хорошими показателями, хорошими конфигурациями памяти и другими важными элементами настройки производительности.