Унаследованная проблема с базой данных SQL Server

Question

Я унаследовал базу данных SQL Server, которая по какой-то странной причине разработчики не использовали Identity для автоматического увеличения первичного ключа. (может быть, когда-то это был Oracle, кто знает).

Теперь, ... поскольку к базе данных обращаются бесчисленные клиенты, я предполагаю, что "следующий идентификатор" должен где-то храниться в БД, чтобы они не конфликтовали друг с другом. Если я пытаюсь добавить запись вручную, она работает, но затем, когда клиент создает запись, он терпит неудачу, говоря, что ключ уже используется.

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

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

Answer 1

Если для вставки используются хранимые процедуры, то, вероятно, там.

Answer 2

проверьте information_schema.constraint_column_usage для таблицы, на которую ссылаются все остальные с внешним ключом.

Answer 3

Запустите трассировку и найдите вставку, чтобы увидеть, явно ли передается идентификатор от клиента. Если нет, и нет никаких проблем, проверьте наличие триггера на этой таблице.

Answer 4

Как быть, если вы запустили сеанс SQL Server Profiler (при условии, что вы используете SQL Server 2005+)? Этот инструмент покажет запросы, выполняемые приложением. Если следующий идентификатор действительно хранится в таблице в базе данных, вы должны увидеть запрос на доступ к нему при запуске или непосредственно перед вставкой записи. Вы также должны увидеть следующий идентификатор обновляется после вставки. Если вы не видите ничего из этого, возможно, вы все равно получите некоторые ценные подсказки.

Answer 5

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

Если вы измените его на использование Identity (и, честно говоря, если это сработает, я бы предпочел сделать это, чем использовать GUIDS), и вам нужно вернуть это значение для вставки в дочерние таблицы, то убедитесь, что вы используете scope_identity ( ), чтобы вернуть только что введенное вами значение идентификатора, а не @@ identity.

Answer 6

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

Answer 7

Я видел пару таких систем.

• У одного была таблица с автоматическим номером, которая использовалась бы для определения личности в каждой таблице. Это использовалось, чтобы гарантировать, что каждый объект имел различный идентификатор.

• Другой проект был задан чем-то вроде: выберите max (id) +1 из таблицы. Не спрашивай меня почему;)

Answer 8

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