Comments 8
Волею случая мне довелось поработать с адресным реестром в форматах ФИАС и ГАР. Поэтому задам пару вопросов.
Адресный реестр в ГАР фрмате доступен в двух вариантах: полный слепок базы и дельты измений. Вы предолагаете периодическое обновление данных из дельт?
Ограничение `is_active = true` , по моему опыту, недостаточное. В данных административной иерархии я находил записи объектов, родителем которых были записи со значением `is_actie=false`. Находил случаи, когда актуальной является не последняя запись в цепочке изменений, а одна из предыдущих. Вы проводили анализ данных на предмет достаточности условия `is_active = true`?
Здравствуйте!
Вы предолагаете периодическое обновление данных из дельт?
Да, я планирую периодическое обновление данных из дельт. Но пока не подходил к изучению этого вопроса. Планирую в скором будущем.
Ограничение `
is_active = true` , по моему опыту, недостаточное.
Да, всё верно. Я упомянул об этом в статье. Началось всё с того, что я вообще не стал загружать неактивные данные в свою базу. Первые грабли сработали очень быстро. Нашлось несколько домов, для который данные были в is_active = false, но is_actual = true. Пришлось загружать ретроспективу и писать метод, который «актуализирует» подобные данные. Алгоритм «актуализации» приведён в статье, после 9-го рисунка. Также он реализован в готовом приложении.
Ммм, мне думается, что ваш способ "актуализации" неверный. При получении каждой новой очередной дельты вы будете обязаны проводить поиск и повторную актуализацию таких записей. При этом весьма вероятно появление коллизии, когда две записи (отмеченная вами как активная и запись о том же объекте, но с другим GUID и отмеченная как активная в базе адресного реестра ФНС) будут значиться как актуальные. При работе пользователя с такой адресной базой появятся ошибки идентификации одной из нескольких адресных единиц как единственно верной для использования в ваших бизнес процессах.
Доброе утро!
Я не ставлю задачу найти и разрешить все коллизии в базе ГАР. Я исхожу из предположения, что база ГАР верна, а коллизии возникают по причине того, что компании и юр. лица не озабочены актуализацией информации.
Разрешаю коллизии я точечно. Появился дом, который я не могу сопоставить с базой ГАР — принимаю решение по этому дому. Бывает, что контрагенты не указывают или не знают кода ФИАС, тогда задача решается от противного.
мне думается, что ваш способ "актуализации" неверный
Для описанного мною случая — верный.
При получении каждой новой очередной дельты
Спасибо, познавательно, но как я упомянул выше, пока я не подходил к изучению дельты.
При работе пользователя с такой адресной базой
Пользователь не работает с этой адресной базой. В заголовке статьи говориться о нормализации собственной адресной базы. В процессе работы я создаю собственные справочники, в которых актуализировать практически нечего. За исключением случаев переименования городов и улиц.
Ещё раз здравствуйте!
В прошлом комментарии я написал, что «актуализация для моего случая» верная. Но потом заметил, что о том, какой случай используется, не указано в статье, только в контексте комментирования.
Я добавил примечание в текст статьи. Ещё раз спасибо за интересный комментарий.
из которого убрали все переводы строк и пробелы. Для чего так сделано — непонятно.
Почему ж не понятно, очень даже понятно: меньше места занимает в распакованном виде. XML не предполагает человеческого чтения, а для машины без разницы есть там пробелы (на них ещё и время при обработке тратить надо) или нет
меньше места занимает в распакованном виде
Резонно.
XML не предполагает человеческого чтения
Рекомендации W3C говорят об обратном: https://www.w3.org/TR/2006/REC-xml11-20060816/
1.1 Origin and Goals
...
The design goals for XML are:
XML documents should be human-legible and reasonably clear.
Любой beautifier превратит этот xml в human-readable, если уж возникла необходимость прочитать. И это не рекомендации, а цели разработки XML (когда не было ничего, и вдруг что-то надо бы универсальное сделать, то вот хорошо б чтоб человеку немного удобнее было). И XML в одну строчку без пробелов сюда всё ещё подходит - он чисто текстовый, границы тегов понятны (даже начало и конец отличаются), где значения тоже понятно, ещё и пробелы не надо считать
Я даже не предполагаю кому б понадобилось вручную читать этот файлик в поисках какой-то там улицы. Я как-то пробовал в ФИАСе ручками поискать и это было очень неудобно, благо, что в деревне три улицы крестом, а не благо, что таких деревень несколько в области
Импорт базы ГАР для нормализации собственной адресной базы в Laravel 10. Часть I, исследуем выгрузку ГАР