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

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

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

алгоритмы выборки похожих фио [D7, XP, 2003]

Страницы: 1 2 3 4 5 >
Дмитрий © (2015-04-17 18:43:00)
Имеется таблица Персонал связанная с таблицей Предприятия.
Появилась потребность сохранять личные координаты контактов и бонусы при смене места работы
Добавили таблицу Персоналии с личными телефонами и бонусами.
Тут же возникла проблема- при добавлении новой записи в персонал требуется определить не существует ли такая личность в Персоналиях.
Во избежание многократного дублирования.

Какие существуют алгоритмы выборки похожих лиц, включая возможные ошибки в написании имен и перестановки типа "Иван Иванов" и "Иванов Иван"?

(2015-10-20 20:50:00) [1]
Удалено модератором

(2015-10-20 20:41:00) [2]
Удалено модератором

(2015-10-20 20:39:00) [3]
Удалено модератором

(2015-10-20 20:07:00) [4]
Удалено модератором

(2015-10-20 18:00:00) [5]
Удалено модератором

Ega23 (2015-05-06 23:41:00) [6]

> А при восстановлении бэкапа поля "удалено" не сотрутся что
> ли? Просто всё откатится "как было до удаления".

Не "восстановление из бэкапа", а разворачивание из актуального бэкапа параллельной БД, с последующим переносом ошибочно удалённых данных в боевую базу. Ручками.
Ещё тот гемор.

> А чем моё [86] "Merge" отличается от [88] "Слияние"?

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

Edgar_Wine (2015-05-06 23:26:00) [7]
Приходилось. В нераспределённых/облачных правда, обычных. А при восстановлении бэкапа поля "удалено" не сотрутся что ли? Просто всё откатится "как было до удаления".
Как можно восстановить bak чтоб удалённые записи не восстановились, а в поле "удалено" осталось новое значение?

А чем моё [86] "Merge" отличается от [88] "Слияние"? Это и переводится как слияние. %)

Ega23 (2015-05-06 22:00:00) [8]

> Игорь Шевченко © (06.05.15 21:42) [88]

Угу, я бы тоже так же делал

Игорь Шевченко (2015-05-06 21:42:00) [9]
Дмитрий (06.05.15 17:21) [85]

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

Ega23 (2015-05-06 19:24:00) [10]

> Вот тогда видно что к данному случаю не подходит.

Это из первого поста было видно.

> а система пусть оставит одного, второго грохнет (с учётом
> всех нюансов связей).

Вам, юноша, очевидно пока ещё не приходилось в авральном порядке поднимать бэкапы и восстанавливать удалённые по дурости данные.
Из таких баз нельзя данные удалять, их можно только спец.полем "удалено" помечать.

Edgar_Wine (2015-05-06 17:55:00) [11]
м.. Вот тогда видно что к данному случаю не подходит.
Возможно оставить "задвоение" на совести операторов (но история операций пригодится), и просто разработать функционал аля "Merge Персон"?
Указываем что мол этот и этот есть одно и то же, а система пусть оставит одного, второго грохнет (с учётом всех нюансов связей).

Дмитрий (2015-05-06 17:21:00) [12]

> Игорь Шевченко © (06.05.15 10:22) [83]
> если есть какие-то дополнительные данные отображаемые
> в форме персоны, то их и надо использовать для уникальности/неуникальности,
> а если данных нет, то оператору бессмысленно показывать
> список, он силой мысли не установит, это повторение ввода
> или новый уникальная личность.

Всегда есть какой-то перехлест/различие информации
Телефон поменялся, уже автоматом решение принять сложно
При необходимости оператор уточняет информацию и действует соответственно.
При этом всегда существует вероятность ошибок идентификации и первого рода, и второго.
И результат лени операторов.
Удасться снизить, так и хорошо.

> Ega23 © (05.05.15 18:42) [80]
> > У нас как бы различие персонала завязано на логин пользователяБаза
> персонала и база пользователей некой системы - это совершенно
> разные вещи. Иногда они могут совпадать, но это только иногда.
>

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

Edgar_Wine (2015-05-06 14:52:00) [13]
Я думаю что всё надо решать по ситуации. Просто предложил ТС, как вариант. Не думаю что у него АЭС.
От ~20 до ~1500 более чем нормально себя показал вариант, за больше сказать не могу, пока не требовалось столько. А дальше пусть он сам оценивает подходит под его ситуацию или нет.

Игорь Шевченко (2015-05-06 10:22:00) [14]
Дмитрий (05.05.15 14:53) [78]

И какой дальнейший алгоритм действий с этой формой персоны ?
Оператор ввел очередного Шмундяку Ивана Михайловича, ему открылся список где есть еще пара похожих, что он дальше должен делать и на основании чего решить, это повторение или уникальный человек ?

Я к чему - если есть какие-то дополнительные данные отображаемые в форме персоны, то их и надо использовать для уникальности/неуникальности, а если данных нет, то оператору бессмысленно показывать список, он силой мысли не установит, это повторение ввода или новый уникальная личность.

Ega23 (2015-05-06 00:09:00) [15]

> Это само собою, но вот решили не разделять - и всё вполне хорошо.

Вот есть концерн, например - РосЭнергоАтом. Вот у него всякого персоналу - тыщ 200 человек. Они разбросаны по разным предприятиям, а некоторые вообще в субподрядных организациях состоят. Там всякие электрики, монтажники, водители, пожарные, охранники, охранники охранников, слесари, уборщицы, маляры, бухгалтеры, особисты, делопроизводители отдела кадров, повара в столовой, инженера, главные инженера, профсоюзные работники и крановщики. Даже несколько плотников есть. И всё это на десятке АЭС, нескольких предприятиях по обслуживанию этих АЭС, а порой - даже на соседних блоках одной АЭС.
Ты реально думаешь, что вот каждый из них имеет некий волшебный логин в некую общую росэнергоатомовскую программу???

Edgar_Wine (2015-05-05 21:01:00) [16]
Это само собою, но вот решили не разделять - и всё вполне хорошо.

Ega23 (2015-05-05 18:42:00) [17]

> У нас как бы различие персонала завязано на логин пользователя

База персонала и база пользователей некой системы - это совершенно разные вещи. Иногда они могут совпадать, но это только иногда.

Edgar_Wine (2015-05-05 17:43:00) [18]
> бонусы при смене места работы

При смене? Бонусы? Отрицательные что ли? %)

У нас как бы различие персонала завязано на логин пользователя, уникальный, без пробелов и спец-символов, большинство предпочитают регистрироваться под числами типа 245, 1100.
То есть есть id записи (счётчик) и логин - основные поля. А опционально есть три необязательных поля Ф/И/О и одно вычисляемое, склеивающее их через пробелы. Заполняй, не заполняй, пиши любой текст. И люди при регистрации (в том числе киргизы и прочие) сами заполняют эти поля.

> похожих фио

Странный термин. Имя "Попугай" и имя "йагупоП" это как считать, похожие? С:

Дмитрий (2015-05-05 14:53:00) [19]
При обнаружении похожих записей ему будет показан список этих записей с возможностью открыть форму Персоны

Игорь Шевченко (2015-05-01 10:50:00) [20]
а как оператор узнает ?

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

Наверх

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