Как проверить уникальность вводимого в ключевое поле значения?

← →
NewSer (2008-03-16 11:25) [0]

Как организовать проверку - не вводит ли пользователь в поле с ключевым значением уже существующее (повторно)? (ADO)

← →
Sergey13 © (2008-03-17 08:37) [1]

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

← →
Игорь Шевченко © (2008-03-17 12:08) [2]

> Ввод пользователем ключевых полей желательно исключить совсем

Вах! Как это ?

← →
clickmaker © (2008-03-17 12:09) [3]

> Как организовать проверку - не вводит ли пользователь в
> поле с ключевым значением уже существующее (повторно)?

поискать уже существующее?

← →
ANB (2008-03-17 12:47) [4]

> поискать уже существующее?

Как вариант.
Но лучше - попробовать выполнить операцию изменения/добавлени и ловить исключение.

← →
Ega23 © (2008-03-17 12:56) [5]

> Вах! Как это ?

Не давать пользователю вообще знать о существовании ключа.
Пример (MSSQL):
рабочая таблица:
create table MyWorkTable ( UID int identity (1,1), ....., constraint PK_MYWORKTABLE primary key (UID));
Соответственно, при после вставки записи выбирать в той же транзакции Select Result=Scope_Identity() и возвращать данное значение на клиент.
После переоткрытия выборки - позиционировать НД по значению Result.
Для IB - тоже самое, но с генератором.

Таким макаром юзер вообще не знает про PK и какие-то ключи.

← →
Ega23 © (2008-03-17 12:59) [6]

А по сабжу - либо проверять перед вставкой, либо ловить exception после.
ИМХО, зависит от объёма базы и количества клиентов, одновременно работающих с БД. Если вероятность одновременного добавления (модификации) такой записи двумя клиентами не сильно велика - то проверка "До". Естественно, с последующей ловлей исключения.
Если вероятность достаточно велика - то просто ловля исключения.

← →
Sergey13 © (2008-03-17 13:23) [7]

> [2] Игорь Шевченко © (17.03.08 12:08)
> Вах! Как это ?

Да как обычно - генерить.

← →
ANB (2008-03-17 13:32) [8]

> Sergey13 © (17.03.08 13:23) [7]

PK - генерить, UK - по любому юзер вбивает.

← →
Sergey13 © (2008-03-17 13:45) [9]

> [8] ANB (17.03.08 13:32)
> UK - по любому юзер вбивает.

Это может быть и набор ссылок. Так что процесс "вбивания" все не совсем "от балды" идет.

ЗЫ: Мне все таки кажется у автора проблема с ПК.

← →
ANB (2008-03-17 14:03) [10]

> ЗЫ: Мне все таки кажется у автора проблема с ПК.

В сабже, про вводимый руками ключ. У нормальных программистов - это УК, а не ПК.
Впрочем, очень очень редко и ПК вбивается руками. И ничего в этом такого страшного нету.

← →
Игорь Шевченко © (2008-03-17 14:43) [11]

Sergey13 © (17.03.08 13:23) [7]

> Да как обычно - генерить.

ANB (17.03.08 14:03) [10]

> У нормальных программистов - это УК, а не ПК.

Они всегда чем-то отличаются ?
Нравится мне постановка вопроса - если ключ не генерируется, значит программист ненормальный.

Удавил бы таких генераторов на первой же осине :)

← →
clickmaker © (2008-03-17 14:46) [12]

> У нормальных программистов - это УК

это уже у хакеров ))

← →
ANB (2008-03-17 14:51) [13]

> Они всегда чем-то отличаются ?
> Нравится мне постановка вопроса - если ключ не генерируется,
> значит программист ненормальный.
>
> Удавил бы таких генераторов на первой же осине :)

1. Констрейнты таки разные. В оракле, во всяком случае, часто бывает разница в использовании.
2. Не надо нас давить. :) Тем более я написал, что иногда (очень редко) мона ПК и без генераторов делать.

← →
Игорь Шевченко © (2008-03-17 22:22) [14]

