|
su.dbms
- SU.DBMS ----------------------------------------------------------------------
From : Dmitry V. Liseev 2:5020/400 23 Jun 2003 21:08:09
To : All
Subject : Целостность данных. Как обеспечить?
--------------------------------------------------------------------------------
Hi,All!
Вот проблемка возникла. Предположим, есть
низкоуровневая целостность данных, типа
ссылочной целостности или уникального индекса.
Ее сервер сам отслеживает, т.к. он на это рассчитан.
Предположим есть такой констрейн:
CREATE TABLE MyTable (
Name VARCHAR(50) NOT NULL UNIQUE
);
Первый юзер говорит:
INSERT INTO MyTable(Name) VALUES("Name 1")
но транзакцию пока не коммитит.
Второй юзер говорит:
INSERT INTO MyTable(Name) VALUES("Name 1")
и вот тут сервер должен подождать, пока первый
юзер не завершит свою транзакцию (или коммит
или откат), прежде чем что-то делать дальше.
Другая ситуация:
Первый юзер говорит:
DELETE FROM MyTable WHERE Name="Name 1"
но транзакцию пока не коммитит.
Второй юзер говорит:
INSERT INTO MyTable(Name) VALUES("Name 1")
и вот тут сервер опять должен подождать.
Аналогично со ссылочной целостностью:
CREATE TABLE Folder (
id INTEGER NOT NULL PRIMARY KEY
);
CREATE TABLE Document (
id INTEGER NOT NULL PRIMARY KEY,
Folder_id INTEGER REFERENCES Folder(id) ON UPDATE CASCADE ON DELETE
CASCADE
);
Пусть есть Folder с полем id=25 и есть Document
с полями id=57, Folder_id=25
Первый юзер говорит:
DELETE FROM Document WHERE id=57
но транзакцию пока не коммитит.
Второй говорит:
DELETE FROM Folder WHERE id=25
и вот тут сервер опять должен подождать.
С этим все понятно, т.к. сервер знает об этих
констрейнах и сам блокирует операции.
Hо что делать, если логика требует целостности,
на которую сервер не рассчитан?
Простейший пример: требуется, чтобы в таблице
TABLE_A была как минимум одна запись. То есть
нужно написать триггер BEFORE DELETE, который
проверял бы количество записей, и если там всего
одна, то не удалял бы ее.
Предположим, в таблице две записи и два пользователя
начали транзакции по удалению записей. Первый видит
две записи, поэтому удаляет одну, но транзакцию пока
не завершает. Второй тоже видит две записи и удаляет
другую. Когда оба коммитятся, не остается ни одной
записи, т.е. триггер не помог, т.к. пользователи не видят
результатов незакоммиченных транзакций.
Если пользователи видят результаты незакоммиченных
транзакций, то это опять не помогает: была одна запись,
первый юзер вставил вторую запись, но не закоммитился. Второй
юзер видит, что записей две, решает первую запись удалить
и закоммитить. И тут вдруг первый юзер свою транзакцию
откатывает.
Как обычно такие вещи делают? Предположим,
на InterBase 6.0, хотя, думаю, на других серверах
все аналогично.
____________________________
С уважением, Лисеев Дмитрий.
http://private.peterlink.ru/dimik/
PGP key fingerprint: 09 28 74 28 6C 39 62 29 2E CB 95 03 4F 04 33 73
--- ifmail v.2.15dev5
* Origin: Peterlink ISP News System (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
