Потенційні перешкоди на шляху модифікації даних

Навіть допускаючи, що логіка операцій абсолютно коректна, а інструкції модифікації даних насправді змінюють коректні значення, в будь-який момент все може піти під укіс У цьому розділі ми досліджуємо кілька типів потенційних проблем і знайдемо шляхи, як їх уникнути

Як показано в табл 162, інструкції INSERT і UPDATE мають більше підводних каменів, ніж інструкція DELETE, так як вставляють у таблицю дані, які повинні слідувати безлічі певних правил Інструкція DELETE тільки видаляє дані, тому й число можливих пасток невелика

Таблиця 162 Потенційні проблеми модифікації даних

Потенційна проблема

Інструкція

INSERT

Інструкція

UPDATE

Інструкція

DELETE

Тип і довжина даних

X

X

Первинний ключ

X

X

Зовнішній ключ

X

X

X

Унікальний індекс

X

X

Заборона порожніх значень і відсутність замовчувань

X

X

Перевірка обмежень

X

X

Тригер INSTEAD OF

X

X

X

Тригер AFTER

X

X

X

Неоновлювані подання

X

X

X

Вистави за параметром check

X

X

Безпека

X

X

X

Проблема типу і довжини даних

Тип і довжина стовпців даних можуть впливати на результати інструкцій INSERT і UPDATE Однією з перших перевірок, які повинні проходити нові дані, є перевірка на їх тип і довжину Часто помилка типу даних викликана відсутністю лапок або, навпаки, їх наявністю SQL Server виконує неявне (тобто автоматичне) перетворення даних Водночас перетворення, які автоматично виконуються в інших мовах програмування, можуть не спрацювати в SQL Server Наведемо показовий приклад:

USE OBXKites

INSERT Price (ProductID, Price, EffectiveDate)

Values (1DB8D8D60-76F4-46C3-90E6-A8648F63C0F01,

4500, 6/25/2002 )

Server: Msg 260, Level 16, State 1, Line 1 Disallowed implicit conversion from data type varchar

to data type money, table 1OBXKitesdboPrice 1, column 1 Price

Use the CONVERT function to run this query

Проблема в наведеному прикладі полягала в зайвих лапках, що обрамляють нове значення ціни СУБД SQL Server не здатна автоматично перетворити строкове значення в числове Якщо вам необхідно таке перетворення, скористайтеся функцією Convert () або Cast ()

Додаткова Детально про типи даних і таблицях йтиметься у розділі 17 Про перетворень-йнформацій нии типів даних і повязаних з цією операцією функції див в розділі 8

Проблеми первинного ключа

Первинні ключі можуть впливати на інструкції INSERT і UPDATE

Первинні ключі за визначенням повинні бути унікальними Спроба вставити значення первинного ключа, яке вже використовується, викличе помилку

З технічної точки зору оновлення первинного ключа вже існуючим значенням також викличе помилку Однак якщо ви прямуєте практичним вказівкам, то будете використовувати автоматично генеруються первинні ключі, які безглузді для звичайної людини і які немає ніякого сенсу оновлювати

Оновлення первинного ключа може також зруйнувати посилальну цілісність бази даних, в результаті чого інструкція UPDATE не буде виконаний Проте в даному випадку причиною збою буде не сам первинний ключ, а обмеження зовнішнього ключа, що посилається на нього

Додаткова Детально про створення первинних ключів см в главі 2 До цієї теми ми також інформація повернемося в главі 17

Одним з конкретних питань, повязаних зі вставкою, є створення первинних ключів для новий рядків SQL Server пропонує два відмінних способи генерування первинних ключів: стовпці ідентичності та глобальні універсальні ідентифікатори (GUID) Кожен з цих методів має свої переваги і недоліки, так що до їх вибору слід підходити уважно

Стовпці ідентичності являють собою генеруються сервером послідовні цілі числа Вони генеруються в ході виконання операцій вставки, і сама інструкція INSERT ніяк не може вплинути на цей процес, навіть якщо буде містити значення для стовпця ідентичності

Насправді той факт, що стовпці ідентичності відкидають поставляються їм значення, може створити серйозні проблеми, особливо якщо на такі ж значення первинного ключа вже посилаються вторинні таблиці У навчальній базі даних байок Езопа первинні ключі прошиті в інструкції INSERT в сценаріях заповнення, так як вони заздалегідь відомі в операціях перетворення даних

