Функция автоматического приращения в базе данных
Я использую SQL Server, и когда я создаю новую таблицу, я делаю определенное поле автоматическим приращением первичный ключ. Проблема в том, что некоторые люди сказали мне, что сделать поле автоматическим приращением для первичного ключа означает, что при удалении любой записи (их не волнует номер поля автоматического приращения) поле увеличивается, поэтому в какой - то момент - если тип моего поля целочисленный, например-диапазон целого числа будет потребляться полностью, и я буду в беде. Поэтому они говорят мне не использовать эту функцию больше.
лучшее решение-сделать это через код, получив максимум моего первичного ключа, тогда, если значение не существует, max будет 1 иначе max + 1.
любые предложения по этой проблеме? Можно ли использовать функцию auto increment?
Я также хочу знать случаи, которые не предпочтительны для использования автоматического приращения ..и альтернативы...
Примечание: этот вопрос вообще не относится к любой СУБД , я хочу знать это верно также для СУБД ,таких как ORACLE,Mysql, INFORMIX....
спасибо.
5 ответов
вы должны использовать столбцы identity (auto increment). The bigint тип данных может хранить значения до 2^63-1 (9,223,372,036,854,775,807). Я не думаю, что ваша система скоро достигнет этого значения, даже если вы вставляете и удаляете много записей.
Если вы реализуете метод, который вы предлагаете правильно, вы получите много проблемы с блокировкой. В противном случае, вам придется иметь дело с исключения из-за нарушение ограничения (или еще хуже - не уникальные значения, если нет ограничения первичного ключа).
An int тип данных в SQL Server может содержать значения от -2,147,483,648 до 2,147,483,647.
если вы засеиваете свой столбец идентификаторов с -2,147,483,648, например FooId identity(-2,147,483,648, 1) тогда у вас есть более 4 миллиардов значений, чтобы играть.
если вы действительно думаете, что этого все еще недостаточно, вы можете использовать bigint, который может содержать значения от -9,223,372,036,854,775,808 до 9,223,372,036,854,775,807, но это почти гарантированно будет перебор. Даже при больших объемах данных и / или большое количество транзакций, вы, вероятно, либо закончится дисковое пространство или исчерпать срок службы вашего приложения, прежде чем исчерпать значения идентификаторов при использовании int, и почти наверняка при использовании bigint.
чтобы суммировать, вы должны использовать столбец идентификаторов, и вы не должны заботиться о пробелах в значениях, так как а) у вас достаточно значений-кандидатов и Б) это абстрактное число без логического значения.
если вы должны были реализовать решение, которое вы предложите, чтобы код, выводящий следующий столбец идентификаторов, учитывал параллелизм, поскольку вам придется синхронизировать доступ к текущему максимальному значению идентификатора между двумя конкурирующими транзакциями. Действительно, Вы можете привести к значительному снижению производительности, так как вам придется сначала прочитать максимальное значение, вычислить и затем вставить (не говоря уже о дополнительной работе, связанной с синхронизацией параллельных транзакций). Однако если используется столбец идентификаторов, параллелизм будет обрабатываться для вас Database engine.
продолжайте использовать функцию идентификации с ПК в SQL Server. В mysql также есть функция автоматического приращения. Не волнуйтесь, что у вас закончится целочисленный диапазон, у вас закончится место на жестком диске, прежде чем это произойдет.
решение, которое они предлагают, может и, скорее всего, создаст проблему параллелизма и/или проблему масштабируемости. Если в двух сеансах используется описанная вами техника Max, они могут получить одно и то же число, а затем попытаться добавить его одновременно. Это создаст нарушение ограничений.
вы можете обойти эту проблему, заблокировав таблицу или поймав исключения и продолжая повторную вставку.. но это очень плохой способ делать вещи. Замок будет уменьшите производительность и вызовите проблемы масштабируемости (и если вы планируете столько записей, чтобы беспокоиться о переполнении int, вам понадобится масштабируемость).
поля идентификаторов являются атомарными операциями. Два сеанса не могут создать одно и то же поле идентификатора, поэтому эта проблема не существует при его использовании.
Если вас беспокоит, что поле идентификатора может переполниться, используйте более крупный тип данных, например bigint. Вам будет трудно создать достаточно записей, чтобы перелив это.
теперь есть веские причины не использовать поле идентификатора, но это не один из них.
Я бы посоветовал не использовать Identity / Auto-increment, потому что:
его реализация нарушена в SQL server 2005/2008. подробнее
Это не хорошо работать, если вы собираетесь использовать ORM для базы данных с объектами. подробнее
Я бы посоветовал вам использовать генератор Hi / Lo, если вы обычно получаете доступ к своей базе данных через программу и не зависите от отправки вставьте инструкции вручную в БД. Подробнее об этом вы можете прочитать во второй ссылке.