Какая причина использовать последовательности в базах данных?

80
9

Я новичок в DB/Hibernate и нашел код:


@SequenceGenerator(name = "entSeq", allocationSize = 5, sequenceName = "CODE_SEQ")
...
@Id
@GeneratedValue(strategy = GenerationType.SEQUENCE, generator = "entSeq")

которые устанавливают последовательность для первичного ключа.

Почему были использованы последовательности для значений первичного ключа? Какие цели были решены:

    повысить производительность добавить ограничения, некоторые проверки ограничение допустимого диапазона значений целочисленных значений ID, зачем это делать? зачем начинать считать с 1?

Я прочитал о синтаксисе и использовании в:

но не нашел ответа на мой вопрос.

ОБНОВИТЬ:

Мне понравилось читать:

где показано, что в теории БД есть проблема, как получить уникальный идентификатор для первичных ключей. Это означает, что я могу вставлять в таблицу без предоставления значения для первичного ключа из моего собственного:


INSERT INTO suppliers
(supplier_id, supplier_name)
VALUES
(supplier_seq.nextval, 'Kraft Foods');

Но я ожидаю, что эта функция должна присутствовать во всей БД, не заставляя меня предоставлять значения первичного ключа...

Думаю, правильно?

UPDATE2:

Ответ за использование START WITH:

Этот раздел может быть полезен при добавлении последовательностей в существующие базы данных. Когда более старая схема использовалась приложением и уже использовала некоторые значения из правового диапазона, это предложение может использоваться для пропуска этих потребляемых значений. MINVALUE и MAXVALUE используются для указания правового диапазона, но START WITH инициирует использование последовательности в этом диапазоне, чтобы ранее созданные значения не появлялись снова.

UPDATE3: * последовательности * предоставляют http://en.wikipedia.org/wiki/Surrogate_key

спросил(а) 2021-01-19T15:06:21+03:00 9 месяцев назад
1
Решение
65

Исторически сложилось две основные причины.

    Избегайте проблем с производительностью с помощью UPDATE CASCADE в больших таблицах. Избегайте проблем с производительностью при подключении к широким естественным клавишам.

Oracle даже не поддерживает ON UPDATE CASCADE, поэтому обновление значения, используемого в ссылках на внешние ключи, более проблематично, чем на других платформах.

Эти "проблемы" производительности в настоящее время гораздо менее серьезны, чем 20 лет назад, с учетом таблиц одинакового размера. (Теперь оборудование намного быстрее.) Но мы, похоже, сейчас занимаемся гораздо большими столами, чем 20 лет назад.

Есть некоторые нежелательные побочные эффекты для такого рода настройки производительности.

    Вам обычно требуется гораздо больше объединений, чем вы могли бы с тщательно подобранными естественными клавишами и ON UPDATE CASCADE. Вам может потребоваться так много, что соединения более дороги, чем чтение диска. Легче заблудиться в соединениях, когда у вас есть 20 или 30 из них. Строки сложнее понять. (Строка, которая читает {1, 7, 13, 255, 438}, сложнее понять, чем строка, читающая {1, библиотека, checkout, 255, "Книга - ваш друг"}.) Часто разработчик базы данных назначает идентификационный номер в качестве первичного ключа, но не устанавливает никаких других ограничений UNIQUE. Это делает идентификационный номер идентификатором строки, а не идентификатором реального мира, который представляет строка. Это может быть большой проблемой.

ответил(а) 2021-01-19T15:06:21+03:00 9 месяцев назад
46

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

ответил(а) 2021-01-19T15:06:21+03:00 9 месяцев назад
Ваш ответ
Введите минимум 50 символов
Чтобы , пожалуйста,
Выберите тему жалобы:

Другая проблема