Могу ли я использовать нечисловой первичный ключ для таблицы MySQL?

В моем веб-приложении пользователь может определить документы и дать им уникальное имя, которое идентифицирует этот документ и дружественное имя, которое человек будет использовать для ссылки на документ. Возьмут следующую схему таблицы в качестве примера:Могу ли я использовать нечисловой первичный ключ для таблицы MySQL?

| id | name  | friendly_name | 
----------------------------------------------- 
| 2 | invoice-2 | Invoice 2  |

В этом примере я использовал id столбец в качестве первичного ключа, который является номером авто инкрементации. Так как это уже естественный идентификатор документов (name) Я мог бы также сделать это:

| name  | friendly_name | 
-------------------------------------- 
| invoice-2 | Invoice 2  |

В этом примере name является первичным ключом документа. Мы удалили поле id, поскольку оно по сути является всего лишь дубликатом name, так как каждый документ в таблице должен иметь уникальный name в любом случае.

Это также означает, что когда я ссылаюсь на документ из отношения внешнего ключа, я должен был бы назвать его document_name, а не document_id.

Какова наилучшая практика в отношении этого? Теоретически для меня вполне возможно использовать VARCHAR для первичного ключа, но он подходит для любых недостатков, таких как служебные служебные данные?

источник

2014-09-28 John Dorean

В чем преимущества? – Mihai

Преимущество состояло бы в том, что у меня есть меньше столбцов в таблице, которые в противном случае были бы просто дублирующими данными. –

Как бы вы увеличили это? Триггеры? Проблемы могут возникать.JOINs на varchar медленнее, чем на int.Larger size table.Larger index.Просто несколько вещей, чтобы думать. Также это может вас заинтересовать http: //en.wikipedia. org/wiki/Natural_key – Mihai

На эту тему есть две школы мысли.

Есть те, кто придерживается убеждения, что использование «естественного ключа» в качестве первичного ключа для таблицы сущности желательно, поскольку оно имеет значительные преимущества перед суррогатным ключом.

Другие, которые считают, что ключ «суррогатного» может предоставить некоторые желательные свойства, которые может быть «естественным» ключом.

Давайте подведем некоторые из наиболее важных и желательных свойств первичного ключа:

минимальное - наименьшее возможное число атрибутов
простой - родной типы данных, в идеале один столбец
недоступно - значение всегда будет доступно, когда объект будет создан
уникальный - абсолютно нет дубликатов, без двух строк никогда не будет одинакового значения
анонимных - несет нет скрытых «смысла» информация
неизменны - однажды назначено, он будет никогда быть изменен

(Есть некоторые другие свойства, которые могут быть перечислены, но некоторые из этих свойств могут быть получены из свойств выше (не равно нулю, могут быть проиндексированы и т.д.)

я нарушу две школы мысли о «естественных» и «суррогатных» ключи, как «лучших» первичных ключей в два лагеря:

1) Те, кто был плохо сожжен более ранним решением избрать естественный ключ в качестве первичного ключа, и

2) Те, кто еще не был сожжен этим решением.

источник

2014-09-28 21:24:50 spencer7593

Вы забыли третий «лагерь»: те, кто успешно используют естественные ключи, когда они имеют смысл, и используют сгенерированные ключи, когда это необходимо. –

@a_horse_with_no_name: что «имеет смысл», учитывая сегодняшнюю спецификацию, часто может оказаться проблемой при изменении спецификации в следующем году, когда мы уже интегрированы с другой системой, которая теперь имеет зависимость от неизменности первичного ключа в нашей системе , Естественный ключ редко удовлетворяет всем трем из этих желаемых свойств одновременно: «анонимность», «доступность» и «неизменность». (Если он доступен, мы часто обнаруживаем, что он не является неизменным.Если он доступен и неизменен, мы часто обнаруживаем, что он не анонимный. – spencer7593

@a_horse_with_no_name: несколько десятилетий назад я работал над переписыванием системы, которая использовала " естественный ключ "в качестве первичного ключа, при моделировании отношений с сущностью было обнаружено, что естественный ключ, который был выбран разработчиками несколько лет назад, на самом деле не был уникальным, он был« обычно »уникален.Пользователи приняли механизм для решения этого вопроса, назначив «фиктивный» естественный ключ, а затем, когда печатный отчет вышел из системы, они сделали записи в печатном отчете, они написали в реальном натуральном ключе. Когда было сделано предложение, чтобы исправить это, пользователи были в восторге от удивления. – spencer7593

Конечно, вы можете.

create table sometbl(
`name` varchar(250) NOT NULL PRIMARY KEY, 
`friendly_name` varchar(400) 
);

Время доступа к целому или varchar (если его слишком длинный) ключ не имеет никакого значения. Даже если это произойдет, это не будет вашим основным узким местом. Пока столбец объявлен как ключ, mysql может получить к нему доступ очень быстро.

Автоинкрементное целое не может быть первичным ключом. Его просто серийный номер для строки. Когда вы посмотрите на реальный объект, вы увидите, что у него нет серийного номера. Поэтому первичный ключ должен основываться на этих реальных свойствах.

источник

2014-09-28 19:27:43

Я знаю, я * могу *, мне было интересно, если это лучшая практика с естественным идентификатором, и если есть какие-то недостатки. :) –

'id' никогда не должен быть PK. ПК должен быть получен из реального объекта. –

О, дорогая, эта скучная дискуссия будет запущена и запущена – Strawberry

Могу ли я использовать нечисловой первичный ключ для таблицы MySQL?

ответ

Смежные вопросы