Базы данных и обеспечение уникальности

← →
Servy © (2010-09-11 15:42) [0]

Есть таблица в базе данных, в частности в ней есть колонки

PRIMARY KEY UINT id
UINT type
VARCHAR(255) data

id - суррогатный ключ для связи с другими таблицами, type - тип документа (например 0-паспорт, 1-студенческий билет), data - данные документа (номер и серия паспорта, номер студенческого билета).

Пара type и data должна быть уникальна, то есть в таблице не может быть двух столбцов с одинаковыми type и data, как не может быть двух людей с одинаковыми паспортными данными. Как правильно при вставке новой строки убедиться в уникальности данной пары и возбудить исключение при попытке вставки дубликата? Возможно ли для этого наложить какие-то ограничения на таблицу, так, чтобы СУБД сама давала мне отлуп при попытке такой вставки?

Предполагаю, что задача нередкая, но сходу не нагуглилась. В базах данных я пока далеко не гуру. Заранее благодарен за ваше участие и снисходительность ^_^.

← →
Anatoly Podgoretsky © (2010-09-11 15:50) [1]

> Servy (11.09.2010 15:42:00) [0]

> В базах данных я пока далеко не гуру.

Плохо твое дело.

← →
Джо © (2010-09-11 15:53) [2]

> как не может быть двух людей с одинаковыми паспортными данными.

Может, может...

← →
Джо © (2010-09-11 15:54) [3]

П. С. СУБД указали бы. В разных это делается по-разному.

← →
Servy © (2010-09-11 16:01) [4]

> Плохо твое дело.

Еще веревку и мыло предложите ^_^. Или тут обычно метлы раздают?

Текущее решение - предварительный селект для проверки наличия. Уже напоролся когда два конкурирующих инсерта успешно прошли селект и добавили таки 2 одинаковые записи. Теперь думаю, как это делается правильно ^_^.

> Может, может...

В той модели реальности, которая есть в моей БД и моем несуществующем ТЗ - не может ^_^.

> СУБД указали бы. В разных это делается по-разному.

В данный момент я натолкнулся на такую проблему в Mysql, но было бы интересно услышать более-менее общие решения, чтобы иметь в виду в будущем.

← →
Игорь Шевченко © (2010-09-11 16:01) [5]

во многих СУБД это делается через CREATE UNIQUE INDEX

← →
Servy © (2010-09-11 16:10) [6]

Большое спасибо, похоже это то, что мне нужно.

← →
Piter © (2010-09-11 19:28) [7]

а мне тоже стало интересно... Если бы уникальных ключей или ограничений не было бы, как такой вопрос грамотно реализовать?
Этому сильно бы мешала транзакционность...

Сходу пока придумалось в блокировочниках использовать блокировки вынужденно, чтобы транзакции в очередь вставали, но это не кошерно и могло бы сильно снизить производительность. Кто еще что думает?

← →
картман © (2010-09-12 02:24) [8]

> Если бы уникальных ключей или ограничений не было бы,

а такая система назвалась бы СУБД?

← →
старый маразматик (2010-09-12 03:52) [9]

> Servy © (11.09.10 15:42)

> и снисходительность

упс...

> картман © (12.09.10 02:24) [8]

> а такая система назвалась бы СУБД?

а шо это за ..., извините? у неё шо, по определению, должны
быть уникальные ключи? сцылу в студию, плиз. а то я уже нифига себе скока лет этой фигней занимаюсь, может чего пропустил?

зы. почти Кэтмар. но - не он... а я уж было обрадовался...

> Джо © (11.09.10 15:53) [2]

> Может, может... но - не хочет!

это ты о сиамских близнецах? двое в одной фотке. кошмар и ужос.

← →
Джо © (2010-09-12 04:48) [10]

> старый маразматик (12.09.10 03:52) [9]
> это ты о сиамских близнецах

Нет, это я об ужасах реальной жизни паспортных столов.

← →
Piter © (2010-09-12 19:14) [11]

картман © (12.09.10 2:24) [8]
а такая система назвалась бы СУБД?

не нашел такой БД, даже в SQLite это есть... Но если допустить, что уникальных ключей нету... Или что более вероятно - БД не умеет строить уникальный ключ, допустим, по строковому полю (даже более того, не умеет строить вообще индексы по строковым полям).

И вот тут возникает задача обеспечения уникальности некоего текстового поля... Варианты решения?

← →
Petr V. Abramov © (2010-09-12 19:57) [12]

> Piter © (12.09.10 19:14) [11]

найти другую СУБД. если нельзя, отказаться от решения задачи с формулировкой "не нанимался заниматься онанизмом"

← →
Anatoly Podgoretsky © (2010-09-12 20:06) [13]

> Piter © (12.09.10 19:14) [11]

Как минимум есть файловые СУБД

← →
Anatoly Podgoretsky © (2010-09-12 20:10) [14]

Кстати назову один SQL сервер, который не справится, в этом или подобных случаях. Это Interbase и его клоны.

> И вот тут возникает задача обеспечения уникальности некоего
> текстового поля... Варианты решения?

Когда уникальные индексы не доступны, то их заменяют селектом с условием.

Anatoly Podgoretsky © (12.09.10 20:11) [15]
Когда уникальные индексы не доступны, то их заменяют селектом с условием.

это понятно. Самая главная проблема, что в двух транзакциях может пройти проверка на SELECT, а потом уже будут внесены данные

и собственно рассматриваются варианты решения именно этой задачи.

> это понятно. Самая главная проблема, что в двух транзакциях
> может пройти проверка на SELECT, а потом уже будут внесены
> данные

Так где недоступны уникальные индексами, там не пахнет транзакциями или они фикция.
Естественно, не гарантируется надеждность техническими методами, но ее можно попытаться реализовать административными методами. Чтобы не было перекрытия с разных мест, ну или хотя бы после вставки проверять на коллизию и ее разруливать.

> и собственно рассматриваются варианты решения именно этой
> задачи.

Я вижу только одно решение, выбрать СУБД без этой проблемы. Ведь очень много бесплатных СУБД, тот же MSSQL, где такой проблемы нет в принципе, хоть по трем полям делай индексы, к тому же регистро нечувствительные.

← →
картман_ (2010-09-13 12:27) [20]

> старый маразматик (12.09.10 03:52) [9]

> сцылу в студию, плиз. а то я уже нифига себе скока лет этой
> фигней занимаюсь, может чего пропустил?

ну, ВАЗ тоже как бы автомобиль

Базы данных и обеспечение уникальности Найти похожие ветки