Рішення проблеми зводиться до використання параметра бази даних identity_insert Коли цей параметр встановлений в значення on, захист стовпця ідентичності тимчасово відключається, що дозволяє вставляти в нього свої дані У базі даних параметр identity_ insert може бути одночасно встановлений в значення on тільки для однієї таблиці Наступний пакет інструкцій SQL використовує параметр identity_insert для заповнення первинного ключа

USE CHA2

— attempt to insert into an identity column INSERT dboGuide (GuidelD, FirstName, LastName)

VALUES (10, Bill1, Fletcher)

У результаті буде отримана помилка:

Server: Msg 544, Level 16, State 1, Line 1

Cannot insert explicit value for identity column in table

‘Guide when IDENTITY_INSERT is set to OFF

Тепер встановимо параметр identity_insert і спробуємо виконати інші вставки:

SET IDENTITY_INSERT Guide On

INSERT Guide (GuidelD, FirstName, LastName)

VALUES (100, Bill, Mays)

INSERT dboGuide (GuidelD, FirstName, LastName)

VALUES (101, Sue, Atlas)

Щоб побачити, які значення тепер будуть присвоєні колонки ідентичності, знову відключимо параметр identity_insert і виконаємо ще одну вставку:

SET IDENTITY_INSERT Guide Off INSERT Guide ( FirstName, LastName)

VALUES (Arnold, Bistier)

SELECT GuidelD, FirstName, LastName FROM dboGuide

Тепер подивимося на результат:

GuidelD FirstName LastName

1Dan                   Smith

2 Jeff                    Davis

3Tammie             Commer

4 Lauren               Jones

5Greg                  Wilson

100&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp Bill         Mays

101&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp Sue         Atlas

102&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp Arnold    Bistier

Як було продемонстровано, вставка вручну ідентифікатора з номером 101 призвела до того, що наступному було присвоєно значення 102

Ще одна проблема, повязана зі стовпцем ідентичності, полягає в тому, що досить важко дізнатися щойно створений ідентифікатор Так як SQL Server генерує це значення в ході виконання інструкції INSERT, програма, що виконує вставку рядка, його не знає Сама інструкція INSERT проблем не викликає – все виявляється тоді, коли сгенерированное значення доводиться відображати в інтерфейсі користувача

SQL Server пропонує три методи отримання значення ідентифікатора

■ @ @ Identity Ця глобальна змінна повертає останнє значення стовпця ідентичності, сгенерированное сервером для таблиці, підключення або набору даних Однак якщо з моменту вашої вставки сталася ще одна помилка, то змінна @ @ identity повернеться не потрібне вам значення, а пізніший

■ scope_identity () Ця системна функція повертає останнє сгенерированное значення стовпця ідентичності в процесі виконання поточної процедури або пакета Особисто я рекомендую використовувати саме цей метод отримання останнього згенерованого значення стовпця ідентичності

■ ident_current {таблиця) Ця функція повертає останнє значення стовпця ідентичності, сгенерированное для зазначеної таблиці Незважаючи на гадану схожість з функцією scope_identity (), ця функція не враховує вставки значень ідентичності, виконані в інших таблицях Таким чином, ви отримуєте гарантовано коректний результат

Глобальні унікальні ідентифікатори GUID чудово справляються з роллю первинних ключів Їх основна відмінність від значень ідентичності полягає в тому, що вони генеруються кодом SQL або за допомогою значень стовпця за замовчуванням, а не під час виконання самої вставки Таким чином, розробник отримує більший контроль над створенням цих ідентифікаторів Якщо значення вставляється в стовпець, для якого визначено значення за замовчуванням, то проблеми не виникнуть Значення за замовчуванням використовується тільки тоді, коли в інструкції вставки для стовпця явно не вказано значення Ідентифікатори GUID можна використовувати та з інших причин, однак самою основною я вважаю простоту їх використання

Додаткова Більш докладно питання створення первинних ключів будуть розглянуті в інформація чолі 17 Там же наведено порівняльну характеристику GUID і стовпців ідентичності

