выборка ближайших объектов

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

А никто и не спорит. Но данные эти должны быть не уникальными для каждого вызова, а общими для N вызовов. Достаточно общие, чтобы их выгрузка в кэш имела смысл для прироста производительности. Часто используемые данные всегда "горячие", те, что используются реже - со временем могут остывать и протухать. И да, он может хранить в себе не чистые данные из БД, а результаты выборок, если эта выборка пользуется спросом, а всякие соцсети так вообще хранят там и пользовательские выборки, которые дешевле хранить так, чем тянуть из БД, как, например, френдленту, я в курсе насчет всего этого. Но если выборка уникальна не только для каждого пользователя, но и чуть ли не на каждый запрос - кэш будет бесполезен. Он будет вечно полон заведомой тухлятиной, у которой единственный путь - на выброс.

 

Пока в order by

 

Хз хз, я б по возможности избегал этого.

 

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

А вот теперь, чтобы быть правым любой ценой ты начал скатываться в демагогию и присваивать мне тезисы, которые я не выдавал, с тем, чтобы победоносно их опровергнуть. Не надо так делать. Либо тут ошибка понимания, исходящая из того, что ты прочитал то, что я написал по-диагонали. Уж чем чем, а косноязычием я не страдаю. И многозначно стараюсь не выражаться.

Не было ни слова про "надо все необработанные данные выдрать и загнать в кэш". Было сказано лишь про то, что в случае, если из базы выбирать только широту и долготу объектов, кэш получится прикрутить и он будет прогреваться без проблем. Если же БД будет выдавать уникальные одноразовые конечные результаты, то добавить системе быстродействия, в будущем, за счет кэша, при такой архитектуре не получится. И, по возможности, лучше учесть это уже сейчас.

А ты прочитал то, что не было написано, просто потому, что не способен не спорить. Я ни разу не видел, чтобы ты не спорил. Спорил ради спора. Это не круто.

 

Парни, лень тему читать. Предложение использовать готовые координатные хранилища в СУБД уже было?

 

Нет. Я предложил вполне прямым текстом выбирать из этих 10к объектов те, что находятся от пользователя в квадрате NхN градусов. И сортировать по расстоянию уже на сервере. Эти вот объекты можно складывать в кэш. И те, что чаще востребованы, будут забираться оттуда. А те, что нет, с базы. А на стороне сервера уже делать все, что захочется.

Снова демагогия. Это не было сказано. Это первый страйк. После третьего Родент, в свое время, улетел, не обещав вернуться.
--- Добавлено ---

Геометри, поинты и полигоны? Если да, то было. Или ты о чем-то другом?

 

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

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

Об этом я и толковал.

 

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

 

Я уже несколько раз же написал. Посмотри, какой запрос у @vikrorpert используется. Он возвращает не объекты, а посчитанные с них значения. То есть он выбирает пачку, потом ее гонит через формулы, и то, что получилось, отдает клиенту.

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

Протухаемость этих данных будет просто феноминальная.
И кэшировать их нет никакого смысла.

Разве что...можно сделать оптимизацию и считать не от позиции клиента, а от квадрата, в котором он находится. Нарезать для себя карту города, скажем, на равные сектора. Проверять вхождение пользователя в сектор, после чего делать выборку, относительно этого сектора и/или смежных, если надо. Тогда действительно будет профит от кэширования уже посчитанных данных, потому как ключом будет квадрат, охватывающий разом определенную площадь, внутри которой выборка всегда будет актуальна, но посчитанные данные, разумеется, не будут иметь точность "до метра".

 

на прошлой неделе ганзал психует, сегодня - миксир. Че с вами?
--- Добавлено ---

я тоже так предлагаю

 

да, вот отличный кейс сейчас: у него скорее всего немного объектов, и он крайне хреново врубается в программирование. Вполне себе отличное решение на коленке, которое понятно.

 

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

 

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