Доброго времени суток. У меня такой вопрос. Стоит задача отображать магазины в радиусе 5,10,15 км от точки которую укажет пользователь (по ZIP коду). В базе координаты магазинов хранятся в geo_x (float) и geo_y (float). Я вижу выборку магазинов по координатам как указание координаторов квадрата, центр которого координаты местонахождения пользователя, после чего я проверяю расстояние между магазином и пользователем по формуле нахождения длины отрезка по координатам. Вот тут и сам вопрос. Может было бы лучше после нахождения расстояния между пользователем (ZIP кодом) и магазином записывать результат в БД что бы в след. раз по этому Zip коду не проводить таких манипуляций. Но при таком варианте мне нужно будет хранить все используемые Zip коды и при добавлении нового магазина рассчитывать расстояние между магазином и всеми использованными Zip кодами. Так вот, как лучше использовать БД для хранение инфы или пересчитывать её при каждом запросе?

Сделайте кэш по зип коду и очищайте его при добавлении новых магазинов.

_____________
Senior PHP developer: PHP5, MySQL, JavaScript, CakePHP, Yii/Yii2, Zend Framework, Smarty, XML/Xslt, JQuery, Jquery Mobile, Bootstrap, ExtJS, HTML, HTML5, CSS, Linux, SVN, Git, Memcached, Redis, MongoDB, Zend Guard, Ioncube, FFMpeg, PayPal, Webmoney, Qiwi, Facebook API, Vkontakte Api, Google API, Twitter Api, Steam Api.
Junior Android Developer: Android SDK, многопоточность, работа с HTTP запросами, JSON, SQLite, фрагменты.

имеете виду memcached? Таким образом кеш долго жить не будет, так как возможен вариант частого добавления магазинов.

С кэшем стоить мутить в том случае, если выборка слишком тяжелая.
ПО опыту могу сказать, что при наличии 2к строк(объектов) в БД запрос подобного рода отрабатывает достаточно шустро.

_____________
Mysql, Postgresql, Redis, Memcached, Unit Testing, CI, Kohana, Yii, Phalcon, Zend Framework, Joomla, Open Cart, Ymaps, VK Api

Я бы просто хранил в базе расстояния от магазина к точке, привязанной к индексу. Т.е.:
id | store_id | zip_id | distance

PS: Запрос по двум int-полям с индексами будет проходит мгновенно и по многомиллионной таблице. Плюс, сверху можно наложить грамотный memcached с тэгированием, дабы всё не сбрасывать при одном добавлении.

_____________
Блог | VK | GitHub | Twitch

а если подобных пар будут 10к? просто выходит связь 1к1 и на 1 код будут все магазины.

AlmazDelDiablo это извращение. ПРедставь сколько отношений получим при наличии даже 1000 объектов...И тут адрес одного объекта изменился...


_____________
Mysql, Postgresql, Redis, Memcached, Unit Testing, CI, Kohana, Yii, Phalcon, Zend Framework, Joomla, Open Cart, Ymaps, VK Api

AlmazDelDiablo
Да я так и планировал, но тут получаешься лишняя нагрузка. Если магазин находиться больше чем макс значение фильтра (15 км), то работать с ним не нет смысла. если будет много магазинов, то при таком алгоритме (проверять дистанцию до каждого магазина) пользователь может и не дождаться ответа. Если работать по значению фильтра (когда магазин еще не занесен в БД) то нужно будет все равно делать подвыборку (на тот случай если фильтр будет изменен в большую сторону.) что бы занести новые магазины. Проще при добавлении магазинов, мы просто работаем во всеми использованными zip кодами.
П.С. у меня нет списка zip кодов, база пополняется ими по мере их использования.

Можно выгрузить объекты в таблицу MEMORY(если речь о Mysql). При обновлении обновлять основную и memory таблицу, читать из MEMORY, ну и сопоставлять основную и MEMORY таблицу(достаточно по моему проверить MEMORY таблицу на наличие записей).
По крайней мере читать из ФС уже не придется.

_____________
Mysql, Postgresql, Redis, Memcached, Unit Testing, CI, Kohana, Yii, Phalcon, Zend Framework, Joomla, Open Cart, Ymaps, VK Api

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

Имеет смысл, если упираемся в производительность. Если нет, то нечего проблемы создавать из ничего.

_____________
Mysql, Postgresql, Redis, Memcached, Unit Testing, CI, Kohana, Yii, Phalcon, Zend Framework, Joomla, Open Cart, Ymaps, VK Api

T1grOK в производительно упираемся, это само собой. Вот ли будет профит если через таблицу кешей делать выборку.

Алгоритм в студию. У меня сомнения что алгоритм оптимален. Все делается одним запросом к БД.

_____________
Mysql, Postgresql, Redis, Memcached, Unit Testing, CI, Kohana, Yii, Phalcon, Zend Framework, Joomla, Open Cart, Ymaps, VK Api

T1grOK все описано в начале.

ПО словам как то код не просматривается)

_____________
Mysql, Postgresql, Redis, Memcached, Unit Testing, CI, Kohana, Yii, Phalcon, Zend Framework, Joomla, Open Cart, Ymaps, VK Api