спасибо!

кстати, не надо бояться тупых алгоритмов "в лоб" типа полного перебора.
вполне вероятно, что на твоих объёмах оно будет решаться за вменяемое время.
конечно, реализовать это надо будет не на РНР, а на чём-то побыстрее типа C/C++/Rust

Возможно и на php оно решаемо полным перебором. Если брать 8 пыху, то там оч быстро работает все

Нужно исходить из начальных вводных

Вместо постоянного спама мог бы уже нагуглить решение

Снова Ты? Вместо бла бла помог бы лучше

Я бы помог, так для поиска проблеммы надо поднимать проект. За это мне обычно деньги платят

Да не нахожу я.

Покажи скрин консоли. Покажи скрин данных которые прилетают… та наконец попробуй погуглить хоть как дебажить свой же код))

Я только учу

Группой ошиблись тогда

Спасибо

Пожалуйста

🙏

😂😂😂

Почитайте «Грокаем алгоритмы» — там разложена похожая задача в двух вариантах решения

Всем привет. Юзаю Laravel 7.3. Может кто нибудь сталкивался с такой ситуацией. У меня есть маршрут для получения списка объектов: {{domain}}/api/v1/customers?sort=price&direction=asc&offset=0&limit=30 и когда отправляю его еще раз, что бы получить следующие 30, то могут быть объекты с теми же id. В контроллере похоже на это:

$customers = Customer::with('realtor.departments')
           ->whereHas('realtor.departments', function ($query) use ($departments)      {
               $query->whereIn('department_id', $departments);
           })
          ->orWhereNull('realtor_id');
           ->sortable()
           ->offset($offset)
           ->limit($limit)
           ->get();

Правильно, потому что в текущую выборку, вернее в предыдущую порцию, могли добавится новые айдишки, который сдвинули этот индекс и юзер был в твоей выборке 30й, а стал 31й и вот он дваждый и попал на выгрузку

Это все дело в пагинации лимитами и офсетами