Глобальні універсальні ідентифікатори створюються за допомогою функції newid () Якщо значення за замовчуванням для первинного ключа задано як NewID (), то новий ідентифікатор генерується для кожної нової рядки До того ж функція newid () може бути вказана безпосередньо у списку інструкції INSERT VALUES Ця функція буде виконуватися навіть у складі вираження інструкції INSERT SELECT, що працює з групою рядків У складі збереженої процедури або програми результат виконання цієї функції може бути збережений в змінній Згодом ця змінна може бути використана в інструкції INSERT VALUES для вставки її значення в новий рядок Будь-який з цих варіантів добре справляється зі своєю роботою, і в додатку їх можна комбінувати

Перевагою попереднього визначення GUID до виконання інструкції INSERT VALUES є те, що програма вже буде знати значення первинного ключа ще до операції вставки нового рядка Гнучкість використання глобального універсального ідентифікатора полягає в тому, що навіть якщо структура програми не допускає його попереднього визначення, то ідентифікатор, що генерується безпосередньо в інструкції вставки, впорається зі своєю роботою не гірше

У наступному прикладі продемонстровані різні методи генерування GUID для первинного ключа при вставці нових рядків у таблицю ProductCategory бази даних OBXKites У першому прикладі ми перевіримо роботу функції newid ()

USE OBXKites Select NewID()

Отримуємо наступний результат:

5 СВВ2 800-5207-4323-АЗ1б-Е 9 б 3ААСВ 6081

Наступні три запити вставляють у нові рядки GUID, використовуючи при цьому різні методи:

– GUID вставляється за замовчуванням

– (Значенням за замовчуванням для стовпця є функція NewID ())

INSERT dboProductCategory (ProductCategorylD, ProductCategoryName)

VALUES (DEFAULT, З умовчання)

– GUID вставляється функцією INSERT dboProductCategory (ProductCategorylD, ProductCategoryName)

VALUES (NewID (), З функції)

– GUID вставляється із змінної DECLARE @ NewGUID Uniqueldentifier SET @ NewGUID = NewID ()

INSERT dboProductCategory (ProductCategorylD, ProductcategoryName)

VALUES (@ NewGUID, З змінної1)

Для перегляду результатів вставки ми відфильтруем тільки ті рядки, які починаються зі слова З:

SELECT ProductCategorylD, ProductcategoryName FROM dboProductCategory

WHERE ProductcategoryName LIKE З%

Буде отримано наступний результат:

ProductCategorylD                           ProductcategoryName

25894DA7-В5ВВ-435D-954 0-6В9207C6CF8F З умовчання 393414DC-8611-4460-8FD3-4657Е4В4 9373 З функції FF868338-DF9A-4B8D-89В6-9С28293CA25F З змінної

Наступна інструкція INSERT використовує функцію newid () для вставки декількох ідентифікаторів GUID:

INSERT dboProductCategory

(ProductCategorylD, ProductcategoryName)

Select NewIDO, LastName From CHA2 dbo Guide

Наведена інструкція SELECT запрошувати нові ідентифікатори:

SELECT ProductCategorylD, ProductcategoryName FROM dboProductCategory

Тепер подивимося на результати:

ProductCategorylD                           ProductcategoryName

1B2BBE15-B415-43ED-BCA2-293050B7EFE4 Kite 23FC5D45-8B60-4800-A505-D2F556F863C9 Accessory

3&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp 88 9671A-F2CD-4B79-8DCF-19F4F4703 693 Video

5471F896-A414-432B-A57 9-0880757ED097 Fletcher 428F29B3-111B-4ECE-B6EB-E0913A9D34DC Atlas E4B7D325-8122-48D7-A61B-A83E258D8729 Bistier

SQL Server пропонує двох відмінних кандидатів на роль первинних ключів – стовпці ідентичності та GUID Те, який з них буде використовуватися, залежить від декількох факторів У будь-якому випадку у вас є кілька методів вставки нових рядків Ким би ви не були – програмістом або адміністратором бази даних, – ситуація завжди буде у вас під контролем

Проблеми зовнішніх ключів

Зовнішні ключі можуть впливати на виконання інструкцій INSERT, UPDATE і DELETE – вони можуть блокувати ці операції Вставка нового рядка вторинної таблиці, що має зовнішній ключ, який не відповідає жодному первинного, може просто не виконатися

