Оправдано ли использование строкового первичного ключа?

Question

[ZmeuSnake]

Например есть таблица, хранящая каталог автомобилей. Оправдано ли будет сделать первичным ключем гос.номер, т.е. , допустим, поле nchar(6)? А если нет, то в каких случаях это бывает оправдано? Тут ведь и избавляемся от интового поля с автоинкрементом, и не надо делать дополнительно проверок на уникальность номера.
Как скажется использование строкового pk на производительности?

Comments

[Дмитрий]

На производительности не скажется. Но количество возможных проблем при желании поменять ключ, или при внезапном незапланированном появлении дубликатов как правило превышает выгоды от кажущейся простоты.
В более общем случае рекомендую почитать обсуждения на тему суррогатного vs естественного ключа.
Спойлер - большинство обсуждающих за суррогатные.
Для того чтобы грамотно и аргументированно использовать естественные (читай строковые) значения в качестве ключа - должно совпасть очень много условий. Поэтому лучше перестраховаться и использовать обычные int или guid.
Кстати, не совсем понятна фраза о избавлении от intс автоинкрементом? чем он мешает?

Answer 1

[Станислав Макаров]

Оправдано ли будет сделать первичным ключем гос.номер, т.е. , допустим, поле nchar(6)?

Оправдано, если а) поле фиксированной длины - неважно, строка это или число; б) вы действительно уверены в том, что значения будут уникальны, в том числе во времени. Есть предметные области, где это действительно так, но далеко не везде.
Если строка переменной длины, первичным ключом её лучше не делать, но можно сделать полнотекстовой поиск по ней, если он нужен.

Для СУБД небольшая строка фиксированной длины (напр, 12 байт) - все равно что большое число, особой разницы в общем-то нет. А вот строки переменной длины как правило хранятся иначе, в отдельной области, а в самой записи ставится указатель. Все это, разумеется, удорожает запросы.

Comments

[wadeg]

Переменная длина тут вообще не при чем. Это в какой же СУБД такая экзотика с отдельной областью хранения для varchar'ов? В MSSQL и Oracle, разумеется, не так (вы с блобами перепутали?)

И полнотекстовый поиск тут ну вообще ни при чем, это совсем-совсем другая пепяка. Не стоит плодить и без того чудесные мифы про удорожание запросов столь причудливым образом :)

[Станислав Макаров]

wadeg Воистину перепутал с BLOB, посыпаю голову пеплом:). Просто у меня много дискуссий на счет них было последнее время (BLOB vs файловая система)..

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

Запросы на вставку/обновление с полем переменной длины будут дороже однозначно, т.к. записи также будут переменной длины и сложнее поддерживать карту свободного места. Либо придется делать компрессию время от времени (тут нужно про конкретную СУБД говорить). Хотя, если записи не удаляются и не обновляются, тогда без разницы)

[wadeg]

Станислав Макаров: Это называется like или поиск подстроки, и это все к полнотекстовому поиску никакого отношения не имеет. Записи и так обычно переменной длины хотя бы потому, что null-значения в строках не хранятся, никаких дополнительных сложностей от этого не бывает вообще и никто специально для обслуживания карты памяти" для этого ничем подобным не занимается, хватит уже наворачивать одну чепуху на другую.

[Станислав Макаров]

wadeg Ну за Оракл говорить не буду, но вот в Постгресе есть такая процедура, как VACUUM, и время от времени ее проводить бывает полезным (если было много удалений и есть много "мертвых" кортежей).

Это называется like или поиск подстроки, и это все к полнотекстовому поиску никакого отношения не имеет.
Под полнотекстовым поиском я понимаю индекс для поиска в середине, такой, по которому можно искать LIKE '%str', где обычное B-дерево не поможет. Я не про морфологию, операторы и/или и прочие высокоуровневые навороты.

[Freeman]

wadeg: В Oracle varchar2 всё же хранятся отдельно, но прозрачно для программиста: блок данных бьется на две части, в одной хранятся табличные строки (rows), в другой — varchar2. Начиная с Oracle 10 или 11 varchar2-ы могут перемещаться в другой блок, если в текущем не хватает места. В предыдущих версиях varchar2 мигрировали в другой блок вместе с табличными строками.

Answer 2

[Армянское Радио]

1. Никуда не годится. Ключ должен быть числом, это раз. Это влияет на производительность.
2. Допущение об уникальности номеров автомобилей - мрак. Вполне возможна ситуация, когда появятся две машины с одинаковым номером, просто одна из них 100500 лет назад снята с учета.

Comments

[Илья Т.]

обоснуйте п.1 пожалуйста

[Армянское Радио]

Илья Т.: Процессору проще сравнивать числа, нежели строки. Особенно, если требуется не просто сравнение строк бит-в-бит, а, например, регистронезависимое сравнение, или сравнение, нечувствительное к кодировке.

[wadeg]

Армянское Радио: А теперь все же поставьте реальный опыт, чтобы статистически значимо уловить разницу в производительности всего запроса.

[Армянское Радио]

wadeg: На какой базе? На каких данных? На каком железе?

Чувство морального удовлетворения от доказательства "в интернете кто-то не прав" (или от приобретенного опыта "вот оно что бывает, Михалыч, база X настолько интересная, что ключ по числу у нее такой же тормозной, как и ключ по строке), затраты времени и электроэнергии мне не компенсирует.

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

[wadeg]

Армянское Радио: Т.е. ложные советы раздавать интереснее с точки зрения компенсации чего-то нескомпенсированного? Ну ок, не смею мешать.

Answer 3

[trevoga_su]

не правильно. автомобильный номер - не уникален.
в 2013 я пошел в ГИБДД, заплатил 2000 руб и на новую машину поставить свой старый гос номер

Answer 4

[wadeg]

Если строковый ключ не слишком широкий, то он гораздо лучше использования "фальшивого" PK. На производительность вставок/джойнов в пределах реальной погрешности НЕ влияет: не нужно слушать тех, кто когда-то прочел эту байку, достаточно самому поставить нехитрый опыт с реальной средней шириной записи. Единственное ограничение тут - возможное переиспользование ключа, но если этого не допускается, как в данной задаче - так и нужно делать.

Comments

[Freeman]

Могу дополнить: типичный пример натурального строкового ключа — коды ISO стран, валют, языков и т. п. Они фиксированы по длине, читабельны и уникальны.

Answer 5

[Константин Цветков]

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

Оправдано, но гос. номер не определяет сущность (автомобиль). Возможно определяет VIN, но это нужно определять по предметной области. Использование суррогатного ключа (обычно автоинкрементное число, хотя может быть всё, что угодно, например, uniqueidentifier 0E984725-C51C-4BF4-9960-E1C80E27ABA0) избавляет от необходимости искать (и понимать его уникальность) естественный ключ.