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

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

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

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

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

Sergey13 (2008-03-19 15:23:00) [1]
> [63] Игорь Шевченко © (19.03.08 15:19)
> Насчет большинства - не соглашусь, но есть.

Просто наверное у нас разные предметные области. Но это не тема для спора, ИМХО.

Игорь Шевченко (2008-03-19 15:19:00) [2]
Sergey13 © (19.03.08 15:03) [62]

Безусловно. Насчет большинства - не соглашусь, но есть. Точно также есть много систем, где не требуются ключи в искусственном виде, и есть много систем, где не требуются ключи в естественном виде.

"Их тоже следует убивать" (с)

Все это к одному - что всякий овощ, и т.п.

Sergey13 (2008-03-19 15:03:00) [3]
> [60] Игорь Шевченко © (19.03.08 14:52)
> Ни данные по ним не выгрузишь вовне, ни загрузишь ничего с ними
Есть очень много систем (может их даже большинство), которым вообще не нужен импорт/экспорт. Они сами по себе.

ANB (2008-03-19 15:02:00) [4]

> обязательно придется по внешним не менее ключевым атрибутам
> сравнивать

Ну куда деваться то.

Игорь Шевченко (2008-03-19 14:52:00) [5]
ANB (19.03.08 14:44) [59]

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

И все время забывается о том, что кроме исправления ошибок после того, как уже вбито дофига данных, существует еще и естественное переименование ключевых атрибутов, про пример с RUR и RUB я уже писал, как и про разделение Югославии на кучу стран со своими названиями.
Эта ситуация происходит точно после того, как данные уже вбиты. И простым переимованием значения в справочной таблице, с сохранением ссылок на конкретную справочной же таблицы запись, тут не обойдешься никак.

Так что я не понимаю, какую пользу приносит повсеместное использование суррогатов, имеющих смысл только внутри системы. Ни данные по ним не выгрузишь вовне, ни загрузишь ничего с ними, обязательно придется по внешним не менее ключевым атрибутам сравнивать.

ANB (2008-03-19 14:44:00) [6]

> А триггеры на заполнение генерированных ключей новые программисты
> не забывают писать ?

Триггера на это дела могут генерятся автоматом. А вот правильную цепочку чистки приходится писать ручками.

> В тех случаях, когла не существует удобного уникального
> ключа вне системы.

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

Игорь Шевченко (2008-03-19 13:51:00) [7]
Sergey13 © (19.03.08 13:44) [57]

> Но ты похоже упорно не признаешь для других права использовать
> генераторы ключей.

Признаю. Сам использую. В тех случаях, когла не существует удобногоуникального ключа вне системы.

> Автор после задания вопроса пропал напрочь, посему вряд
> ли мы узнаем о его намерениях.

Да нафиг он нужен - автор ? :))

ANB (19.03.08 13:29) [56]

> Дык это надо все таблицы апдейтить. Да еще и не забывать
> добавлять в хранимку новые таблицы (извечная проблема -
> новые программисты никогда этого не делают).

Надо. А триггеры на заполнение генерированных ключей новые программисты не забывают писать ?

Sergey13 (2008-03-19 13:44:00) [8]
> [55] Игорь Шевченко © (19.03.08 13:16)

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

> а не так что "как обычно - генерацией".

Эта "красная тряпка" уже по моему выцвела вся пока мы тут "спорим".
Я же писал, что свой пост [1] писал имея в виду скорее ручное заполнение ПК (уж так я понял вопрос). Что плохого в этом случае в генерации ключей?
Автор после задания вопроса пропал напрочь, посему вряд ли мы узнаем о его намерениях.

ANB (2008-03-19 13:29:00) [9]

> Да хоть и во всей цепочке - не руками же каждый менять,
> сервер сделает.

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

Игорь Шевченко (2008-03-19 13:16:00) [10]
ANB (19.03.08 13:03) [54]

Блин. Ну писали уже десять раз, что в каждой задаче должен быть свой подход, а не так что "как обычно - генерацией".

А ты мне начинаешь про есть системы где физиков и юриков одинаково и поэтому их не надо по паспорту.

> Поменять номер в одной таблице или по всей цепочке связей
> ?

Да хоть и во всей цепочке - не руками же каждый менять, сервер сделает.

ANB (2008-03-19 13:03:00) [11]

> но для этого потребуется вводить этот номер в любую систему,
> куда ты будешь экспортировать данные.

Мы их ИМПОРТИЛИ. И собирали эти номера со всех источников. Если человек числился в нескольких - у него была инфа в каком источнике у него какой ИД.
И очень тяжко, когда импортишь, а этот ИД внешняя система не присылает.

> Извини, но менять неправильный номер что так, что сяк -
> фиолетово.

Поменять номер в одной таблице или по всей цепочке связей ?

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

Игорь Шевченко (2008-03-19 12:09:00) [12]
Sergey13 © (19.03.08 12:01) [52]

> Меняем просто атрибуты, а не связи. Типа смена неправильного
> номера паспорта.