У наступному прикладі значення ідентифікатора категорії товару (ProductCategorylD) не існує в таблиці ProductCategory У результаті обмеження зовнішнього ключа блокує виконання операції вставки:

– Зовнішні ключі: проблеми вставки INSERT Product (ProductID, Code,

ProductCategorylD, ProductName)

VALUES (9562C1A5-44 99-4626-BB33-E5E14 0ACD2AC1 ,

‘999

1DB8D8D6 0-76F4-4 6C3-90E6-A8648F63C0F0,

‘Basic Box Kite 21&quot’)

Server: Msg 547, Level 16, State 1, Line 1

INSERT statement conflicted with COLUMN FOREIGN KEY

constraint FK______ Product___ Product         7B905C751

The conflict occurred in database OBXKites, table ProductCategory, column ProductCategorylD.

The statement has been terminated

Зверніть увагу на те, що, так як ідентифікатор GUID є унікальним, в різних системах він буде генеруватися по-різному

Обмеження зовнішніх ключів можуть блокувати операції оновлення як в первинних, так і у вторинних таблицях Якщо оновлюється первинний ключ, а зовнішній вказує на старе значення, то операція завершиться помилково

У наступному прикладі операція оновлення блокується з тієї причини, що робиться спроба поновлення значення зовнішнього ключа вторинної таблиці значенням, яке не існує в первинній:

– Зовнішні ключі: проблеми оновлення вторинної таблиці

UPDATE Product

SET ProductCategorylD =

‘DB8D8D6 0-76F4-46C3-90E6-A864 8F63C0F0

WHERE ProductID = 67804443-7E7C-4769-A41C-3DD3CD3621D9

Server: Msg 547, Level 16, State 1, Line 1

UPDATE statement conflicted with COLUMN FOREIGN KEY

Constraint FK______ Product___ Product         7B905C75.

The conflict occurred in database OBXKites, table ProductCategory, column ProductCategorylD.

The statement has been terminated

Оновлення первинного ключа новим значенням, якщо зовнішній ключ вказує на нього, має той же ефект, що і видалення рядка первинної таблиці, якщо вторинна на неї посилається В обох випадках операція завершиться помилкою, і викликана вона буде обмеженнями зовнішнього ключа

У наступному прикладі помилка викликана не таблицею ProductCategory, навіть незважаючи на те, що оновлюється саме вона помилку провокує таблиця Product Таблиця Product має обмеження зовнішнього ключа, і одне з його значень тепер має посилатися на значення первинної таблиці, якого більше не існує

– Зовнішні ключі: проблеми оновлення первинної таблиці UPDATE ProductCategory SET ProductCategorylD =

‘DB8D8D60-76F4-46C3-90E6-A8648F63C0F0

WHERE ProductCategorylD =

‘1B2BBE15-B415-43ED-BCA2-2 93 050B7EFE4

Server: Msg 547, Level 16, State 1, Line 1

UPDATE statement conflicted with COLUMN REFERENCE constraint

‘FK___ Product__ Product      7B905C75. The conflict occurred

in database OBXKites, table Product, column ProductCategorylD.

The statement has been terminated

Додаткова Детально про роль посилальної цілісності при виборі зовнішніх ключів см в ^ інформація \ чолі 2 Сам процес створення зовнішніх ключів докладно описаний в главі 17

Проблеми унікальних індексів

Унікальні індекси можуть впливати на виконання інструкцій INSERT і UPDATE

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

Як правило, завершиться невдачею навіть вся транзакція, що містить операції вставки або оновлення таких рядків У той же час існує параметр ignore dup key, що дозволяє транзакціях виконуватися, забороняючи лише ті операції, які призводять до дублювання рядків

Додаткова Більш докладно про обмеження унікальних індексів ви дізнаєтеся в главах 17

^ Інформація \ і 50

Проблеми порожніх значень і значень за замовчуванням

Допустимість порожніх значень і значень за замовчуванням стовпців можуть впливати на виконання інструкцій INSERT і UPDATE

