@Graf_Nosferatu

Есть таблицы с первичным ключом тип: int
Добавляя новые данные пользователь может:
- либо сам ввести ключ
- либо база сама должна его сгенерировать

Моя реализация:

При росте таблицы растёт и время генерации, так при количестве записей около миллиона на генерацию данным способом требуется примерно 12 секунд.
Есть ли какие либо способы ускорить этот процесс?

0

@Humanitis

А чем Identity не устраивает?

0

@canopen

А зачем вам позволять пользователю самому вводить ключ? И что будет если он введет ключ который уже используется? Создали бы IDENTITY поле и все дела. Инкрементировался бы он у вас автоматически и все дела.

0

@Graf_Nosferatu

Долго объяснять, но суть в том, что в обычной ситуации ключ вводится автоматом (генерируется). Однако бывают случаи когда ключ должен быть указан явно. Так же в какой-то момент он может изменится. Может я конечно, что-то делаю не правильно, но с Identity такой вариант использования не проходит (ругается на явно указанные значения).
Если не трудно наставьте на путь истинный?)

0

@canopen

То есть алгоритм будет такой:

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

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

И разумеется, никаких циклов.

1

@Аватар

При многопользовательской работе это в общем случае не гарантирует правильность создания ключей. Я выбрал и до INSERT-а (даже если он идет вслед за моей выборкой) сосед успел выбрать тот же максимальный ключ.

1

@canopen

Для этого как раз и существуют транзакции, уровни изоляции, блокировка таблиц и т.д.

0

@Humanitis

http://msdn.microsoft.com/en-u... 88059.aspx

1

@Graf_Nosferatu

И ещё вопрос. Что будет когда значение поля с Identity примет максимально допустимое значение?

0

@iap

Тут требуется монопольная блокировка на чтение до конца транзакции.
Значит все выстроятся в очередь перед этим бутылочным горлышком.
Плохо! Очень плохо!

Вот тут гляньте: Организация пользовательских счетчиков (генераторов) в Microsoft SQL Server

В MS SQL 2012 появилась CREATE SEQUENCE
Тоже не без недостатков подход, конечно...

1

@Oila

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

0

@iap

Представьте, что эту же кнопку в этот же момент нажали ещё 100 человек

0

@Oila

А кто еще может нажать эту кнопку если запись новая(!), т.е. только предполагается к вводу данным пользователем и ни для кого другого её просто нет?!
Если же производится корректировка записи, например, как сформулировано в условиях примера заглавного поста, для ручного ввода уникального идентификатора, то блокировать запись на изменение(но не на чтение) кем-либо другим - норма и здесь проверки на корректность введенного вручную уникального идентификатора и его в апдейт в записи также требуют минимального времени определяемого только быстродействием системы (не раздумьями оператора) ибо только на этот краткий момент будет ставится полная локировка.
Обе ситуации при этом не мешают кому-либо иному в то же время добавлять как новые записи, так и редактировать старые.

0

@Аватар

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

0

@iap

Какая разница?

0