Если так брутально, то да, будет 20 перекодировок, каждая по нескольку записей. Но это все же редкость, из-за того, что системы сильно дублируют функционал друг друга, и фактически есть несколько копий каждого бизнес-процесса.
Все же мне кажется, что направлений движений документа даже в таком случае будет меньше 20. Зачем, например, двунаправленная связь между СЭДом и Порталом или между Учетной Системой и Порталом?
В децентрализованном подходе изменения отслеживаются в каждой системе относительно друг друга. Казалось бы, их должно быть N*(N-1), то есть в пределе 20 для 5 систем, если мы считаем, в самого себя перекодировать не надо, при этом перекодировка может быть несимметричной.
Но их будет намного меньше. Скорее всего, около 5 и будет. Потому что в реальной жизни относительно каждого справочника каждая система является либо поставщиком данных, либо их потребителем. Редко когда и то и другое. Бизнес-процессы и потоки данных — преимущественно дороги с односторонним движением. То есть если у нас нет потока данных из системы A в систему B, то перекодировки A -> B не будет, и отслеживания изменений относительно этого мэппинга тоже.
МДМ-система с разными справочниками и классификаторами, которые являются эталонными и имеют все нужные атрибуты у объектов-записей этих контейнеров. Интегрированные сторонние системы имеют на своей стороне нужные полные/частичные копии эталонных справочников, имеют синхронизации.
Это только в теории хорошо звучит. На практике
(1) согласование эталонов происходит медленнее, чем изменение бизнес-потребностей, и
(2) внесение изменений в сторонние системы, чтобы они питались эталонами, либо не представляется возможным, либо требует неадекватных усилий.
Кроме того, сама цель сомнительная — нам ведь нужны не эталоны на самом деле, а возможность обмена информацией в направлении хода бизнес-процессов. Введение эталонов — это подмена цели, которая не упрощает задачу, а только усложняет ее.
«перекодировка» осуществляется централизованно, на шине, например
Почти всегда есть потоки данных, которые идут мимо шины. Например, ETL для аналитического хранилища. Если его пустить через шину, то за время перегрузки данных они успеют потерять актуальность.
На Улан-Удинской Ботанической домов в несколько раз больше, чем на Казанской Ботанической. Поэтому вероятность, что человек именно из Улан-Удэ в несколько раз выше, поэтому она раньше и показывается. Москва как центр вселенной не зашита, просто на ее улицах действительно много людей живет, поэтому московские адреса в конкурсе на вероятность и побеждают.
В данном частном случае точности до СПб бы хватило, чтобы предложить несколько подходящих вариантов с городами Петергоф, Сестрорецк и Ломоносов. Вообще, в случае с подсказками точности до региона достаточно, чтобы сократить пространство в 10-100 раз — это в пользовательском опыте дает качественную разницу.
Ботанических улиц в стране слишком много, чтобы всех их вывести в качестве вариантов. Поэтому сразу напрашивается два варианта:
1. Сужение пространства поиска по IP пользователя. С этим вообще большинство проблем снимается сразу.
2. Если объектов с названием слишком много, то в подсказки выводить не адреса, а продолжения этого слова.
Сначала реализуем первый вариант, если не окажется достаточно, то и второй. Вообще, по нашим наблюдениям, с улицы адреса начинают в основном москвичи )))
Приняли как риск до возникновения судебной практики. Согласно тексту лицензии (п. 3) получается, что даже публикация адреса в формате КЛАДРа является распространением компонента КЛАДР и запрещена. Что делает невозможным достижения целей использования, прописанных (п. 1). Думаю, что на волне инициатив государства по открытым данным и поощрению создания производных продуктов вероятность возникновения проблем с этой лицензией стремится к нулю.
Варианты отсортированы по вероятности, которая в общем случае зависит от количества проживающих в этом месте людей. Видимо, Чичеринская и Шахматова являются либо уникальными для Петергофа, либо в других сторонах на этих улицах меньше людей живет.
Все же мне кажется, что направлений движений документа даже в таком случае будет меньше 20. Зачем, например, двунаправленная связь между СЭДом и Порталом или между Учетной Системой и Порталом?
Но их будет намного меньше. Скорее всего, около 5 и будет. Потому что в реальной жизни относительно каждого справочника каждая система является либо поставщиком данных, либо их потребителем. Редко когда и то и другое. Бизнес-процессы и потоки данных — преимущественно дороги с односторонним движением. То есть если у нас нет потока данных из системы A в систему B, то перекодировки A -> B не будет, и отслеживания изменений относительно этого мэппинга тоже.
Это только в теории хорошо звучит. На практике
(1) согласование эталонов происходит медленнее, чем изменение бизнес-потребностей, и
(2) внесение изменений в сторонние системы, чтобы они питались эталонами, либо не представляется возможным, либо требует неадекватных усилий.
Кроме того, сама цель сомнительная — нам ведь нужны не эталоны на самом деле, а возможность обмена информацией в направлении хода бизнес-процессов. Введение эталонов — это подмена цели, которая не упрощает задачу, а только усложняет ее.
Почти всегда есть потоки данных, которые идут мимо шины. Например, ETL для аналитического хранилища. Если его пустить через шину, то за время перегрузки данных они успеют потерять актуальность.
1. Сужение пространства поиска по IP пользователя. С этим вообще большинство проблем снимается сразу.
2. Если объектов с названием слишком много, то в подсказки выводить не адреса, а продолжения этого слова.
Сначала реализуем первый вариант, если не окажется достаточно, то и второй. Вообще, по нашим наблюдениям, с улицы адреса начинают в основном москвичи )))
> У вас внутри системы есть деление на справочник имен и справочник фамилий?
Да, конечно.
>Добавляются ли автоматически новые фамилии/имена после ввода их в форму?
Нет, иначе справочники быстро замусорятся. Их пополнение — это отдельный процесс в hflabs.ru с комплексом мер по контролю качества.
> Как решается проблема составных имен/фамилий, типа «АЛИ ОГЛЫ»?
В сервисе разбора в dadata.ru оглы/кызы считается частью отчества. К подсказкам этот функционал не подключили еще. Запланировали на ближайшее будущее!
www.nalog.ru/rn77/program/all/kladr/
А какая граница по-вашему была бы более разумной для бесплатной версии?