Является ли функция генерации первичных ключей базы данных надежной?

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

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

Итак, мой вопрос: могу ли я полагаться на эту функцию автоматического генерации ключей?

Не было бы проблем, если бы различные пользователи одновременно записывали записи?

источник

2010-02-22 Yatendra Goel

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

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

источник

2010-02-22 19:17:47

Вы можете, однако, полагаться на last_insert_id, поскольку это относится к последнему вставленному идентификатору по этому соединению. – Erik

+1 спасибо ...... –

Эрик, это SQL Server или MySQL? Марк, транзакции не имеют к этому никакого отношения ... уровень изоляции определит, может ли транзакция считаться грязной или нет. –

Что вы подразумеваете под "надежным"?

Базы данных используют блокировки.

В базе данных нет «одновременно». Ресурсы заблокированы, а доступ на запись сериализуется.

Что вы спрашиваете? Пожалуйста, уточните «надежный» в своем вопросе.

источник

2010-02-22 19:17:18

Разговорный, как инженер-программист с многолетним опытом. :) –

S.Lott, мне не нравится твой тон. Я думаю, что довольно ясно, что означает OP, и вопрос тоже не плох. –

@Terry Спасибо Терри за две вещи: 1. Угадай мой опыт, не зная моего прошлого ..... 2. Для того, чтобы сказать всем, что программисты с меньшим опытом не могут задавать вопросы ... 3. Ваш опыт отражен от ваши SO points ... lol ... Есть много-2 лучших и опытных профессионала в SO, которые верят в ответы на вопросы, не публикуя бесполезные комментарии, такие как ваши ... Если вы не знаете ответов, пожалуйста, не публикуйте фида комментарии ... –

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

источник

2010-02-22 19:18:31 dsolimano

Коэффициенты заключаются в том, что любой метод, который вы использовали для создания уникальных ключей по своему усмотрению, был бы менее надежным, чем встроенный в СУБД! – Jay

Я хотел бы добавить еще одну вещь, чтобы иметь в виду при использовании auto_inc особенность MySQL:

Представьте, что вы есть таблица employees, которая использует auto_inc и (по любой причине) вторую таблицу с именем former_employees. Давайте еще раз притворимся, что каждый сотрудник будет иметь уникальный идентификатор (следовательно, auto_inc), прикрепленный к нему, и что он даже не потеряет его из-за увольнения или увольнения.

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

Теперь вот снимок из двух таблиц (не против маленьких идентификаторов сейчас):

employees      former_employees 
------------------------  ------------------------ 
id | name | ...   id | name | ... 
------------------------  ------------------------ 
27 | Peter | ...   29 | Andrew | ... 
28 | Jacko | ...   30 | Dennis | ... 
32 | Paula | ...   31 | Lenny | ... 
           33 | JoDon | ...

Обратите внимание, что former_employees последний ID равен 33 и employees auto_inc счетчик равен 34 прямо сейчас.

Если бы выключит сервер на этом этапе и перезапустить его, employees auto_inc бы отпрыгнуть до 33 !!! Это потому что MySQL не хранит счетчик auto_inc между перезапусками!

Помните об этом. С уважением.

PS: Чтобы обойти эту «функцию», вам придется запускать хранимые процедуры, которые смотрят на последний идентификатор former_employees и устанавливают, если больше.

Примечание (S.Leske): Это относится к таблицам InnoDB, но не к таблицам MyISAM. Не знаю о других настольных двигателях.

источник

2010-02-22 19:54:40 aefxx

Вы указали очень важный момент для рассмотрения ... спасибо за усилия –

Добро пожаловать. Это прослушивало меня один раз в течение целой недели. – aefxx

-1 Я не могу воспроизвести это и считаю, что это неправильно. Я просто попробовал (создать таблицу с auto_increment, вставить некоторые значения, удалить некоторые, перезапустить сервер), а MySQL делает * не * повторно использовать значения.Кроме того, если вы «mysqldump» в таблице, CREATE TABLE в дампе содержит фрагмент «AUTO_INCREMENT = 5», т. Е. MySQL * делает * внутренне хранит последний идентификатор autoinc, который он использовал. – sleske

Вы спрашиваете, возможно ли получить дубликат ключа в столбце IDENTITY, который не имеет уникального ограничения? Да, это возможно (при этом потребность в DBCC CHECKIDENT RESEED), хотя вероятность низкая. Я имел это случается со мной в нескольких случаях с SQL Server за последние несколько десятилетий. Единственный способ надежно гарантировать, что любое поле будет уникальным, - использовать уникальное ограничение (или ограничение первичного ключа).

источник

2010-02-22 21:15:29 Thomas

Кстати, если семя IDENTITY перепуталось, и оно имеет ограничение ограничения или первичного ключа и пытается использовать уже существующее значение, вы, очевидно, получите нарушения ограничений (т. Е. Исключения будут быть отброшены к пользователям). – Thomas

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

Существует одна оговорка: вы можете вставить повторяющиеся значения в столбец, если вы вставляете их явно (если СУБД позволяет явно устанавливать значение столбца autoinc, что наиболее важно). Это может показаться тривиальным, но вы можете настроить «бомбы замедленного действия», если вы (случайно) вставляете явное значение в столбец autoinc, который больше, чем текущий идентификатор autoinc.

Это будет работать нормально, пока счетчик autoinc не достигнет значения, которое вы вставили, затем «стрела» (то есть нарушение ограничения).

Это может произойти, например. если вы копируете записи из другой базы данных или восстанавливаете резервную копию. У нас возникла проблема с нашими системами, и теперь они обычно «ресинхронизируют» счетчики автоконтактов: после «опасного» обновления, такого как копирование всего БД, мы извлекаем самое большое значение, которое используется для каждого столбца autoinc, и устанавливаем счетчик autoinc на значение +1.

источник

2010-02-22 23:53:40 sleske

Является ли функция генерации первичных ключей базы данных надежной?

ответ

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