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

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

ANB (18.03.08 16:40) [39]

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

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

Johnmen © (18.03.08 16:07) [38]

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

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

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

← →
Johnmen © (2008-03-18 16:49) [41]

> Игорь Шевченко © (18.03.08 16:44) [40]
> Ну не понимаю я догматиков.

Насколько помню, там было объективно - и плюсы и минусы и того и другого.
Т.е. в конечном счёте - про овощ :))

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

Johnmen © (18.03.08 16:49) [41]

Вот про плюсы я как-то не увидел. Собственно, со статьей я знаком давно, и ее последователями тоже.
Но вот незадача - есть не менее авторитетный Joe Celko, который считает с точностью до наоборот, к сожалению, не могу найти в сети главу из его книжки, где он пишет про ID-иотов...

← →
Leonid Troyanovsky © (2008-03-18 21:50) [43]

> ANB (18.03.08 16:40) [39]

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

Человек идентифицируется с точностью до однояйцевых близнецов.
Ну, или клонов. Остальное - субъективо.

--
Regards, LVT.

← →
Anatoly Podgoretsky © (2008-03-18 23:54) [44]

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

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

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

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

← →
Johnmen © (2008-03-19 09:02) [46]

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

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

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

← →
ANB (2008-03-19 09:46) [47]

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

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

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

ANB (19.03.08 09:46) [47]

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

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

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

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

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

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

← →
ANB (2008-03-19 10:52) [50]

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

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

← →
Игорь Шевченко © (2008-03-19 11:20) [51]

Sergey13 © (19.03.08 10:19) [49]

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

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

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

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

ANB (19.03.08 10:52) [50]

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

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

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

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

← →
Sergey13 © (2008-03-19 12:01) [52]

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

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

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

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

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

Sergey13 © (19.03.08 12:01) [52]

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

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

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

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

← →
ANB (2008-03-19 13:03) [54]

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

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

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

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

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

← →
Игорь Шевченко © (2008-03-19 13:16) [55]

ANB (19.03.08 13:03) [54]

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

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

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

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

← →
ANB (2008-03-19 13:29) [56]

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

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

← →
Sergey13 © (2008-03-19 13:44) [57]

> [55] Игорь Шевченко © (19.03.08 13:16)

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

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

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

Sergey13 © (19.03.08 13:44) [57]

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

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

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

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

ANB (19.03.08 13:29) [56]

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

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

← →
ANB (2008-03-19 14:44) [59]

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

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

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

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

ANB (19.03.08 14:44) [59]

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

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

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

← →
ANB (2008-03-19 15:02) [61]

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

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

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

Sergey13 © (19.03.08 15:03) [62]

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

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

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

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

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

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