Ці інструкції можуть відправляти в таблицю одне з чотирьох можливих значень: дані, пусте значення, значення за замовчуванням або взагалі нічого У свою чергу, стовпець таблиці може бути налаштований зі значенням за замовчуванням і допустимостью порожніх значень У табл 163 описані результати операцій оновлення і вставки з урахуванням різних конфігурацій шпальти Наприклад, якщо стовпець має значення за замовчуванням і допускає порожні значення, а операція оновлення або вставки посилає порожнє значення, в результаті буде отримана помилка

Таблиця 163 Модифікація даних, значення за замовчуванням і порожні значення

Властивості стовпця

Значення за замовчуванням

Ні

Ні

Є

Є

Допустимість порожніх значень

Так

Ні

Так

Ні

Інструкція посилає

Результат

дані

Дані

Дані

Дані

Дані

null

null

Помилка

null

Помилка

Значення за замовчуванням

null

Помилка

Значення за

Значення за благаючи

замовчуванням

чанію

Нічого

null

Найбільш розпо

Значення за

Значення за благаючи

странения помилка

замовчуванням

чанію

Як ви побачили, найпоширеніша помилка відбувається, коли в стовпець нічого не надсилається, а в ньому не існує значення за замовчуванням і не допустимі порожні значення

Додаткова Детальна інформація про створення значень за замовчуванням і конфігурірова-інформація нии порожніх значень наведена в главі 17 Про роботу з порожніми значеннями при витяганні даних див у главі 8

Проблеми обмежень перевірки

Обмеження перевірки можуть вплинути на виконання інструкцій INSERT і UPDATE Кожен стовпець таблиці може мати кілька обмежень перевірки Як правило, це швидкі булеві операції, що визначають допустимість операції

У наступному прикладі встановлюється обмеження, яке відсіває осіб, які не досягли на момент прийому на роботу 21-річного віку (слід зазначити, що це обмеження вже застосовано при створенні бази даних за допомогою сценарію Create_CHA2 sql):

USE СНА2 go

ALTER TABLE dboGuide ADD CONSTRAINT

СK_Guide_Age21 CHECK (DateDiff (yy, DateOfBirth, DateHire)

&gt= 21)

У наступному запиті до бази даних вставляється інформація про екскурсовода Мері Джонсон Так як вона вже досягла 26-річного віку, вставка буде виконана:

INSERT Guide(lastName, FirstName, Qualifications, DateOfBirth,

DateHire)

VALUES (1 Johnson, Mary,

‘ER Physician, 14/1/71, 1/6/97)

На противагу цьому Грег Франклін досяг тільки 19-річного віку, і обмеження перевірки заборонить вставку його даних:

INSERT Guide (lastName, FirstName,

Qualifications, DateOfBirth, DateHire)

VALUES (Franklin, Greg,

‘Guide, 12/12/83, 1/1/2002)

Server: Msg 547, Level 16, State 1, Line 1

INSERT statement conflicted with TABLE CHECK constraint

‘CK_Guide_Age21.

The conflict occurred in database CHA2, table Guide.

The statement has been terminated

Додаткова Детально про обмеження перевірки, їх достоїнства і недоліки мова співай-«нфорглація дет в главі 17

Проблеми тригерів instead of

Тригери INSTEAD OF впливають на виконання інструкцій INSERT, UPDATE і DELETE

Тригери являють собою особливі збережені процедури, які прикріплюються до таблиці і викликаються при виконанні в ній будь-яких операцій модифікації даних Існують два типи тригерів: INSTEAD OF і AFTER Відрізняються вони часом виконання і ставленням до операції модифікації даних

Тригери INSTEAD OF виконуються замість відповідної операції при цьому сама інструкція відхиляється Ці тригери можуть замінити собою операцію, провівши її в коректній формі, також вони можуть виконати яке інше дію

Проблема тригерів INSTEAD OF полягає в тому, що вони звітують про виконання операції незалежно від того, чи було що-небудь записано в базу даних У цьому немає ніякої помилки, оскільки тригер все одно виконувався, проте це вносить певну плутанину в роботу користувачів

У наступному прикладі тригер InsteadOf Demo виконується замість інструкції вставки:

USE СНА2 go

CREATE TRIGGER InsteadOfDemo ON Guide

INSTEAD OF INSERT AS

Print Приклад тригера INSTEAD OF

Return

