алгоритмы выборки похожих фио

← →
Ega23 © (2015-05-05 18:42) [80]

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

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

← →
Edgar_Wine (2015-05-05 21:01) [81]

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

← →
Ega23 © (2015-05-06 00:09) [82]

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

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

← →
Игорь Шевченко © (2015-05-06 10:22) [83]

Дмитрий (05.05.15 14:53) [78]

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

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

← →
Edgar_Wine (2015-05-06 14:52) [84]

Я думаю что всё надо решать по ситуации. Просто предложил ТС, как вариант. Не думаю что у него АЭС.
От ~20 до ~1500 более чем нормально себя показал вариант, за больше сказать не могу, пока не требовалось столько. А дальше пусть он сам оценивает подходит под его ситуацию или нет.

← →
Дмитрий (2015-05-06 17:21) [85]

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

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

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

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

← →
Edgar_Wine (2015-05-06 17:55) [86]

м.. Вот тогда видно что к данному случаю не подходит.
Возможно оставить "задвоение" на совести операторов (но история операций пригодится), и просто разработать функционал аля "Merge Персон"?
Указываем что мол этот и этот есть одно и то же, а система пусть оставит одного, второго грохнет (с учётом всех нюансов связей).

← →
Ega23 © (2015-05-06 19:24) [87]

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

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

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

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

← →
Игорь Шевченко © (2015-05-06 21:42) [88]

Дмитрий (06.05.15 17:21) [85]

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

← →
Ega23 © (2015-05-06 22:00) [89]

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

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

← →
Edgar_Wine (2015-05-06 23:26) [90]

Приходилось. В нераспределённых/облачных правда, обычных. А при восстановлении бэкапа поля "удалено" не сотрутся что ли? Просто всё откатится "как было до удаления".
Как можно восстановить bak чтоб удалённые записи не восстановились, а в поле "удалено" осталось новое значение?

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

← →
Ega23 © (2015-05-06 23:41) [91]

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

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

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

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

← →
имя (2015-10-20 18:00) [92]

Удалено модератором

← →
имя (2015-10-20 20:07) [93]

Удалено модератором

← →
имя (2015-10-20 20:39) [94]

Удалено модератором

← →
имя (2015-10-20 20:41) [95]

Удалено модератором

← →
имя (2015-10-20 20:50) [96]

Удалено модератором

алгоритмы выборки похожих фио Найти похожие ветки