Блог

Главная - Вопросы по программированию - Предупреждающее сообщение для ограничения первичного ключа

Предупреждающее сообщение для ограничения первичного ключа

#sql #primary-key #composite-primary-key

#sql #первичный ключ #составной первичный ключ

Вопрос:

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

  1. Но он выдает предупреждающее сообщение, поскольку Warning! The maximum key length is 900 bytes. The index 'pk_hrempid' has maximum length of 1530 bytes.For some combination of large values, the insert/update operation will fail я узнал, что это будет серьезной проблемой в будущем для вставки данных. Есть ли решение для этого предупреждения?

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

Любая помощь приветствуется!

Комментарии:

1. Было бы интересно узнать определения типов данных столбцов, которые привели к этой ошибке.

2. Сложно отлаживать код SQL DDL, который мы не видим 😉 Не стесняйтесь, публикуйте имена атрибутов, типы данных и примеры данных. Возможно, здесь вы найдете кого-то, кто разбирается в вашей области бизнеса и может указать вам направление на стандартный отраслевой ключ или другой надежный источник идентификаторов.

3. @Widor.. Спасибо за подсказку.. У всех моих типов данных был nvarchar по умолчанию (255) (поскольку я увеличил размер из access), который слишком длинный для данных в столбцах, я изменил типы данных для столбцов первичного ключа, тогда для первичного ключа нет предупреждения! Должен ли я изменять типы данных для всех других столбцов (которые также имеют небольшие данные по сравнению с nvarchar) … или можно оставить как есть?

Ответ №1:

Хотя из вашей попытки использования составного первичного ключа звучит, что вы пытаетесь использовать наилучшую практику использования «естественного ключа», нет ничего «неправильного» в использовании автоматически увеличивающегося ID поля.

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

Не забудьте принять во внимание возможные оптимизации, выбрав хорошие индексы и подходящие типы данных для таблиц, которые будут подвергаться интенсивным запросам.

Комментарии:

1. Я предполагаю, что вы хотели сказать: «Нет ничего»неправильного» в использовании суррогатного ключа в дополнение к естественному ключу …» (в сторону: я бы не согласился), но проблема здесь в том, что СУБД не может применять естественный ключ.

2. @OTTA Я должен уточнить это словами «если естественный ключ возможен» или «если естественный ключ может быть первичным ключом». То есть, если и «естественный», и «суррогатный» являются небольшими, числовыми и индексируемыми, тогда каждый раз используйте «естественный».

3. Спасибо всем за предложение. Если я добавлю значение автоматического увеличения в качестве первичного ключа для всех сотрудников во всех таблицах, я думаю, это приведет к путанице.. не так ли?

4. @user939615 Да, вы только добавляете автоматическое увеличение ID в Employee таблицу. Любая таблица, которая также ссылается на это ID , будет иметь тот же тип данных, но не автоматически увеличивающийся, и может иметь FOREIGN KEY отношение к Employee .

Ответ №2:

  1. Это ограничение первичного ключа. Вы не можете иметь PK больше 900 байт.

  2. Вы можете добавить столбец идентификатора в таблицу и установить его в качестве первичного ключа. Я предпочитаю использовать идентификаторы Guid, поскольку они глобально уникальны.

Комментарии:

1. 1. Наверняка это ограничение SQL Server? 2. это не предотвратит дублирование в существующих трех столбцах.

Ответ №3:

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