Как обеспечить невозможность вставки данных в обратном порядке

← →
Игорь Шевченко © (2007-09-28 11:59) [0]

Имеется таблица из двух полей (город1, город2)
Требуется обеспечить отсутствие записей с обратным порядком тех же самых городов, если есть запись "Москва","Бобруйск", то запись "Бобруйск","Москва" должно невозможно добавить любым способом.

Вопрос собственно, можно ли объявить такое ограничение на уровне объявления таблицы ?

← →
Anatoly Podgoretsky © (2007-09-28 12:08) [1]

Сводится к проверке выборкой - город2, город1

← →
Reindeer Moss Eater © (2007-09-28 12:09) [2]

Например триггер на бефоинсерт.
Но я бы сделал на клиенте

← →
Desdechado © (2007-09-28 12:09) [3]

CHECK place_id1 < place_id2
UNIQUE place_id1, place_id2
И в триггере переставлять при добавлении записи.

← →
Reindeer Moss Eater © (2007-09-28 12:14) [4]

или уникальный констрейнт на выражение по двум ключам независящее от перестановки операндов (если там ключи, а не строки).

← →
Sergey13 © (2007-09-28 12:31) [5]

Уникальность на сумму двух контрольных сумм.

← →
Игорь Шевченко © (2007-09-28 12:31) [6]

не должна проходить такая пара команд

INSERT INTO FOO VALUES ("Москва","Бобруйск");
INSERT INTO FOO VALUES ("Бобруйск","Москва");

Выданы эти INSERT"ы могут быть в произвольный момент времени из 1000 сеансов одновременно.

Кстати, решил задачу.

CREATE TABLE foo (
city1 CHAR(3) NOT NULL,
city2 CHAR(3) NOT NULL,
CONSTRAINT fk_foo_city1 FOREIGN KEY (city1) REFERENCES city
ON DELETE CASCADE,
CONSTRAINT fk_foo_city2 FOREIGN KEY (city2) REFERENCES city
ON DELETE CASCADE,
CONSTRAINT pk_foo PRIMARY KEY (city1,city2)
) ORGANIZATION INDEX;

CREATE UNIQUE INDEX foo_ix ON
foo (LEAST(UPPER(city1),UPPER(city2))||
GREATEST(UPPER(city1),UPPER(city2)));

← →
stanislav © (2007-09-28 12:33) [7]

Reindeer Moss Eater © (28.09.07 12:14) [4]
Это как?

← →
Reindeer Moss Eater © (2007-09-28 12:40) [8]

>Это как?
Примерно как в последнем параграфе [6].
Зависит от синтаксиса и возможностей сервера

← →
Desdechado © (2007-09-28 12:42) [9]

> UNIQUE INDEX foo_ix
это не
> ограничение на уровне объявления таблицы

И как обычно, СУБД не указано, а далеко не все поддерживают построение индексов по функциям.

← →
Игорь Шевченко © (2007-09-28 12:49) [10]

Desdechado © (28.09.07 12:42) [9]

А я вроде гайку Oracle ставил, когда вопрос задавал...

> > UNIQUE INDEX foo_ix
> это не
> > ограничение на уровне объявления таблицы

А что это, если не секрет ?

← →
Reindeer Moss Eater © (2007-09-28 12:49) [11]

Ну типа все, кто смог бы ответить и так помнят, что там у них Оракл.
Я например помню.
:)

← →
stanislav © (2007-09-28 13:19) [12]

Reindeer Moss Eater © (28.09.07 12:40) [8]
Понял.Интересно MSSQL это поддерживает?

← →
Desdechado © (2007-09-28 13:58) [13]

> А что это, если не секрет ?
На уровне индекса :)
На уровне таблицы - это UNIQUE CONSTRAINT.

← →
evvcom © (2007-09-28 14:10) [14]

> ON DELETE CASCADE

Смело!

← →
Игорь Шевченко © (2007-09-28 14:20) [15]

Desdechado © (28.09.07 13:58) [13]

Пардон, не так выразился. Хотел сказать - на уровне объявлений :)

evvcom © (28.09.07 14:10) [14]

> Смело!

Это бизнес-правило такое.

← →
evvcom © (2007-09-28 14:27) [16]

> Это бизнес-правило такое.

Главное, чтобы оно было задокументировано. Чтобы потом было, чем отмахиваться при разборах "внезапного" исчезновения данных :)

← →
sniknik © (2007-09-28 14:53) [17]

> Интересно MSSQL это поддерживает?
а че нет то? синтаксис записи конечно будет другой, а логику показанную в [6] почему и не повторить?

← →
Desdechado © (2007-09-28 15:31) [18]

> ON DELETE CASCADE
> Смело!
Для кросс-таблицы вполне нормально, хотя и не всегда нужно.

← →
Павел Калугин © (2007-09-28 15:49) [19]

разделитель между городами известен?
ввод осуществляется выбором из справочника или набором текста?

← →
Павел Калугин © (2007-09-28 15:54) [20]

И если бы речь шла про MSSql или про Sybase то написал бы кроме upper ещё ltrim rtrim
то есть ltrim(rtrim(UPPER(city1))) и так далее
Ибо если вводит операторто никто не застрахован от
INSERT INTO FOO VALUES ("Москва","Бобруйск");
INSERT INTO FOO VALUES ("Бобруйск"," Москва ");

← →
Игорь Шевченко © (2007-09-28 15:58) [21]

Павел Калугин © (28.09.07 15:49) [19]

Ввод осуществляется INSERT-ом :)
Города вводятся кодами, разумеется. И выбором и набором текста.

← →
Игорь Шевченко © (2007-09-28 15:58) [22]

> Игорь Шевченко (28.09.2007 15:58:21) [21]

Насколько я понимают тебе надо решение на уровне сервера.
На клиенте хоть и просто, но ненадежно.

> про MSSql или про Sybase то написал бы кроме upper ещё ltrim rtrim
а я бы и upper убрал бы... это дело коллатионов сравнение/индексирование разноразрядных букв (коллатион естественно бы поставил CASE IGNORE)

Ну если на входе код города, да еще и цифровой и код города 2, то решил бы уникальным индексом по полям city1, city2
и на insert поставил триггер
в котором
if exists(select 1
from foo f,inserted i
where f.city1 = i.city2
and f.city2 = i.city1
)
begin
raiseerror("Существует такая комбинация городов")
rollback
return
end

Опять же прошу прощения что не в оракловом синтаксисе

Павел Калугин © (28.09.07 16:07) [25]
решение в [6] и проше. и, имхо, менее "напряжно" для сервера. (чтобы точно, это надо проверить)

> Павел Калугин © (28.09.07 16:07) [25]

В чистом виде это на Оракл не перевести, а с минимальной корректировкой можно, но такое Оракл зарубит сразу. У него другие принципы, отличные от MSSQL.

Anatoly Podgoretsky © (28.09.07 16:04) [23]

Да, конечно на уровне сервера. Уникальным индексом по функции я вроде добился нужного.

> Petr V. Abramov © (28.09.07 22:48) [30]

Ты имеешь ввиду оракловую консерваторию? Дык, на то он и конкретный сервер со своими примочками, чтобы не ограничиваться только стандартами.

Как обеспечить невозможность вставки данных в обратном порядке Найти похожие ветки