Дмитрий

если тебе не надо это контролировать, то игнорировать
@$data->{'id'}

p.s. вторым параметром json_decode пропиши true, тогда результатом будет не object а array в нужном тебе виде, да и работать можно будет с ним $data['id']

Нужно проверять каждое значение перед использованием.
Смотрите в сторону конструкций empty($var), isset($arr['index']), $myVar = $input[123] ?? null и прочих

Не кодил на PHP 100 лет, точного ответа не подскажу. Однако идея, что статическая лямбда будет видеть меньше переменных -> проще для GC = уже кажется, как небольшая победа.

https://www.designcise.com/web/tutorial/what-are-s...
https://www.php.net/manual/en/functions.anonymous....

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

->get() ->first()
А вообще вопрос на уровне документации и легко ищется поисковиком, учитесь использовать источники.

так если температура меньше 60 градусов, чего им крутиться зря?) не вижу проблемы что-то)

В данном коде формируется массив в котором ключ массива задается из $row['key'], а значение из $row['value'].
$row['value'] в квадратных скобках для того, чтобы элемент массива был также массивом.

// исходная строка
$options[$k] = [$row['value']];
// означает то же самое, что
$options[$k] = array($row['value']);
// или
$options[$k][] = $row['value'];

В вашем случае используется короткий синтаксис для array(), который поддерживается с версии 5.4.

$array = array(
    "foo" => "bar",
    "bar" => "foo",
);

// Использование синтаксиса короткого массива
$array = [
    "foo" => "bar",
    "bar" => "foo",
];

Подробнее о массивах php здесь:
https://www.php.net/manual/ru/language.types.array.php

Выносите даты в отдельную таблицу:
Название таблицы: location_event_dates
id - идентификатор даты;
location_event_id - идентификатор из таблицы location_event (то, что у вас в вопросе)
event_date - одна из дат события (в формате даты, а не строки!)
Тогда будет нормальный поиск:

select le.id, le.locationid, le.eventid,
          led.event_date
from location_event le
join location_event_dates led on led.location_event_id = le.id
where led.event_date between :begin_date and :end_date

Стоит ли изучать sql, или же сразу заняться изучением ORM?

Все люди которые ратуют за использование ORM с годами все равно приходят к очень сильной
и мотивированной необходимости знать SQL. Этот язык сегодня является латынью баз данных.
Вы сможете говорить с бизнесом на одном языке если будете в переписке активно использовать
например язык DDL таблиц. Ваши аргументы будут выглядеть убедительно если в переписке будут
фрагменты например любой консоли MySQL, psql, SQL*Plus e.t.c. Короче знание SQL - это признак
джентльмена. Путь в приличное общество.

И наоборот, вы будете вообще НЕПОНЯТЫ если попробуете показать ORM объект на Node или не дай
бох на Java/JPA техниках аннотации. Бизнесу эти аннотации неинтересны и неинформативны.

Да и вам самомму смоделировать любой сложности выборку или отчет будет бытрее в SQL чем в фрейморках
ООП-отображения.

Что касаемо перформанса. К сожалению все современные ORM реализуют только самые базовые возможности
оптимизации запросов. Насколько я знаю Hibernate (по состоянию на 2015 год) так и не умел обращаться
с Oracle Hints. А любой сложный ентерпрайз начинается там где вы выжимаете из запроса не 100 а 1000%
возможностей. И здесь вам нужно управлять проприетарными функциями воздействия на оптимизатор.

Вообще для меня например цикл оптимизации ORM запросов начинается с того что я выбрасываю из
стека ORM. Заменяю на native. И долго наблюдаю его и оптимизирую. И когда достиг критерия готовности
то пытаюсь затащить обратно в ORM. Иногда не заходит. Это те случаи когда ORM оказался плох.
Эти случаи сложны, синьорны. и по каждому из них можно здесь в хабре открывать статью как минимум.

Но не все так плохо. Существует взгляд на ORM с обратной стороны. Это фреймворки наподобие MyBatis.
Они в первую очередь решают проблемы БД а уж потом дают опции объектных возможностей. Короче
Батис - это ОРМ наоборот. Где эволюция системы идет не от кода к БД (как любят хипстеры) а от
имеющихся вызовов процедур
и запросов к объектам респонса.

sudo update-alternatives --config php
Читайте справку к используемому дистрибутиву.

Сколько людей - столько мнений. Не стоит прям вообще всех слушать, кто высказывает какие-то "гениальные" откровения. Даже внутри крупных фреймворков многие вещи реализованы по разному, и каждый считает что именно так надо, и никак иначе. Думаю автор статьи просто искал дешевого хайпа, на практике никто так не делает. Контроллер по сути не модель, а управляющая конструкция, в ней нормально внутреннее ветвление на методы. С таким же успехом можно решить что для модели нужно 4 репозитория, на каждое действие CRUD...