|
su.dbms
- SU.DBMS ----------------------------------------------------------------------
From : Victor Kolos 2:4621/14.110 21 Jun 2002 11:36:09
To : Igor Shmidt
Subject : Уникальный ключ для человека
--------------------------------------------------------------------------------
Чет Июн 20 2002 10:05, Igor Shmidt wrote to All:
IS> From: "Igor Shmidt" <mca@cpl.pstu.ac.ru>
IS> Как наилучшим образом обеспечить уникальность ключа для человека в
IS> разных БД? Ввод в разных БД будет происходить совершенно независимо.
В принципе - ключ - довольно тупая штука для идентификации человека в случае
неточности ввода оператором. В твоем случае есть несколько подходов:
1. Обеспечить доступ к некому центральному компу который генерил бы уникальный
код - тупой способ который тянет за собой частую синхронизацию и огромное
количество неточностей.
2. Заносить как можно больше идентификаторов человека -
2.1. Дата рождения - все понятно - в случае однофамильцев поможет (только
поможет) их различить;
2.2. Фамилию, имя, отчество - каждое в своем поле, причем поля имени и отчества
пусть синхронизируются с таблицей имен, происходящих от них отчеств и склонений
(согласись ты же не всегда будеш выдавать какие либо справки в именительном
падеже - а все таки будеш). Так вот - ввел имя (даже первые буквы - выскакивает
его окончание - и оператор доволен - и тебе мороки меньше с ошибками) - если
такового в буфере нет - выскочит запрос на добавление или исправление ошибки.
2.3. Паспорт - серию и номер - еще одна помощь в различии одноименных людей
2.4. Идентификационный номер - кстати обязательный везде (!) - проверь.
Вот тебе четыре фактора по которым ты должен искать наиболее похожего человека в
уже существующей базе - точнее 7 полей.
Совпадение записи по 5 полям можно считать похожей (мало того, при вводе первых
из них - например - дата и фамилия - твоя прога может предложить готовую запись
оператору - он так буден рад выбрать уже существующего человека в базе).
Hу, естественно, не забываем что в твоей базе каждый человек будет иметь свой
уникальный номер - согласно топологии твоей БД.
Если совпадает всего 2-3 поля - значит - не обойтись без людского фактора.
Это значит что раз в неделю некий оператор запустит проверку на похожесть и
просмотрит возможные варианты исправлений. В случае корректности в логическое
поле каждой записи пишем 1 - это означает что эта запис проверена и дальнейшей
проверке не подлежит.
Таким образом оператор будет проверять только последние, введенные за неделю
записи.
Теперь механизм синхронизации. Какой-то филиал передает свою базу с "людьми" в
другой, либо (что лучше) в центральный. Там в автоматическом режиме твоя прога
сравнивает поступившие (только поступившие, либо измененные) записи и наводит
порядок у себя. В случае совпадения человека но различия ключа твоей базы
возникает коллизия. В таком случе побеждает та запись у которой дата создания
или коррекции старше, либо выбирается случайно. Теперь ты возвращаешь назад либо
новый ключ на который нужно изменить посланную запись либо некий значок Ок.
И так - последовательно с каждой базой.
Примерно таким способом я синхронизирую БД у себя. Прогнозируется БД в среднем
по 5 млн. записей по каждой из 7 последовательно релированных таблицах.
Сеть - коаксиал! С сервером тут никак не развернуться. Пришлось разработать
псевдорепликацию (приблизительно такую) что позволяет быстро доступаться к БД и
синхронизировать БД не то что в областном а в республиканском масштабе (!)
Причем синхронизацию можно проводить с частотой от 1 мин. до нескольких дней,
что практически мало влияет на трафик 10 МБитной сетки. А, если сеть не работает
- то абче - можно дискетками синхронизировать - ведь за день (да что там день) -
неделю инфы - на дискетку очень мало.
IS> Как я догадываюсь,
IS> номер пенсионого страхового свидетельства есть попытка получения
IS> такого
IS> ключа, кто-нибудь в курсе как этот номер получается? -- Примите заверения
IS> и проч. Игорь Шмидт
В послесловие - не пытайся привязываться к такого рода номеру - очень часто
номера путаются, забываются.
А этот вариант, не смотря на кажущуюся громадность - очень надежный способ
избежать неоднозначностей и головных болей и значительно упрощает процедуру
ввода новых данных оператором (продуктивность в данном случае повышается в 2-3
раза). А это - бонус тебе ка программисту. :)
Всех благ!
Victor
---
* Origin: ---> The Golden Wizard <--- (2:4621/14.110)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