ANB (17.03.08 14:51) [13]

> 1. Констрейнты таки разные. В оракле, во всяком случае,
> часто бывает разница в использовании

Да ну ? В каком именно месте и какая именно разница ? Очень любопытно узнать про оракл, который оказывается сгенерированные ключи обрабатывает иначе, чем не сгенерированнные ?

> 2. Не надо нас давить. :) Тем более я написал, что иногда
> (очень редко) мона ПК и без генераторов делать.

Надо вас давить. Иначе появляются таблицы вида
CREATE SEQUENCE foo_gen;

CREATE TABLE foo (
id NUMBER(10) PRIMARY KEY;
code VARCHAR2(2),
name VARCHAR2(32),
CONSTRAINT uq_code UNIQUE,
CONSTRAINT pk_foo PRiMARY KEY(id)
);

Ну и триггер натурально вешается. А потом начинается, что вначале под ID = 1 был код XX и все было хорошо, а потом его отредактировали и стал код YY. С точки зрения генераторщиков все хорошо, как же, пуризм соблюден.
А точки зрения тех сущностей, которые честно продолжают ссылаться на ID=1 и обнаруживают, что оно уже не ХХ, как честно должно быть, а YY, происходит полная лажа.

Удавил бы на первой осине.

← →
Sergey13 © (2008-03-18 08:43) [15]

> [14] Игорь Шевченко © (17.03.08 22:22)
> происходит полная лажа.

Почему? У сущности поменялся уникальный атрибут, но сущность то осталась та же (типа человек паспорт поменял). Если, используя этот механизм, меняют сущности (типа меняют одного человека на другого) - тогда да, криминал. Но это уже не проблема генерирования.

← →
ANB (2008-03-18 09:41) [16]

> Да ну ? В каком именно месте и какая именно разница ? Очень
> любопытно узнать про оракл, который оказывается сгенерированные
> ключи обрабатывает иначе, чем не сгенерированнные ?

Оракл немного по разному обрабатывает UK и PK. В частности, репликация по УК невозможна.

> А потом начинается, что вначале под ID = 1 был код XX и
> все было хорошо, а потом его отредактировали и стал код
> YY. С точки зрения генераторщиков все хорошо, как же, пуризм
> соблюден.

Классический случай, когда нужен генератор. УК вводит юзер с контролем на уникальность. ПК же генерится. С учетом того, что оракл не поддерживает каскадного обновления внешних ключей, при использовании введенного юзером ПК возникает проблема его корректуры (а запрещать ее нельзя, т.к. уж если дал юзеру добавить запись и вбить код, то потом нужно разрешать его и редактировать).
Намного хуже вариант : Имеем справочник с естественным ключом, вбили туда XXX. Затем возникла необходимость поменять его на YYY. И начинаем собирать проблемы со всеми записями, которые на XXX ссылались.

← →
Игорь Шевченко © (2008-03-18 09:52) [17]

Sergey13 © (18.03.08 08:43) [15]

> Почему? У сущности поменялся уникальный атрибут, но сущность
> то осталась та же

Ага. Та же осталась запись в базе данных, на которую кто-то ссылается. А то, что атрибут поменялся - так это семечки, главное, что сгенерированный ключ остался неизменным. В жизни реальных сущностей сгенерированных ключей нет и быть не может, то, что облегчает жизнь программисту, может существенно усложнить жизнь пользователям данных.
И не надо мне рассказывать про кривые руки - прямых рук тоже не бывает :) Если в системе есть возможность для применения кривых рук, она непременно будет использована, причем дважды.

Удавил бы на первой осине :)

ANB (18.03.08 09:41) [16]

> Намного хуже вариант : Имеем справочник с естественным ключом,
> вбили туда XXX. Затем возникла необходимость поменять его
> на YYY. И начинаем собирать проблемы со всеми записями,
> которые на XXX ссылались.

А в чем, собственно, проблемы ? Ввел YYY, далее каскадное обновление вручную. Главное, что это не даст возможности легким движением руки сменить XXX на YYY без каких-либо предупреждений.

← →
Игорь Шевченко © (2008-03-18 09:54) [18]

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

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

← →
Sergey13 © (2008-03-18 10:14) [19]

> [17] Игорь Шевченко © (18.03.08 09:52)
> А то, что атрибут поменялся - так это семечки

А что это - конец света? Если человек поменял паспорт надо вводить нового человека? Или что? Почему старые данные по этому человеку не должны ссылаться на него же?
Если важна хронология атрибута, то ее и решать надо соответственно.

> Если в системе есть возможность для применения кривых рук,
> она непременно будет использована, причем дважды.

А как твой вариант, без суррогата (как я понял) исключит их использование? Если можно менять ПК каскадно, то почему пользователю этого не сделать? Если нельзя, то как собрать воедино данные по одной меняющейся сущности?

← →
Игорь Шевченко © (2008-03-18 10:48) [20]

Sergey13 © (18.03.08 10:14) [19]

> А как твой вариант, без суррогата (как я понял) исключит
> их использование? Если можно менять ПК каскадно, то почему
> пользователю этого не сделать? Если нельзя, то как собрать
> воедино данные по одной меняющейся сущности?

Давай таки различать пользователя и разработчика. То, что делает пользователь, относится к реальной жизни, где, я повторю, автоматически сгенерированных ключей нет и быть не может. И могут быть совершенно разные ситуации в совершенно разных задачах - где-то надо изменить сущность, где-то надо создать вторую сущность, потому что право на существование имеют как старая, так и новая.
Если у разработчика (опять же, мы не берем идеал) что-то легко и просто не получится, например изменить ключевой атрибут каскадно, я склонен полагать, что он все-таки задумается, а надо ли его менять ?
А то, по наблюдениям, народ пользуется автоматическими дизайнерами всякими, которые и генерируют такие вот ключики-замочики с автоматической возможностью замены чего угодна на что угодно.

> Если человек поменял паспорт надо вводить нового человека?

А это уже от задачи зависит - нету тут однозначного решения. Где-то не надо вводить нового человека, где-то надо вводить нового человека, где-то надо оставлять и старый и новый паспорт.

← →
Sergey13 © (2008-03-18 11:39) [21]

> [20] Игорь Шевченко © (18.03.08 10:48)
> То, что делает пользователь, относится к реальной жизни,
> где, я повторю, автоматически сгенерированных ключей нет
> и быть не может.

Водитель машины может и не догадываться про инжекторы/карбюраторы, которые никак не учавствуют в его "реальной жизни". Однако от его незнания реальность не меняется.
ИМХО, нет ничего зазорного стараться облегчить жизнь себе и разрабатываемой системе, естественно обеспечивая нужный функционал. И если я стараюсь (по возможности и без фанатизма естественно) скрыть реализацию связей от пользователя, мне это кажется дополнительной защитой от его (да и моих) шаловливых ручек.

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

Так по наблюдениям нород еще пользует всякие быстрые системы разработки приложений. В результате получаются как шедевры, так и поделки. Не от инструмента это, ИМХО, зависит.

← →
Игорь Шевченко © (2008-03-18 11:53) [22]

Sergey13 © (18.03.08 11:39) [21]

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

"Стремление новообращенных программистов SQL использовать IDENTITY, GUID, ROWID или другое нестандартное средство автонумерации в качестве ключа проистекает из привычки работать с магнитными лентами. Им хочется знать, в каком порядке строки добавлялись к БД, точно так же, как раньше им нужно было знать порядок добавления записей в конец магнитной ленты!"
(с) Joe Celko

← →
Sergey13 © (2008-03-18 12:01) [23]

> [22] Игорь Шевченко © (18.03.08 11:53)
> Единственное, против чего я выступаю - это против повсеместного
> бездумного использования генерируемых ключей.

Против повсеместного, и главное бездумного, и я выступаю. 8-)

> (с) Joe Celko

ИМХО с этой цитаты можно начать не одну холивару. 8-)

← →
Игорь Шевченко © (2008-03-18 12:20) [24]

Sergey13 © (18.03.08 12:01) [23]

> Против повсеместного, и главное бездумного, и я выступаю.
> 8-)

Вот как ? :)

А как же то, с чего началось:

"Sergey13 © (17.03.08 13:23) [7]
> [2] Игорь Шевченко © (17.03.08 12:08)
> Вах! Как это ?

Да как обычно - генерить."

← →
Sergey13 © (2008-03-18 12:56) [25]

> [24] Игорь Шевченко © (18.03.08 12:20)
> А как же то, с чего началось:

Началось все с

> [1] Sergey13 © (17.03.08 08:37)
> Ввод пользователем ключевых полей желательно исключить совсем, если конечно это не естественный ключ.

Ты предлагаешь пользователю вручную вводить сурогаты?

← →
Игорь Шевченко © (2008-03-18 13:05) [26]

Sergey13 © (18.03.08 12:56) [25]

> Ты предлагаешь пользователю вручную вводить сурогаты?
> <Цитата>
> » удаление...

Почему бы и нет ? Разнообразные кодировки, в том числе и международных стандартов, есть самые настоящие суррогаты. И не обязательно символьные, есть и числовые.
Кстати, номер паспорта, ИНН и прочее - самые что ни на есть суррогаты, однако ж вводят.

← →
Sergey13 © (2008-03-18 13:42) [27]

> [26] Игорь Шевченко © (18.03.08 13:05)

Ну так все перечисленные тобой реквизиты - это естественные ключи, которые конечно могут быть и сурогатами. Никто с этим и не спорит.

← →
Johnmen © (2008-03-18 13:48) [28]

> Игорь Шевченко © (18.03.08 13:05) [26]
> Кстати, номер паспорта, ИНН и прочее - самые что ни на есть суррогаты, однако ж вводят.

Кстати, нет, не суррогаты.

Johnmen © (18.03.08 13:48) [28]

> Кстати, нет, не суррогаты.

А что ? :)

Sergey13 © (18.03.08 13:42) [27]

> Ну так все перечисленные тобой реквизиты - это естественные
> ключи, которые конечно могут быть и сурогатами. Никто с
> этим и не спорит.

Отнюдь не естественные, а тоже неким образом сгенерированы. Интересно, что естественного в цифровом коде авиакомпании "Аэрофлот" равном 555 ?

Просто так условились...

> Игорь Шевченко © (18.03.08 14:12) [29]

А Sergey13 © тоже неправ.
Ключ либо натуральный, либо суррогатный. Без полутонов и оттенков :)
Суррогатный ли ключ определяется не способом генерации, а предназначением и наличием предметной сущности.

> [29] Игорь Шевченко © (18.03.08 14:12)
> Отнюдь не естественные, а тоже неким образом сгенерированы.

Все в этом мире кем то сгенерировано. 8-)
По отношению к разрабатываемой конкретной системе такие ключи нельзя назвать генерируемые, так как они генерируются вне этой системы. А там хоть Делфийский Оракул выдумывает значение, хоть попугай выдергивает из кучи.

> По отношению к разрабатываемой конкретной системе такие
> ключи нельзя назвать генерируемые, так как они генерируются
> вне этой системы

Во! Именно это я имел в виду - что для подобных сущностей вводить дополнительный генерируемый внутри системы ключ есть ересь и вводящих надлежить при жизни ссылать прямиком в ад.

Johnmen © (18.03.08 14:18) [30]

> Ключ либо натуральный, либо суррогатный. Без полутонов и
> оттенков :)

Шанкр либо твердый, либо мягкий (с)

> Суррогатный ли ключ определяется не способом генерации,
> а предназначением и наличием предметной сущности.

Да, ты прав, все от задачи зависит. А на фразу "да как обычно - генерировать" у меня вызывает безусловный рефлекс, как красная тряпка у быка.

← →
ANB (2008-03-18 15:10) [33]

> Во! Именно это я имел в виду - что для подобных сущностей
> вводить дополнительный генерируемый внутри системы ключ
> есть ересь и вводящих надлежить при жизни ссылать прямиком
> в ад.

Очень мало сущностей, код которых уникален в пределах страны (типа ИНН) и их никак не поиспользовать в качестве первичного ключа. Уже нарывался.
Единственно, где это может быть оправдано - общероссийские справочники типа хотя бы КЛАДРа. Вот как раз в случае с КЛАДР использование для самого справочника своего ИД (сгенеренного) - вешалка для разработчика в процессе эксплуатации. Я как то работал с системой с таким КЛАДР. Импорт нового - был задачей нетривиальной.
Короче - согласен с ИШ - каждому овощу свое место в огороде.

> Игорь Шевченко © (18.03.08 14:45) [32]

Тем не менее, я настаиваю, что, например, № паспорта или номер авиакомпании ни в коем разе не м.б. суррогатным ключем.
Т.к. паспорт м.б. безвозвратно утрачен, а человек ещё жив :)
(здесь следует говорить просто о совпадении СК с атрибутом, и только о так)
А в новой классификации для авиакомпаний м.б. новая система идентификации.
(сменился способ генерации, а однозначность гарантированна в рамках одного)

Johnmen © (18.03.08 15:12) [34]

Все зависит от задачи.

> Тем не менее, я настаиваю, что, например, № паспорта или
> номер авиакомпании ни в коем разе не м.б. суррогатным ключем.
>
> Т.к. паспорт м.б. безвозвратно утрачен, а человек ещё жив
> :)

> А в новой классификации для авиакомпаний м.б. новая система
> идентификации.

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

Впрочем, зачем далеко ходить - во времена деноминации в блаженной памяти 1998 году вполне уживалось два рубля, один с кодом RUR, другой с кодом RUB, хотя сам рубль как был денежной единицей Российской федерации, так ей и остался.
А нолики, сам понимаешь, у каждого рубля были свои.

Насчет паспорта - опять же, все зависит от задачи. Если человек в задаче идентфицируется по номеру паспорта - тогда поменять номер на новый не составит проблем. А если требуется идентифицировать и по старому и по новому, то ID тебя не спасет.

> Игорь Шевченко © (18.03.08 15:34) [35]
> все зависит от задачи.

Что именно?
У меня ощущение, что мы говорим несколько о разном.

Johnmen © (18.03.08 15:50) [36]

> Что именно?
> У меня ощущение, что мы говорим несколько о разном.

Использование ключевых реквизитов, их состав, хранение и обработка.
Мы не о разном, мы об одном и том же. По крайней мере я о вреде поголовного или бездумного использования автогенерируемых в системе ключей.

> Игорь Шевченко © (18.03.08 15:59) [37]

Ну если о вреде, то об одном :))
Хотя я вред и не обсуждал..

Вспоминается перманентно возникающая дискуссия "СК vs НК". А чего ей возникать? В статье на ibase.ru всё сказано...

← →
ANB (2008-03-18 16:40) [39]

> Если человек в задаче идентфицируется по номеру паспорта

Человека в задаче нельзя идентифицировать точно ни по одному из естественных аттрибутов. Только по искусственному ИД. Который хитрым алгоритмом еще надо определить. Хорошо еще номера документов не дублируются, хотя нельзя исключать ошибки оператора, приводящей к заведению одного и того же документа для разных людей.

ANB (18.03.08 16:40) [39]

> Человека в задаче нельзя идентифицировать точно ни по одному
> из естественных аттрибутов. Только по искусственному ИД

Можно. Например по номеру паспорта, страхового свидетельства, ИНН и много другого :)

Johnmen © (18.03.08 16:07) [38]

> В статье на ibase.ru всё сказано...

"В общем-то, выводы очевидны – введение СК позволяет получить лучше управляемую, более компактную и быстродействующую БД."

Всякой задаче своя база данных. Еще раз. Ну не понимаю я догматиков.

Как проверить уникальность вводимого в ключевое поле значения? Найти похожие ветки