@Maxval

Какой подход для вытаскивания данных из MySQL в PHP наиболее корректный для минимизации нагрузки и скорости?

603cc873e49d4423757199.png

Здравствуйте. Есть вот такой генплан выше, созданный в формате SVG - у него есть теги G + полигоны, которые через fill перекрашиваем по статусам. Вся информация хранится в файле php. Формат каждого из участка примерно такой:

<g id="_1" class="someclass" data-kadastr="номер_кадастра" data-sotki="кол_во_соток_земли">
<polygon class="status_green" points="цифры_обозначающие_расположение_участка">


Нас интересует сейчас - подстановка уже не inline из php файла, а уже из базы MySQL именно класса polygon для каждого из 700 участков. В примере - .status_green, может быть .status_red и прочие. Именно этот класс и отвечает за цвет участка. И этот класс для каждого из 700 участков хочется получать из бд правильно, так скажем используя best practices, если можно так выразиться.

data-kadastr & data-sotki могут оставаться в инлайн формате в php, без базы данных.

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

Моя теория:
у нас 700 участков, создаю MySQL базу, в которой в соответствии с ID каждого участка в базе есть строки - ID и STATUS (или же color, не важно). В ID храним цифру 1,2,3,4,5..... в соответствии с номером, в STATUS - храним просто код цвета (код класса) status_red / status_green / status_lightblue. Предположим, что я вручную заполнил данную базу и в ней все актуально хранится.

Вопрос 1 - верно ли я представляю архитектуру БД для данной задачи? Или есть другие более правильные варианты?
Вопрос 2 - какой подход использовать для получения всех этих данных и построения генплана из базы данных, что бы не было дикой нагрузки? Что бы скорость загрузки была не дико медленная. Тк в моей голове это 700 запросов к базе данных для каждого участка. (UPD - для всех участков генплана, 1 запрос на 1 участок, не правильно выразился)
  • Вопрос задан
  • 91 просмотр
Пригласить эксперта
Ответы на вопрос 1
@rPman
Воспользоваться нужно готовыми инструментами mysql spartial, кажется форматы там популярные, найти готовые либы для работы с ними из браузера будет не сложно.

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

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

Не нужно забывать и о проекциях, мир не на плоскости у нас, а значит запросы на попадание полигона в прямоугольник экрана становятся не простыми.
Ответ написан
Ваш ответ на вопрос

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

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