Свойство Identity

  • Автор темы 17dufa
  • Дата начала
Статус
Закрыто для дальнейших ответов.
1

17dufa

#1
привет всем!
может кто подскажет как программно снять/установить свойство identity у столбца?
 
1

17dufa

#3
MS SQL SERVER 2000
я знаю, что это мона сделать в enterprise manager, но хотелось бы узнать как это делать с помощью SQL запроса
Почти наверняка это ALTER TABLE, но вот, что после этих 2 слов писать, я не знаю
 
B

Barmutik

#6
Гммм.. как показало глубокое вскрытие ... такого сделать с помощью T-SQL нельзя... по крайней мере в MS SQL Server ...

Проанализировав то что делает Enterprise Manager выяснилось ...

1. Создаётся новая таблица где у поля IDENTITY есть или нет
2. Копируются данные из основной таблицы
3. Удаляется основная таблица
4. Переименовывается вновь созданная в таблицу с нужным именем


Так что ... только так Вам и надо делйствовать ...

Мда .. не ожидал что такая проблема так решается ...
 
B

Barmutik

#7
Или как вариант создать новую колонку с нужным вам идентити, потом скопировать в ней данные от старой колонки и потом старую колонку удалить... но это вариант сродни перемещению всех данных в таблице ...
 
1

17dufa

#8
Спасибо огромное за такой развернутый ответ
тогда напрашивается другой вопрос: все это я хотел затеять только потому, что таблица моя будет достаточно интенсивно испытывать операции вставки/удаления, и как следствие, я хотел бы обезопасить себя от переполнения автоинкрементного столбца, делать я это собирался так: снять автоинкремент, сделать нечто вроде update table set column = column - 10000, установить автоинкремент. Может есть другое решение этой проблемы(переполнение)?
 
B

Barmutik

#9
А как насчёт использовать ROWGUID ? Проблема переполнения не страшна :D
 
1

17dufa

#10
Все таки использование свойства identity позволяет отслеживать хронологию поступления сообщений, поэтому я написал пользовательскую функцию:
CREATE FUNCTION countJur
()
RETURNS int
AS
BEGIN
DECLARE @res int
SELECT @res = MAX(id)
FROM JUR

if( @res = NULL )
RETURN( 0 )
RETURN ( @res )
END
и использую ее следующим образом:
insert into JUR(id,type,_time,param) values (dbo.countJur()+1,@type,@_time,@param)
это позволяет создать иллюзию использования identity но не накладывает ограничений на необходимый update, хотя конечно интересно что более затратно: использование этой функции или же копирование значений столбца identity для update
 
1

17dufa

#11
Все таки использование свойства identity позволяет отслеживать хронологию поступления сообщений, поэтому я написал пользовательскую функцию:
CREATE FUNCTION countJur
()
RETURNS int
AS
BEGIN
DECLARE @res int
SELECT @res = MAX(id)
FROM JUR

if( @res = NULL )
RETURN( 0 )
RETURN ( @res )
END
и использую ее следующим образом:
insert into JUR(id,type,_time,param) values (dbo.countJur()+1,@type,@_time,@param)
это позволяет создать иллюзию использования identity но не накладывает ограничений на необходимый update, хотя конечно интересно что более затратно: использование этой функции или же копирование значений столбца identity для update
 
1

17dufa

#12
Есть еще одно решение данной проблемы: заводится таблица, которая хранит максимальный Id всех необходимых таблиц (для который нужно сымитировать свойство identity) Эта таблица имеет формат MaxId INT, TableName VARCHAR(...). Перед помещением новой записи в какую-либо таблицу, нужно вызвать функцию, которая сгенерирует значение столбца якобы имеющего свойство Identity. Функция принимает как параметр имя таблицы, по этому имени обращается в созданную таблицу, берет оттуда данные и модифицирует таблицу, после чего возвращает необходимое значение.
 
B

Barmutik

#13
Если уж такое дело то кто мешает перед вставкой делать SELECT MAX от ключевого поля + 1 .. и дополнительной таблицы заводить не придётся ...
 
1

17dufa

#14
насчет предложения Barmutik, это я сначала и сделал, но предложение о дополнительной таблице представляется более правильным с точки зрения производительности, так как эта таблица небольшая и много места не займет, не займет много времени и поиск требуемого элемента, а вот выбор максимального либо будет требовать много времени, либо надо будет завести для этого поля индекс, тогда соответсвенно этот вариант потребует много памяти. Так что предложение о дополнительной таблице хоть и менее тривиально, по размышлении кажется более грамотным
 
B

Barmutik

#15
Стоп... судя по всеу мы говорим о ключевом поле .. а для этого поля автоматом строится индекс.. так что поиск максимального значения будт выполняться прямом переходм .. что равнозначно нулевым временным затратам...

А вот Ваш вариант .. особенно при большом количестве таблиц наоборот проигрывает в производителености потому как искать приходится по строковому значению.. если конечно по нему не построен индекс ...
 
Статус
Закрыто для дальнейших ответов.