@Garde2

База недвижимости. Проектирование расположение(страна, город, ...)?

Проектирую базу для недвижимости. Недвижимость будет продаваться в разных странах. Возник резонный вопрос, как в базе хранить место расположение недвижимости, чтобы потом не возникло проблем с поиском.

Хранить Страну, город, район в каждой таблице, а потом ссылаться в таблице недвижимости, а улицу делать текстовыми? Мне кажется данный вариант избыточен.

Хранить координаты? Но как потом реализовывать поиск, вывод недвижимости для определенной страны, города?

Пока что есть только две такие идеи, есть ли более идеальный вариант, и какой, чтобы потом он не обернулся в проблему?

Заранее, спасибо
  • Вопрос задан
  • 131 просмотр
Решения вопроса 2
kawabanga
@kawabanga
Бью себя по рукам за каждый ответ на глупый вопрос
Интересный вопрос.

Вы смотрели варианты международных сервисов? Airbnb / booking думаю лучше всего подойдут для вашей задачи.
Посмотрите как они интегрируются с адресами.

У вас есть два абсолютно разных варианта подхода к архитектуре.
1) Использовать базу даных адресов всего мира. Она большая, у каждой страны есть разные правила составления адреса. Район, Подрайон и тд. Т.е. адаптировать все равно придется.
+ возможно вам придется использовать платную базу, и тут будут вопросы.

2) Подход, с использованием сервисов гугл. Он платный, но решает проблему по разработке и поддержке базы.
К примеру, при заполнении адреса, вы вводите адрес любый человеческим способом, а гугл карты сами редактируют и форматируют адрес по тем правилам, что вам нужны.
Обратите внимание на GIS типы данных , такие как POINT.

На стороне пользователя, при поиске - человек может отталкиваться от места где он сейчас находится, а вы ему в зоне видимости объекты показываете. (а это предпочтительный вариант работы вебсайта с недвижимостью - приоритет карты).
Он может ввести следующие запросы, которые гугл подправит и тоже самое на английском языке -
Новосибириский район.
Новосибирск
Новосибирск центральный район

через АПИ мы запрашиваем многоугольник зоны, и уже ищем на нашем сайте.

Ну а по кол-ву текста вы можете понять, какой вариант интересней и проще.
Ответ написан
Комментировать
DmitriyEntelis
@DmitriyEntelis
Думаю за деньги
Координату хранить нужно 100% как свойство объекта, но дальше дьявол в деталях - полный адрес в каждой стране (да и даже в рамках одной страны) может задаваться оооочень сложной логикой, даже рекурсивно (в рф например может быть поселок как часть города, причем может находиться как далеко-далеко, так и внутри границ)
Но по большому счету максимально полный адрес и не нужен, нужно чтобы было понятно пользователю + работало seo.

С точки зрения базы:
Координату объекта хранят все (как его свойства)
Логично что город - отдельный объект в базе (3НФ никто не отменял), а вот какие свойства у него - зависит от бизнес-логики уже вашей.
Циан хранит тупо название с координатами центра.
У нас есть travel проект по всяким весям рф и сопредельных - мы храним развернутый объект страна-регион-район-тип(город,село, пгт, etc)-название-координаты, где страна/регион/район это тоже справочники в бд.

В общем и целом алгоритм такой:
1. выбрать используемое картографическое решение: google / osm / итд
2. изучить их reverse geocoder, структуру его ответа
3. на основе этого, а так же планируемого расположения объектов недвижимости определить структуру вашего гео-объекта.
Ответ написан
Комментировать
Пригласить эксперта
Ответы на вопрос 2
@pfg21
ex-турист
хранить, и то другое, взаимно не мешает.
в работе делать выборку по тому варианту который требуется.
один пользователь захочет выборку по городам, другой захочет мышкой квадратик накарте выделить...
вариант2: в таблице хранить что-то одно а во внешнем источнике связку со вторым вариантом поиска
Ответ написан
Комментировать
LaRN
@LaRN
Senior Developer
Если захотите делать выборки по районам, то вариант с координатами не пройдёт, для выборки лучше иметь все составляющие адреса у себя.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы