Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

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

Страницы: < 1 2 3 4 >
NewSer © (2008-03-16 11:25:00)
Как организовать проверку - не вводит ли пользователь в поле с ключевым значением уже существующее (повторно)? (ADO)

Игорь Шевченко (2008-03-18 12:20:00) [41]
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:01:00) [42]
> [22] Игорь Шевченко © (18.03.08 11:53)
> Единственное, против чего я выступаю - это против повсеместного
> бездумного использования генерируемых ключей.

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

> (с) Joe Celko

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

Игорь Шевченко (2008-03-18 11:53:00) [43]
Sergey13 © (18.03.08 11:39) [21]

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

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

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

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

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

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

Игорь Шевченко (2008-03-18 10:48:00) [45]
Sergey13 © (18.03.08 10:14) [19]

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

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

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

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

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

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

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

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

Игорь Шевченко (2008-03-18 09:54:00) [47]
И еще раз - марксизм не догма, а руководство к действию. Я не призываю везде и всюду использовать только какой-то один подход - сгенерированный или не сгенерированный (неважно, искусственный или естественный) ключ.

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

Игорь Шевченко (2008-03-18 09:52:00) [48]
Sergey13 © (18.03.08 08:43) [15]

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

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

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

ANB (18.03.08 09:41) [16]

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

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

ANB (2008-03-18 09:41:00) [49]

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

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

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

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

Sergey13 (2008-03-18 08:43:00) [50]
> [14] Игорь Шевченко © (17.03.08 22:22)
> происходит полная лажа.

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

Игорь Шевченко (2008-03-17 22:22:00) [51]
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, происходит полная лажа.

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

ANB (2008-03-17 14:51:00) [52]

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

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

clickmaker (2008-03-17 14:46:00) [53]

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

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

Игорь Шевченко (2008-03-17 14:43:00) [54]
Sergey13 © (17.03.08 13:23) [7]

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

ANB (17.03.08 14:03) [10]

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

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

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

ANB (2008-03-17 14:03:00) [55]

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

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

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

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

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

ANB (2008-03-17 13:32:00) [57]

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

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

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

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

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

Ega23 (2008-03-17 12:56:00) [60]

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

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

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

Страницы: < 1 2 3 4 >

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »