Приветствую всех!!! Может кто дать дельный совет по организации структуры! Необходимо собрать

сервер адресный за основу взята ГАР (государственная адресная система).
В архиве 92 папки + Байконур. В каждой папке по 18 xml файлов. Внутреннюю структуру я более-менее знаю, так как общался со старой базой ФИАС (которая ушла в небытие или уйдет) и сейчас требуется перейти на новый стандарт.
Раньше ФИАС крутился на MySQL - но я хочу попробовать PostgreSQL в бою.
Например: есть xml файл "adr_obj" в нем хранятся субъект, города, поселки, улицы и т.д. Соответственно имеется ID и OBJECTID - которые м/у собой связывают строки в рамках одной таблицы в связи с чем можно собрать полный адрес: "Субъект, город, улица" просто написав функцию и дернув функцию получаем в переменную адрес полный. Опытным путем было выявлено, что дергать данные через функции быстрее чем делать кучу запросов из backend (например: при получении полного адреса).
В файле "adr_obj" нет столбца регионID, cityID, streetID - но раньше я делал процедуру и на уровне БД в MySQL проставлял ID всех элементов, что позволяло удобно делать запросы в БД. Это удобно так как в нашем государстве может у адреса например: не быть улицы, или не быть поселка.
Вся БД весит 272 ГБ в виде xml - она ужмется при переносе, но все равно будет достаточно объемной - поиск будет долгим без индекса.

И вот у меня есть 3 варианта:
1. Наделать таблиц adr_obj_[код региона] получиться 93 таблицы и объединить данные в представлении. Но встает вопрос можно ли по представлению делать индексы?
В этом случае сперва можно будет определить регион (или регионы), а потом делать запросы в меньшего размером таблицу соответствующего региона.
При таком подходе таблиц будет 18 * 93 = 1674 таблицы, потому что есть еще таблицы HOUSE (дома) ROOMS (квартиры). Т.е. от 1674 таблиц.
2. Или все таки, как раньше сделать, все 93 файла xml импортировать в одну таблицу adr_obj - она будет большая длинная, селективность низкая.
3. Еще можно полностью переконфигурировать подход и поднять селективность через дополнительную связывающую таблицу (-ы), например "улица Ленина" - есть в каждом городе и поселке. Сделать это для запросов с LIKE где ищем по названию. Но есть и факторы усложняю данный подход, так как может быть "бульвар Ленина". Вообще все улицы в нашей преимущественно православной стране повторяются. Уникальных названий не так много по старой тестовой БД 1512420 (не все регионы вроде там) из них уникальных значений [тип элемента инфраструктуры] + [название элемента инфраструкты] получается 414360 - т.е. в три раза.

С одной стороны одна таблица удобна.
Сценариев эксплуатации адресного сервера много. И у меня тут зоопарк из разных скриптов на разных языках сделанные разными людьми, один разбирает адрес из строки, другой выдает на основе адреса данные статистики. И я хочу все переписать на нативный rest php (а все что возможно в силу синтаксиса сделать силами самой БД). Хочу убрать остальной зоопарк - унифицировать подход к получению данных.

Вот сижу голову ломаю. Заранее благодарю за советы.

Пункт 3 точно не надо делать, а пункт 2 вполне. Одна таблица, все индексы которой начинаются с region_id лучше, чем 93 таблицы