baracsprog123Задача простая и вы, если подумаете, решите ее без форумных советчиков. Нужно добавить к "идентификатору" человека, т.е. его ФИО, еще и место и время его рождения. Если мало, то задать одного или обоих родителей. Такая информация хранится например в базах МВД и никогда никаких проблем, в отличие от софтварера:), не наблюдалось.

Фамилия, Имя, Отчество + место рождения + дата рождения. МВД действительно так идентифицирует человека, но проблемы, таки, иногда наблюдаются. В городах с миллионным населением за день рождается немало детей, и вероятность появления среди них полных тезок отличается от 0.

Про базы МВД, в которых хранятся данные о родителях - ваши фантазии. Это епрахия органов ЗАГС.
Любопытно, как ТС будет налаживать с ними взаимодействие.
Подтверждаю. При мне человек в отделение милиции приходил жаловаться, что на каждом стационарном посту ГАИ на МКАД его тормозят и задерживают. Смысл был в том, что в розыске был его полный тезка, причем совпадали даже даты рождения (место отличалось). Ну и Поток по номеру пробивал владельца, владелец определялся как розыскник, со всеми сопутствующими последствиями.

К сожалению, просто на ФИО ориентироваться бессмысленно. Про банальный случай смены фамилии писать нет смысла. Но через ЗАГС легко меняется и имя. Знаю девушку, которой не понравилось свое имя, и она его сменила.

Или вот еще пример: как дубль определились близнецы, у которых фамилия и отчество совпали, дата и место рождения тоже. Папа имена дал им очень похожие (разница в одной букве). Система посчитала это за опечатку.

Задача поиска дублей очень нетривиальная, есть системы очистки данных, поиска таких дублей и тп, например Фактор . По хорошему нужно несколько сценариев определения дубликатов, и все равно, 100% точности это не гарантирует.

Владимир37Народ, мне требуется помощь или, скорее всего, просто совет. Я разработал 2 программы клиентская (стоит в районах) и общая. Данные вводятся в районах, затем выгружаются в файл xml и загружаются в общую. Так вот, в обеих базах есть таблица с людьми (ФИО, дата рождения, СНИЛС, адрес и др). Вопрос в том, как уникально идентифицировать человека (построить первичный ключ). Теоретически один человек может быть заведен сначала в одном районе и загружен в общую. Потом человека могут завести в другом районе и при загрузке в общую базу его надо найти. Первоначально я думал использовать СНИЛС для идентификации человека, но потом выяснилось, что СНИЛС может и не быть (иностранцы, беженцы). Тогда как построить первичный ключ. Альтернативный вариант: использовать ФИО и дату рождения. Но это не вариант. Были у нас в области разные люди, у который полностью совпадали ФИО и ДР. Плюс еще одна проблема: нашли ошибку, например, в имени. Исправили и все, ключ изменился, при загрузке в общую базу будет создан новый человек.
Может, посоветуете, как все-таки построить первичный ключ.
Мне нравятся суррогатные ключи. И я бы для клиентов выбрал GUID, а не автоинкремент

JeStonemayton,
Возможно имелась ввиду такая характеристика GUID, как глобальная уникальность? Хотя не понятно как в контексте задачи ТС можно такое свойство использовать. Вот если бы не
авторТеоретически один человек может быть заведен сначала в одном районе ... Потом человека могут завести в другом районе

то смысл был бы

Нет, про GUID имелось ввиду следующее. Если программа установлена много где, и вполне может применяться по схеме головной офис - филиалы. Тогда возникает вопрос репликации. Только лишь из-за этого, разумеется, вопрос с определением дубликатов guid никак не решает