Номер известен заранее

Но честно, я не вижу смысла в данной ситуации отходить от AR. Чистый SQL имеет смысл, если идут очень сложные запросы, которые в контексте AR дадут нечеловеческий оверхед.

ничто заранее не известно.

а тут два запроса, а если номер объявлен ещё и как primary key - то такая выборка будет очень быстрой.

понял. спасибо

Согласен. Не такие ситуации оптимизировать надо. Ради -1 запроса...

в этих таблицах по 500к записей. и номер идет отдельно от id, т.к. номера не по порядку. по факту телефонные номера.

два запроса относительно быстро проходят

ну даже если не id, то индекс-то по номеру никто построить не мешает.

есть индекс. а если на чистом sql делать? быстрее будет?

мимо моделей

не будет.

ок

ну лично я ручным запросом делал, например следующую ситуацию:
--
есть грузовая станция, на станции контейнера, таблица container. там номер контейнера и всякие данные по нему.
контейнеры вывозятся автомобилями, таблица trip, там связка по containerId и всякие данные о рейсе - дата, номер машины, водитель и прочее.
нужно получить список контейнеров, которые сейчас находятся на станции.
это либо те, для которых вообще нет записи в таблице trip (рейса ещё не было), либо которые есть в таблице trip, но статус ещё не уехал (под погрузкой, рейс ещё только запланирован и т.д.).

вот там получалось два связных запроса с union и кучей условий. Делать это через AR было бы очень геморно.

не пользоваться сраными уиишными ассетами?

да и кто нынче в здравом уме пользуется бовером? наркоши :D

bower

не надо так в 2020 )

ну там где у меня был bower - всё копировалось. мож alias где-то не прописан.. мало инфы .как ИМЕННО не копирует..