Здесь, в Италии, земля политически разделена на регионы, провинции и муниципалитеты. Например, я живу в городе Варацце, провинция Савона, в регионе Лигурия.
Я создал базу данных Firestore, которая принимает предприятия, адреса которых составлены, как в приведенном выше примере. Ничего сложного, так как я использую внешний сервис, который дает мне последовательные и правильные геоданные. Остальная информация о компании вводится пользователем.
Теперь мне нужно выполнить поиск в этой базе данных предприятий по региону и / или провинции и / или муниципалитету. Чтобы настроить пользовательский интерфейс с фильтром, мне абсолютно необходимо отображать только регионы, провинции и муниципалитеты, у которых есть бизнес, в базе данных, а не все доступные (к вашему сведению: в Италии 21 регион, 107 провинций и ~ 8000 муниципалитетов).
Глядя на inte rnet и здесь, на SO, я понимаю, что лучшая стратегия - создать новую коллекцию для хранения отдельных данных о местоположении, отделенных от коллекции предприятий, чтобы обеспечить более быстрый поиск. Поэтому каждый раз, когда я добавляю или редактирую компанию, я проверяю, существует ли ее регион, провинция и муниципалитет в «поисковой коллекции» (назовем ее так), а если нет, добавляю ее.
Но как структурировать эту коллекцию ?
Если я использую муниципалитет в качестве ключа, у меня будет быстрый поиск самого муниципалитета (вверху будет 8000 записей), но если мне нужно искать по региону или провинции, результат будет плохим потому что firestore не имеет возможности «отличить» результаты (что-то вроде SELECT DISTINCT province FROM geocollection WHERE Region='Liguria', если вы хотите визуализировать его в SQL), и я должен делать это на сервере или, в худшем случае, на клиенте (не вариант, это последний).
Я не знаю, если смотреть на регион и сохранять структуру регион -> провинция -> муниципалитет - это путь к go. Или поехать в провинцию, находясь на полпути между.
Другой способ - создать отдельную коллекцию для регионов, провинций и муниципалитетов.
Я спрашиваю, какое решение является лучшим, с точки зрения производительности и сложности данных.