Проврека записи на уникальность

[Дима]

Здравствуйте.
Вопрос возник следующий: где лучше проводить проверку записи на уникальность при вставке/редактировании, с клиента запросом или в тригере?

[Merlin]

Ни там, ни там. Читай про Constraints.

[Дима]

to Merlin
Почитал. Поправьте, если не прав: необходимо создавать уникальный индекс и отлавливать ошибку, чтоб пользователь не пугался чего-то типа "violation of PRIMARY or UNIQUE KEY".
А с тригерами и запросами при многопользовательском режиме хлопот не оберешься
Поспешил.

[Дима]

И опять я.
А как же быть со строковыми полями, ползователь может ввести поле в другом регистре и constraint unique уже не поможет, ведь нелтзя так:
ADD CONSTRAINT UNQ1_IZDELIJA UNIQUE (Upper(NAME), ED_IZM_REF).
Тогда check? Но Ковязин не рекомендует брать данные для check из записей этой же таблицы.
Как же быть?

[kdv]

это уже называется "контроль качества данных", и к СУБД как такового отношения не имеет. То есть, у пользователей изощренная фантазия, менять О на 0 и наоборот, вводить буквы в разном регистре, и т.п. Так что нужно самостоятельно придумать комплекс мер, которые защитят вводимые данные.

причем, я тебе посоветую почитать книжки по проектированию БД.
пока замечу

1. Есть первичный ключ, а есть альтернативный. ПК - это primary key, альтернативный ключ - это unique.
2. Первичный ключ обычно это искуственный ключ (абстрактное число).
3. данные можно приводить при вставке к Upper. Не хочешь в конкретном столбце, значит в добавленном для хранения upper.

и т.д.

[Ivan_Pisarevsky]

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