Мастера DELPHI, Delphi programming community Рейтинг@Mail.ru Титульная страница Поиск, карта сайта Написать письмо 
| Новости |
Новости сайта
Поиск |
Поиск по лучшим сайтам о Delphi
FAQ |
Огромная база часто задаваемых вопросов и, конечно же, ответы к ним ;)
Статьи |
Подборка статей на самые разные темы. Все о DELPHI
Книги |
Новинки книжного рынка
Новости VCL
Обзор свежих компонент со всего мира, по-русски!
|
| Форумы
Здесь вы можете задать свой вопрос и наверняка получите ответ
| ЧАТ |
Место для общения :)
Орешник
Коллекция курьезных вопросов из форумов
Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / rsdn.org

 
Чтобы не потерять эту дискуссию, сделайте закладку « предыдущая ветвь | форум | следующая ветвь »

Профайлы клиентов в автоматизированной системе


DayGaykin ©   (14.12.18 13:24

Есть некий бизнес у которого есть клиенты, много клиентов.

И вот архитектор создает логичную структуру базы данных:
- Клиенты;
- Заявки, которые ссылаются на клиента.

В таблице клиентов все "чинно-благородно". ФИО, дата рождения, паспорт, контакты.

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

Вот и получается база в которой один человек может быть забит много-много раз. Что, конечно не нравится архитектору да и вообще никому не нравится.

Вопрос, как быть? Какие в этом направлении лучшие практики?


ухты ©   (14.12.18 14:17[1]

А вы автоматом себе в базу заливаете? А зачем?


ухты ©   (14.12.18 14:19[2]

Еще вопрос про архитектора... это вы штоле? или почему не он этим занимаетеся?


Inovet ©   (14.12.18 15:08[3]

Для отсева некоторой части повторов можно проверять какие-то данные о клиенте, которые обычно обязательные, и имеют внутреннюю проверку валидности, ИНН - его сложно ввести криво при наличии проверки. СНИЛС, если физ лицо, тоже с проверкой. Вот паспорт не додумались так сделать, слова по этому поводу произносить не буду, но в 21 веке же, блин, вводили новый паспорт.


KSergey ©   (15.12.18 11:49[4]

Во-первых, ясно дать понять, что архитектор существует для бизнеса, а не бизнес для архитектора. (А то почитал тут статейку на хабре, где чувак гордился, как он у "тупых менеджеров" выбивает себе и друзьям з/п, причем упорно апеллируя к тому, что менеджеры - тупые; смешно, короче.)

Что касается описанной ситуации (именно в той последовательности, как описано), то с учетом

> Когда клиент приходит, его профайл, конечно корректируют,

лично я бы предложил создать фоновую процедуру, которая бы раз в сутки, например ночами, бегала по базе и по каким-либо критериям сопоставляла клиентов, выявляя дубликаты. А далее условной девочке вменить в обязанность просматривать найденные возможные дубликаты и в случае, если девочка согласна с тем, что это дубликаты - то все сущности подвязывать к одной из записей (возможно, указанной как "главной" девочкой), а дубликаты удалять. (В интерфейсе непременно учесть, что могут быть тройственные совпадения и более.)
Алгоритм поиска дубликатов постепенно улучшать (на примерах из практики) как в сторону уменьшения ложных срабатываний, так и в сторону более хитрых способов выявления дубликатов.
Каким-то образом позволить девочке отмечать  "это не дубликаты, блин!!", дабы она каждый день не просматривала одни и те же ошибочно найденные пары.

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

> но и тут могут ошибиться.

Вот это не понял, признаться.
Если ошиблись - ну счастья-то не будет. хоть на этапе первичного заведения данных, хоть на этапе их корректировки. Не понятно что тут вообще возможно сделать.
Ну разве что приделать распознавание паспорта, где-то такие видел/читал, дабы уменьшить кол-во ошибок при первичном вводе данных.


FreeAndNil ©   (15.12.18 14:27[5]

ночные субботники. явка всех роботов предприятия строго обязательна.
все готовят данные для дневного принятия решения людьми.
https://dadata.ru/api/


manaka ©   (15.12.18 19:44[6]


> И вот архитектор создает логичную структуру базы данных:


А уникальный идентификатор клиента архитектор не придумал.
А проверять записи при интеграции сторонних баз программист не догадался.
А бить по рукам пользователей, которые забивают паспорт 111111 начальнику лень.


> Какие в этом направлении лучшие практики?


Все сжечь и переделать.


Тимохов Дима ©   (15.12.18 19:52[7]

Мое имхо:
1. Наведение порядка в данном случае - ручной труд.
2. Дать возможность оператору, наводящему порядок, хорошие инструменты:
  а. Поиск возможных кандидатов на объединение.
  б. Удобным механизм слияния.


KSergey ©   (15.12.18 22:19[8]

> manaka ©   (15.12.18 19:44) [6]
> А бить по рукам пользователей, которые забивают паспорт
> 111111 начальнику лень.

Сказано же: сторонний сервис. Кому по рукам бить?

> manaka ©   (15.12.18 19:44) [6]
> Все сжечь и переделать.

Молодой ты еще, горячий. Всё бы "переделать" всех кругом.


Тимохов Дима ©   (16.12.18 00:17[9]

Добавлю. Вообще, такие вещи решаются имхо в директивном порядке:
а. Выбирается сотрудник, ответственный за порядок.
б. Ему вменяется в обязанность наведение порядка.
в. Ему даются средства наведения порядка.
г. Придумывается критерий успешности его работы.

Человека еще рано списывать в утиль. Как-то так.


картман ©   (16.12.18 01:32[10]


> Какие в этом направлении лучшие практики?

Вот, книжку рекомендуют: https://www.ozon.ru/context/detail/id/19613873/


niteshade ©   (19.12.18 11:56[11]

>manaka ©   (15.12.18 19:44) [6]

>А уникальный идентификатор клиента архитектор не придумал.
допустим, придумал
и архитектор сторонней системы придумал
и эти два идентификатора даже совпадут
с вероятностью, стремящейся к нулю

>А проверять записи при интеграции сторонних баз программист не догадался.
в исходной системе: 50 01 111111 Иванов Иван Иванович
в сторонней: 50 01 111111 Петров Пётр Петрович
в какой из систем ошибка?
проверяйте, нам не жалко

>А бить по рукам пользователей, которые забивают паспорт 111111 начальнику лень.
1. системы сторонние;
2. от ошибок ввода никто не застрахован.

>Все сжечь и переделать.
такие переделкины с гордо поднятой головой идут на рынок труда, подгоняемые ветром
из головы


KSergey ©   (19.12.18 19:47[12]

> niteshade ©   (19.12.18 11:56) [11]
> такие переделкины с гордо поднятой головой идут на рынок
> труда, подгоняемые ветром
> из головы

Они вполне успешны
Так что не стоит завидовать )


niteshade ©   (21.12.18 08:02[13]

>KSergey ©   (19.12.18 19:47) [12]
>Они вполне успешны
>Так что не стоит завидовать )
мнение не изменю
завидовать не перестану)


ухты ©   (22.12.18 00:12[14]

чем же дело кончилось ...


DayGaykin ©   (26.12.18 15:41[15]

Пока идея такая.
Будут профайлы проверенные и непроверенные.

Когда от внешней системы приходит заявка, для нее создается непроверенный профайл.

Когда администратор будет обрабатывать заявку он увидит, что профайл не проверен и сделает одно на выбор действие:
1. Пометит профайл как проверенный и корректно заполнит его.
2. Выберет на свое усмотрение уже существующий проверенный профайл, а непроверенный полностью удалится.

Для того, чтобы администратор мог выбрать правильное действие, ему в интерфейсе будет показан список всех проверенных профайлов, которые так или иначе по разным наборам признаков совпадают в исходным непроверенным.


ухты ©   (26.12.18 21:27[16]

уболтали архитектора? ))


KSergey ©   (27.12.18 07:04[17]

Его просто убрали.


версия для печати

Написать ответ

Ваше имя (регистрация  E-mail 







Разрешается использование тегов форматирования текста:
<b>жирный</b> <i>наклонный</i> <u>подчеркнутый</u>,
а для выделения текста программ, используйте <code> ... </code>
и не забывайте закрывать теги! </b></i></u></code> :)


Наверх

  Рейтинг@Mail.ru     Титульная страница Поиск, карта сайта Написать письмо