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

Question

[Maxval]

Здравствуйте. Есть вот такой генплан выше, созданный в формате 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 участок, не правильно выразился)

Comments

[FanatPHP]

Ты можешь объяснить, где тут "700 запросов для каждого участка"?

[Maxval]

FanatPHP, могу. Только не 700 для каждого, а 700 запросов для всех, что бы общий генплан вырисовался с правильными цветами. Скриншот - обрезок плана участков. Всего участков в районе 700 шт. Каждый polygon имеет класс, который отвечает за цвет. В моей неумной голове для этой задачи строится система, когда для каждого участка идет обращение к БД по поводу класса. В формате id 1 - получает класс .status_green, окращиваясь в зеленый. Второй запрос - к id 2 - получает класс .status_red, красится в красный.

Вот и хочу посоветоваться заранее, перед всей этой проектировкой у знающих людей, что бы по верному пути меня подтолкнули. Я понимаю, что 700 запросов делать - скорее неверно. Поэтому и прошу совета

[FanatPHP]

если тебе надо получить один участок, то запрашиваешь из БД один участок
Но если тебе нужно получить 700, то кто мешает запросить сразу все одним запросом?
Ты с БД что ли вообще никогда не работал?

[nokimaro]

Про то что можно вытащить все нужные данные одним запросом уже написали.
Я бы предложил ещё кеширование svg-файла.
Генерируете один раз svg по данным из БД и дальше отдаёте этот svg клиентам. Если что-то поменялось (перекрасили и тд) - генерируем новый svg с изменениями и тд.

Answer 1

[rPman]

Воспользоваться нужно готовыми инструментами mysql spartial, кажется форматы там популярные, найти готовые либы для работы с ними из браузера будет не сложно.

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

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

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