Извини, но менять неправильный номер что так, что сяк - фиолетово.

> Я тоже про это. При импорте/экспорте часть данных ушла в
> ошибки. Для внутреннего функционирования системы это фиолетово.
> Можно спокойно искать ошибку, поменять атрибут и/или переназначить
> ссылки. Система в это время спокойно функционирует. А вот
> если связи настроены по ключам вызвавшим сбои, менять придется
> гораздо больше и не всегда тривиальными способами (когда
> нет каскадного изменения) и все это на живой системе.

И что ? Это то же самое, что и исправление ошибки. Причем тут экспорт/импорт и прочее ?

Sergey13 (2008-03-19 12:01:00) [13]
> [51] Игорь Шевченко © (19.03.08 11:20)
> Каким образом, если не секрет ?
Меняем просто атрибуты, а не связи. Типа смена неправильного номера паспорта.

> Я имел в виду связь по данным. Типа по идентификаторам...

Я тоже про это. При импорте/экспорте часть данных ушла в ошибки. Для внутреннего функционирования системы это фиолетово. Можно спокойно искать ошибку, поменять атрибут и/или переназначить ссылки. Система в это время спокойно функционирует. А вот если связи настроены по ключам вызвавшим сбои, менять придется гораздо больше и не всегда тривиальными способами (когда нет каскадного изменения) и все это на живой системе.

> Ошибается чаще всего человек, а не программа.
Именно об этом я и думал, когда писал [1]. Совсем неплохо, ИМХО, иметь независящий от человека механизм хотя бы внутреннего функционирования системы.

Игорь Шевченко (2008-03-19 11:20:00) [14]
Sergey13 © (19.03.08 10:19) [49]

> Нет конечно, но по моему значительно облегчает работу по
> борьбе с последствиями ошибок.

Каким образом, если не секрет ?

> Нет конечно, но позволяет системе нормально функционировать
> внутри себя в то время, как идет разбор причин отсутствия
> связи с внешними системами.

Я имел в виду связь по данным. Типа по идентификаторам...

ANB (19.03.08 10:52) [50]

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

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

> ЗЫ. Как то писали скрипт по поиску дублей людей в наложке.
> Ужаснулись результатам его работы.

Так тоже люди вводят. Ошибается чаще всего человек, а не программа. А программе бы желательно потенциальные ошибки отслеживать

ANB (2008-03-19 10:52:00) [15]

> Табельный номер это хорошо, но дальше родного предприятия
> его ценность стремится, сам понимаешь, к нулю и очень быстро.
>

А вот ничего подобного.
Во всяком случае, если экспортить этот код, то в приемнике при любых изменениях естественных ключевых данных все равно можно будет понять, что это именно изменение, а не добавление нового человека.
ЗЫ. Когда писали системку для БКИ после недельного обсуждения пришли к выводу, что нужно заставить банки высылать нам таки этот код. Сразу снялась куча проблем. Есно, остается проблема слития данных из разных источников. Но в этом случае, есно, без естественных ключей не обойтись.
Алгоритм получился эвристический и довольно навороченный, но,
1) случаи дублей от разных источников довольно редки
2) если не было ошибок и в разных источниках совпадают ключевые данные, то система понимает, что человек один и тот же и можно теперь подвязать к нему 2-й внешний ИД с указанием источника
3) если ошибки были то с большой вероятностью коллизии обнаруживаются.
4) есно, все равно остается вариант, когда человек будет забит в базу 2 раза.
ЗЫ. Как то писали скрипт по поиску дублей людей в наложке. Ужаснулись результатам его работы.

Sergey13 (2008-03-19 10:19:00) [16]
> [48] Игорь Шевченко © (19.03.08 09:55)
> Это автоматически исключает ошибки при вводе ?

Нет конечно, но по моему значительно облегчает работу по борьбе с последствиями ошибок.

> Это дает возможность связаться с внешними системами ?
Нет конечно, но позволяет системе нормально функционировать внутри себя в то время, как идет разбор причин отсутствия связи с внешними системами.

Игорь Шевченко (2008-03-19 09:55:00) [17]
ANB (19.03.08 09:46) [47]

Ну хорошо, сгенерированный ключ не может отсутствовать и иметь несколько значений. Дальше что ? Это автоматически исключает ошибки при вводе ? Это дает возможность связаться с внешними системами ?
В чем, собственно, его преимущество, кроме описанного в статье Тенцера быстродействия и компактности ?

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

ANB (2008-03-19 09:46:00) [18]

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

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

Johnmen (2008-03-19 09:02:00) [19]

> Anatoly Podgoretsky © (18.03.08 23:54) [44]
> Игорь Шевченко © (19.03.08 00:06) [45]

>но они никакого отношения к базам не имеют, в базе они естественные ключи.

О чем я и говорил.
Хотя другие могли обсуждать и в разрезе не БД, а чего-то другого, чего они там сами себе хотели...

Игорь Шевченко (2008-03-19 00:06:00) [20]

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

Целиком и полностью поддерживаю :)

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

Наверх

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