Справка по SQL

[code] [int] IDENTITY(1,1) PRIMARY KEY ,

[model] [varchar] (4) NOT NULL ,

[color] [char] (1) NOT NULL ,

[type] [varchar] (6) NOT NULL ,

[price] [float] NOT NULL )

Автоинкрементируемое поле определяется посредством конструкции IDENTITY (1, 1). При этом первый параметр свойства IDENTITY (1) определяет, с какого значения начнется отсчет, а второй - какой шаг будет использоваться для приращения значения. Таким образом, в нашем примере первая вставленная запись будет иметь в столбце code значение 1, вторая - 2 и т.д.

Поскольку в поле code значение формируется автоматически, оператор

INSERT INTO Printer_Inc VALUES (15, 3111, 'y', 'laser', 2599);

приведет к ошибке, даже если в таблице нет строки со значением в поле code, равным 15. Поэтому для вставки строки в таблицу просто не будем указывать это поле точно так же, как и в случае использования значения по умолчанию, т.е.

INSERT INTO Printer_Inc (model, color, type, price)

VALUES (3111, 'y', 'laser', 2599);

В результате выполнения этого оператора в таблицу Printer_Inc будет вставлена информация о модели 3111 цветного лазерного принтера, стоимость которого равна $2599. В поле code окажется значение, которое только случайно может оказаться равным 15. В большинстве случаев этого оказывается достаточно, т.к. значение автоинкрементируемого поля, как правило, не несет никакой информации; главное, чтобы оно было уникальным.

Однако бывают случаи, когда требуется подставить вполне конкретное значение в автоинкрементируемое поле. Например, нужно перенести уже имеющиеся данные во вновь создаваемую структуру; при этом эти данные участвуют в связи "один-ко-многим" со стороны "один". Таким образом, мы не можем допустить тут произвола. С другой стороны, нам не хочется отказываться от автоинкрементируемого поля, т.к. оно упростит обработку данных при последующей эксплуатации базы данных.

Поскольку стандарт языка SQL не предполагает наличия автоинкрементируемых полей, то соответственно не существует и единого подхода. Здесь мы покажем, как это реализуется в MS SQL Server. Оператор

отключает (значение ON) или включает (OFF) использование автоинкремента. Поэтому чтобы вставить строку со значением 15 в поле code, нужно написать

SET IDENTITY_INSERT Printer_Inc ON;

INSERT INTO Printer_Inc(code, model, color, type, price)

VALUES (15, 3111, 'y', 'laser', 2599);

Обратите внимание, что список столбцов в этом случае является обязательным, т.е. мы не можем написать так:

SET IDENTITY_INSERT Printer_Inc ON;

INSERT INTO Printer_Inc

VALUES (15, 3111, 'y', 'laser', 2599);

ни, тем более, так

SET IDENTITY_INSERT Printer_Inc ON;

INSERT INTO Printer_Inc(model, color, type, price)

VALUES (3111, 'y', 'laser', 2599);

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

Важно отметить, что если значение 15 окажется максимальным в столбце code,то далее нумерация продолжится со значения 16. Естественно, если включить автоинкрементирование: SET IDENTITY_INSERT Printer_Inc OFF.

Наконец, рассмотрим пример вставки данных из таблицы Product в таблицу Product_Inc, сохранив значения в поле code:

SET IDENTITY_INSERT Printer_Inc ON;

INSERT INTO Printer_Inc(code, model,color,type,price)

SELECT * FROM Printer;

По поводу автоинкрементируемых столбцов следует еще сказать следующее. Пусть последнее значение в поле code было равно 16, после чего строка с этим значением была удалена. Какое значение будет в этом столбце после вставки новой строки? Правильно, 17, т.к. последнее значение счетчика сохраняется, несмотря на удаление строки, его содержащей. Поэтому нумерация значений в результате удаления и добавления строк не будет последовательной. Это является еще одной причиной для вставки строки с заданным (пропущенным) значением в автоинкрементируемом столбце.

Оператор UPDATE

Оператор UPDATE изменяет имеющиеся данные в таблице. Команда имеет следующий синтаксис

UPDATE

SET {имя столбца = {выражение для вычисления значения столбца

| NULL

| DEFAULT},...}

[ {WHERE }];