Наступний запит вставить зазначену в тригері тестову рядок замість фактично вказаних в інструкції даних:

INSERT Guide(lastName, FirstName,

Qualifications, DateOfBirth, DateHire)

VALUES (Jamison, Tom,

‘Biologist, Adventurer, 14/1/56, 1/9/99)

Буде отримано наступний результат:

Приклад тригера INSTEAD OF (1 row (s) affected)

Інструкція INSERT мала бути виконана, але вставила вона в таблицю рядок Перевіримо

SELECT GuidelD FROM Guide

WHERE LastName = Jamison

GuidelD

(0 row(s) affected)

Додаткова Створення тригерів буде описано в главі 23 Процес виконання транзакцій інформація модифікації даних і час запуску тригерів розглянутий у розділі 51

Слід зазначити, що в наведеному прикладі тригер InsteadOf Demo перед своїм створенням був видалений

Проблеми тригерів after

Тригери AFTER можуть впливати на виконання інструкцій INSERT, UPDATE і DELETE

Ці тригери часто використовують для здійснення складної перевірки введених даних Якщо розглянута операція вставки, оновлення або видалення НЕ буде схвалена тригером, вона буде скасована У програмі також можуть бути виконані ще які-небудь операції У той же час, якщо тригер явно не відкотить операцію, вона буде виконана, як і

передбачалося спочатку На відміну від тригерів INSTEAD OF, тригери AFTER звітують про помилку, якщо інструкція була скасована

У главі 51 ми обговоримо всі операції, неявно виконувані у транзакціях, навіть якщо вони не містить інструкції BEGIN TRANSACTION Тригери AFTER запускаються на виконання відразу ж після інструкції, але перед підтвердженням операції Таким чином, під час виконання тригера AFTER транзакція вважається відкритою

У наступному прикладі створюється тригер Af terDemo, прикріплений до таблиці Guide У цьому тригері містяться команди raiseerror і rollback transaction:

USE СНА2

CREATE TRIGGER AfterDemo ON Guide

AFTER‘INSERT, UPDATE AS

Print Приклад тригера AFTER

– Logic in a real trigger would decide what to do here RAISERROR (Приклад помилки, 16, 1)

ROLLBACK TRAN Return

В результаті застосування цього тригера до таблиці Guide результат операції вставки буде наступним:

INSERT Guide(lastName, FirstName,

Qualifications, DateOfBirth, DateHire)

VALUES (Harrison, Nancy,

‘Pilot, Sky Diver, Hang Glider,

Emergency Paramedic, 25/6/69, 14/7/2000)

Приклад тригера AFTER

Server: Msg 50000, Level 16, State 1,

Procedure AfterDemo, Line 7 Приклад помилки

Пошук рядки з даними про Ненсі Харрісон ні до чого не приведе, оскільки транзакція була скасована

Додаткова * Більш докладно тригери AFTER будуть описані в главі 23 Про додаткові інформація стратегіях створення тригерів ви дізнаєтеся в розділі 24

Слід звернути увагу, що програмний код на компакт-диску, що додається до книги, що відноситься до цієї чолі, видаляє тригер AfterDemo, щоб всі інші приклади могли працювати

Обчислювані стовпці

З неоновлювані уявленнями безпосередньо повязане питання обчислюваних стовпців – будь-яка спроба запису даних у такий стовпець приречена на невдачу

Додаткова Більш докладно про створення обчислюваних стовпців ви дізнаєтеся в розділі 17

інформація

Проблеми неоновлювані уявлень

На можливість оновлення уявлень впливає кілька факторів Найпоширенішою причиною неможливості поновлення є використання підсумкових функцій, угруповань та обєднань Якщо подання містить вкладені уявлення, хоча б одне з яких є неоновлювані, зовнішнє подання буде також неоновлювані

Подання vMedGuide, створюване в наступному прикладі, є неоновлювані, так як предикат DISTINCT виключає дублювання, що, в свою чергу, не дає можливості сервера однозначно визначити, яка саме рядок оновлюється:

CREATE VIEW dbovMedGuide AS

SELECT DISTINCT GuidelD, LastName, Qualifications FROM dboGuide

WHERE Qualifications LIKE %Aid%1 OR Qualifications LIKE %medic%

