-
Познакомьтесь с пентестом веб-приложений на практике в нашем новом бесплатном курсе
- Статус
MS SQL SERVER 2000
я знаю, что это мона сделать в enterprise manager, но хотелось бы узнать как это делать с помощью SQL запроса
Почти наверняка это ALTER TABLE, но вот, что после этих 2 слов писать, я не знаю
я знаю, что это мона сделать в enterprise manager, но хотелось бы узнать как это делать с помощью SQL запроса
Почти наверняка это ALTER TABLE, но вот, что после этих 2 слов писать, я не знаю
Гммм.. как показало глубокое вскрытие ... такого сделать с помощью T-SQL нельзя... по крайней мере в MS SQL Server ...
Проанализировав то что делает Enterprise Manager выяснилось ...
1. Создаётся новая таблица где у поля IDENTITY есть или нет
2. Копируются данные из основной таблицы
3. Удаляется основная таблица
4. Переименовывается вновь созданная в таблицу с нужным именем
Так что ... только так Вам и надо делйствовать ...
Мда .. не ожидал что такая проблема так решается ...
Проанализировав то что делает Enterprise Manager выяснилось ...
1. Создаётся новая таблица где у поля IDENTITY есть или нет
2. Копируются данные из основной таблицы
3. Удаляется основная таблица
4. Переименовывается вновь созданная в таблицу с нужным именем
Так что ... только так Вам и надо делйствовать ...
Мда .. не ожидал что такая проблема так решается ...
Или как вариант создать новую колонку с нужным вам идентити, потом скопировать в ней данные от старой колонки и потом старую колонку удалить... но это вариант сродни перемещению всех данных в таблице ...
Спасибо огромное за такой развернутый ответ
тогда напрашивается другой вопрос: все это я хотел затеять только потому, что таблица моя будет достаточно интенсивно испытывать операции вставки/удаления, и как следствие, я хотел бы обезопасить себя от переполнения автоинкрементного столбца, делать я это собирался так: снять автоинкремент, сделать нечто вроде update table set column = column - 10000, установить автоинкремент. Может есть другое решение этой проблемы(переполнение)?
тогда напрашивается другой вопрос: все это я хотел затеять только потому, что таблица моя будет достаточно интенсивно испытывать операции вставки/удаления, и как следствие, я хотел бы обезопасить себя от переполнения автоинкрементного столбца, делать я это собирался так: снять автоинкремент, сделать нечто вроде update table set column = column - 10000, установить автоинкремент. Может есть другое решение этой проблемы(переполнение)?
Все таки использование свойства 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
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
Все таки использование свойства 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
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
Есть еще одно решение данной проблемы: заводится таблица, которая хранит максимальный Id всех необходимых таблиц (для который нужно сымитировать свойство identity) Эта таблица имеет формат MaxId INT, TableName VARCHAR(...). Перед помещением новой записи в какую-либо таблицу, нужно вызвать функцию, которая сгенерирует значение столбца якобы имеющего свойство Identity. Функция принимает как параметр имя таблицы, по этому имени обращается в созданную таблицу, берет оттуда данные и модифицирует таблицу, после чего возвращает необходимое значение.
Если уж такое дело то кто мешает перед вставкой делать SELECT MAX от ключевого поля + 1 .. и дополнительной таблицы заводить не придётся ...
насчет предложения Barmutik, это я сначала и сделал, но предложение о дополнительной таблице представляется более правильным с точки зрения производительности, так как эта таблица небольшая и много места не займет, не займет много времени и поиск требуемого элемента, а вот выбор максимального либо будет требовать много времени, либо надо будет завести для этого поля индекс, тогда соответсвенно этот вариант потребует много памяти. Так что предложение о дополнительной таблице хоть и менее тривиально, по размышлении кажется более грамотным
Стоп... судя по всеу мы говорим о ключевом поле .. а для этого поля автоматом строится индекс.. так что поиск максимального значения будт выполняться прямом переходм .. что равнозначно нулевым временным затратам...
А вот Ваш вариант .. особенно при большом количестве таблиц наоборот проигрывает в производителености потому как искать приходится по строковому значению.. если конечно по нему не построен индекс ...
А вот Ваш вариант .. особенно при большом количестве таблиц наоборот проигрывает в производителености потому как искать приходится по строковому значению.. если конечно по нему не построен индекс ...
- Статус
Обучение наступательной кибербезопасности в игровой форме. Начать игру!