Форум: "Базы";
Текущий архив: 2002.11.14;
Скачать: [xml.tar.bz2];
ВнизУникальное значение по нескольким полям Найти похожие ветки
← →
dim- (2002-10-27 13:57) [0]Нужно организовать получение уникального значения. Есть БД (установленна локально на нескольких ПК) со списком людей, периодически происходит обмен данными. Как можно организовать идентификацию человека не зависимо на какой машине он был внесен, что-бы уменьшить вероятность получения двойников, если одного и того же человека занесли на двух или более ПК.
← →
Desdechado (2002-10-27 14:04) [1]1. если территориально далеко, то двойники вряд ли возникнут :)
2. если территориально близко, то в локальную сеть их и на единую БД направить
3. если локалка невозможна, то через модемные соединения и терминал сервер опять же на одной БД
Ну а если все это ПРИНЦИПИАЛЬНО не то, то определиться, что именно должно указывать на задвоение и при сливании анализировать.
← →
dim- (2002-10-27 21:34) [2]Если бы так все легко было:)
Просто наиболее постоянное значения: Дата рождения, пол, Имя, Отчество (хотя тоже может меняться).
Все остальные могут меняться в течении жизни, а хочется формировать некий код, который мог бы позволить инициализировать человека с минимальной вероятностью появления двойников
← →
Anatoly Podgoretsky (2002-10-27 21:52) [3]Приведенные признаки не являются уникальными, но даже и они могут измениться
← →
elv (2002-10-28 09:10) [4]dim- © (27.10.02 21:34)
М.б. тебе поможет код плательщика налога.
P.S. Если не ошибаюсь, на ibase.ru, в разделе репликация есть статья посвященная решению похожей проблемы.
← →
dim- (2002-10-28 09:37) [5]elv ©
код плательщика налога есть не у всех и я знаю человека у него таких кодов 2. По поводу статьи спасибо, посмотрю.
← →
stone (2002-10-28 09:45) [6]Если данные не синхронизируюются при добавлении или изменении, то выработать уникальный код не получиться. Хотя есть вариант вырабатывать ID внутри каждой базы, предварительно расставиви приоритеты разных баз при их слиянии. Процедура объединения данных должна анализировать айдишник каждой добавляемой в основную БД записи с уже имеющимися и при совпаденнии указанных тобой параметров менять его в добавляемой записи на найденный. Отрицательный момент такой технологии в том, что айдишник должен меняться и в присоединяемой базе, а потом измененная база должна возвращаться пользователям. Как организовать двусторонний обмен данными - это уже технические детали.
← →
sniknik (2002-10-28 10:57) [7]действительно проблема и похоже нерешаемая :((.
знаю по опыту, в супермаркетах вернее в сетях супермаркетов при распределенной базе товар может забиватся на местах а потом в офисе сливатся в общую базу, так вот даже имея жесткий идентификатор - баркод - умудряются задваивать и затраивать и т.д. товары, просто неправильно его вбивая, учитывая что ввод баркода делается сканером то сначала непонятно как умудряются, но в итоге все обьясняется разными обьективными причинами. (одно из обьясниений оператора, тетка 40 лет, "да я незнаю как он работает! кто меня научил?" :-)), кто видел сканеры, надо обучать ими работать? и ли достаточно показать?)
← →
roottim (2002-10-28 11:51) [8]проблема всеравно останется, но скажу что в органах (именно в паспортном столе) идентефикация человека организуется изсходя из ФИО, даты рождения и места рождения!
← →
Delirium (2002-10-28 12:04) [9]Думаю стоит рассмотреть, как вариант, генерацию ключа на основе контрольных сумм ...
http://softdev.omskreg.ru/cpp/crc.asp
Страницы: 1 вся ветка
Форум: "Базы";
Текущий архив: 2002.11.14;
Скачать: [xml.tar.bz2];
Память: 0.47 MB
Время: 0.015 c