Comments 4
Собственно задача состоит в том что бы сгруппировать почтовые индексы всех домов и взять минимальный индекс как индекс собственно населённого пункта (индекс населённого пункта обычно заканчивается нолями, у подчинённых почтовых отделений индексы заканчиваются цифрами от 1 до 9).
Это явно ваше собственное изобретение, и оно, увы, имеет массу исключений. Вплоть до полной его неправильности.
Например, город Зеленоград. Который хоть административно и является округом города Москва, но территориально - это самостоятельный город. В самом Зеленограде имеется 11 почтовых отделений со своими индексами, причём никакой из индексов не оканчивается несколькими нулями (есть один из них, оканчивающийся одним нулём, но у этого почтового отделения нет ну никакого приоритета). То есть методика отбора по нулю даст результат либо пустой, либо не имеющий смысла. А если, вопреки логике, получить для города индекс не по территориальной, а по административной принадлежности, получим Главпочтамтовский 101000, что тоже далеко от истины.
По моему мнению, более правильным будет собрать все индексы населённого пункта. И при использовании полученных данных дополнительно помечать минимальный/"многонулевой" как возможно приоритетный.
По этой выгрузке, заказчик проверил, ему подошло, были бы замечания - были бы доработки. Можно строить вложенность по иерархии муниципалитетов, одну табличку на другую поменять, и всех дел.
Индексы у домов, дома не образуют между собой иерархии, они просто нижний слой в адресных объектах, поэтому ни какой вложенности, "многоуровневости" по индексам не возможно получить. Мне в выборке для населённого пункта надо было хотя бы какой то получить, можете доработать выборку своим алгоритмом, брать не min(), брать max(), написать case любой сложности или обойтись if, дело ваше.
Приведённое решение не единственно верное, а только пример для ваших собственных решений.
Если вам для импорта БД из XML файлов не нужен PHP, если вы легко пишите хранимки, то пожалуйста поделитесь своими наработками. Для того статьи и пишутся. что бы обмениваться опытом.
Делитесь в комментариях своим опытом работы с ФИАС!
Из опыта, возможно, немного устаревшего.
Когда мне пришлось пару лет назад пообщаться с ФИАС/ГАР, я при импорте натолкнулся на следующую проблему. Некоторые текстовые поля содержали символы табуляции и знаков больше-меньше, преобразованные в HTML entities. Более того, некоторые полученные таким образом значения превышали лимит на размер поля, установленный в файле схемы. Соответственно для нормальной работы необходимо было выполнять импорт в поля увеличенного размера (дабы избежать обрезки значения), а после сырого импорта дополнительным запросом заменять entities на соотв. символы.
Соответственно хочется спросить - пофиксили ли эту проблему? Или данные в выгрузке до сих пор содержат подобные косячные значения?
По прочтении остался без ответа один вопрос - а нафига вообще во всём этом супе потребовался PHP? PostgreSQL прекрасно может и сам, без сторонних костылей, импортировать текстовую выгрузку, а затем распарсить XML функцией XMLTABLE()
Извлекаем почтовые индексы из ФИАС