OR Qualifications LIKE 1%Physician%

Для перевірки можливості поновлення подання виконаємо наступний запит:

UPDATE dbovMedGuide

SET Qualifications = 1ER Physician, Diver

WHERE GuidelD = 1

Буде отримано наступний результат:

Server: Msg 4404, Level 16, State 1, Line 1

View or function dbovMedGuide is not updatable

because the definition contains the DISTINCT clause

Додаткова Детально про створення уявлень см в розділі 14 Там же ви знайдете пере-мнформаціі чень причин, через які неможливо оновлювати подання

Проблеми уявлень з параметром перевірки

Вистави за параметром WITH CHECK OPTION впливають на виконання інструкцій INSERT і UPDATE

Використання цього параметра може призвести до появи двох специфічних проблем Одна з них, звана проблемою зникаючих стовпців, виникає, коли оновлені стовпці більше не задовольняють критерію пропозиції WHERE Ці стовпці нікуди з бази даних не зникають, просто уявлення перестає відображати їх

Додаткова Детально про параметр with check option і проблемі зникаючих стовпців інформація см в розділі 14 Використання ролей системи безпеки буде розглянуто в главе40

Додавання в уявлення параметра WITH CHECK OPTION може викликати ще одну проблему Він впливає на виконання умови WHERE як для видобутих даних, так і для вставляються і оновлюваних Якщо дані після операцій вставки або оновлення не здатні відображатися в поданні, то параметр WITH CHECK OPTION може призвести до неможливості виконання відповідної інструкції в цілому

У наступному прикладі в згадане вже раніше уявлення додається параметр WITH CHECK OPTION, після чого виконуються дві спроби поновлення даних Перша з них задовольняє вимогам пропозиції WHERE Друга операція намагається видалити рядки з результуючого набору даних, який повернув подання, тому вона завершується невдачею:

ALTER VIEW dbovMedGuide AS

SELECT GuidelD, LastName, Qualifications FROM dboGuide

WHERE Qualifications LIKE %Aid%

OR Qualifications LIKE %medic%

OR Qualifications LIKE %Physician%1 WITH CHECK OPTION

Наступні запити тестують видозмінене уявлення Перший з них виконується, оскільки містить кваліфікацію Physician другий завершується помилкою:

UPDATE dbovMedGuide

SET Qualifications = ER Physician, Diver1

WHERE GuidelD = 1

UPDATE dbovMedGuide

SET Qualifications = Diver

WHERE GuidelD = 1

Server: Msg 550, Level 16, State 1, Line 1 The attempted insert or update failed because the target view either specifies WITH CHECK OPTION or spans a view that specifies WITH CHECK OPTION and one or more rows resulting from the operation did not qualify under the CHECK OPTION constraint

The statement has been terminated

Проблеми системи безпеки

Питання безпеки можуть впливати на виконання інструкцій INSERT, UPDATE і DELETE

До неможливості виконання інструкції може призвести безліч налаштувань системи безпеки і ролей Зазвичай питання безпеки не піднімаються на етапі створення програми Однак, як тільки база даних запускається в промислову експлуатацію, захист даних часто виходить на перший план Документування налаштувань безпеки і ролей допоможе вам вирішити більшість проблем, повязаних із захистом даних

Додаткова Більш докладно про систему безпеки і ролях ми поговоримо в розділі 40

інформація

Більшість проблем модифікації без праці можуть попередити програмісти і адміністратори баз даних, якщо вони тільки розуміють систему роботи SQL Server, документують базу даних, знайомі зі схемою бази, з збереженими процедурами і тригерами

Резюме

Витяг і модифікація інформації є основними завданнями додатків роботи з базами даних У цьому розділі ми розглянули інструкції мови DML INSERT, UPDATE і DELETE, а також питання їх блокування в базі даних

На цьому ми завершуємо вивчення інструкцій DML, яким присвятили десяток глав У наступних розділах ми приступимо до завдань програмування і проектування баз даних в SQL Server за допомогою T-SQL, CLR і нової архітектури, орієнтованої на служби

Джерело: Нільсен, Пол Microsoft SQL Server 2005 Біблія користувача : Пер з англ – М: ООО ІД Вільямс , 2008 – 1232 с : Ил – Парал тит англ

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*