driverx18

IMHO, там где понятно по тайпхинтам, смысла в phpdoc нету. А вот там где непонятно

/**
 * @return array{uid: string, name: string, isAdmin: bool}
 * @throws AuthenticationException on authentication error
 */
private static function authenticate(string $login, string $password): array
{
}

https://www.php.net/manual/ru/function.unset.php - там написано

Если переменная, которая передаётся ПО ССЫЛКЕ, удаляется внутри функции, то будет удалена только локальная переменная.

$sotrudniki=Sotrudnik::find()->asArray()->all();

И где тут связь должна дергаться? Модель не дергает связи пока Вы этго не попросите. В модели Вы описываете, как строить связь. Это не значит, что все запросы теперь будут тянуть ненужные им связи. Откройте документацию:
https://www.yiiframework.com/doc/guide/2.0/en/db-q...
https://www.yiiframework.com/doc/api/2.0/yii-db-ac...
Что бы дернулась связь getPodrazd() надо как-то так строить:

$sotrudniki = Sotrudnik::find()->joinWith('podrazd', true, 'INNER JOIN')->all();

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

нет. главное чтоб в where были или первое поле, или первых два поля, или все 3 поля. в каком порядке вы их напишете в запросе - без разницы.

т.е. where country = ?? использовать индекс не будет вообще, а where country = ?? and entityId = ?? будет использовать только первую часть составного индекса (по ентитиИд).

Преобразование в строку

Значение boolean TRUE преобразуется в строку "1", а значение FALSE преобразуется в "" (пустую строку). Это позволяет преобразовывать значения в обе стороны - из булева типа в строковый и наоборот.

Массивы

key может быть либо типа integer, либо типа string. value может быть любого типа.

* * * * * docker exec container php /path/to/artisan/in/container/artisan schedule:run
что-то типа...

build надо только еслы Вы возьмете его проект с гитхаба тут, тогда надо будет git clone https://github.com/dougbtv/docker-asterisk , cd docker-asterisk ну и дальше build как написано.
Если Вы делаете pull из docker hab-а , то используется уже заранее собранный контейнер.
Дальше просто docker run -it dougbtv/asterisk ну и так далее.

Иммутабельность переменной - это достаточно важное свойство. Переменные нужно помечать ключевым словом let не просто так. Опустим очевидное, исходящее из определения - неизменяемость. Но что стоит за этим на уровне компилятора? А стоят за этим нужные вещи.

Если мыслить широко, то ключевым словом let можно ведь пометить не только, скажем переменную содержащую число, а коллекцию или структуру или объект.

Коллекция, помеченная как неизменяемая, даёт возможность компилятору выделить для неё непрерывную память, что позволит ускорить операцию чтения, в сравнении с обычной, динамической коллекцией. (Именно по этой причине, для особых нужд, в Swift, есть специальная коллекция ContiguousArray)

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

Сравнение для неизменяемых объектов также может быть оптимизировано компилятором.

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

driverx18, считается, что у любой программы может быть вывод. если у конкретной программы его нет - то это свойство конкретной программы, я говорю об общем случае.
по умолчанию, если не указано, куда выводить стандартный поток сообщений, то вывод идёт в стандартное устройство вывода - на консоль.
по умолчанию, если не указано, куда выводить стандартный поток ошибок, то вывод идёт в стандартное устройство вывода - на консоль.
если приложение, запущенное через cron, делает вывод в стандартный поток сообщений и/или в стандартный поток ошибок, то cron это перехватывает и, в зависимости от настроек, может херить или, что встречается чаще, передавать в подсистему логгирования, класть в мейлбокс.
поэтому, если вывод сообщений и ошибок принудительно не переназначить в другое место (например, в /dev/null), он, как правило, окажется в почте.

Сделайте общий метод getUsersQuery(), который просто возвращает пользователей без какой либо сортировки. Свой метод getUsers() измените так, что бы он использовал первый метод. Плюс, добавьте метод getUsersSorted(), где будете возвращать данные, отсортированные в нужном виде. Не зная структуры проекта сложно написать какие то примеры кода, но я бы сделал примерно так:

function getUsersQuery() {
    // ...
}
function getUsers() {
    return getUsersQuery()->orderBy('id');
}
function getUsersSorted() {
    return getUsersQuery()->orderBy('name');
}

Смотря зачем)). Я когда делаю Code Review критерии следующие:

* Безопасность:
- Каждый аргумент метода простого типа должен проверяться на тип в случае его проксирования и на граничные значения в случае обработки. Чуть что не так - бросается исключение. Если метод с кучкой аргументов на 80% состоит из поверки из аргументов - это вполне норм))
- Никаких trigger_error, только исключения.
- Исключения ДОЛЖНЫ быть человеко-понятны, всякие "Something went wrong" можно отдавать пользователю, но в лог должно попасть исключение со стектрейсом и человеко-понятным описанием, что же там пошло не так.
- Каждый аргумент (объект) метода должен быть с тайпхинтингом на этот его класс, или интерфейс.
- За eval как правило шлю на **й.
- @ допускается только в безвыходных ситуациях, например проверка json_last_error.
- Перед работой с БД - обязательная проверка данных.
- Никаких == и !=. Со swtich - единственное исключение, по ситуации.
- Если метод возвращает не только bool, а еще что-то - жесткая проверка с ===, или !== обязательна.
- Никаких условий с присваиваниями внутри. while($row = ...) - тоже идет лесом.
- Магические геттеры/сеттеры разрешаются только в безвыходных ситуациях, в остальном - запрещены.
- Конкатенации в sql - только в безвыходных ситуациях.
- Параметры в sql - ТОЛЬКО через плейсхолдеры.
- Никаких глобальных переменных.
- Даты в виде строки разрешаются только в шаблонах и в БД, в пхп коде сразу преобразуется в \DateTimeImmutable (в безвыходных ситуациях разрешено \DateTime)
- Конечно зависит от проекта, но как приавло должно быть всего две точки входа: index.php для web и console(или как-то по другому назваться) - для консоли.

* Кодстайл PSR-2 + PSR-5 как минимум, + еще куча более жестких требований (для начала все то что в PSR помечено как SHOULD - становится MUST)
- В PhpStorm ни одна строчка не должна подсвечиваться (исключением является typo ошибки, например словарик не знает какой-то из аббревиатур, принятых в вашем проекте). При этом разрешается использовать /** @noinspection *** */ для безвыходных ситуаций.
- Если кто-то говорит, что пишет в другом редакторе и у него не подсвечивается, на эти отговорки кладется ВОТ ТАКЕЕЕНЫЙ мужской половой **й и отправляется на доработку)).

* Организация кода:
- Никаких глобальных функций.
- Классы без неймспейса разрешаются только в исключительно безвыходных ситуациях.

* Тестируемость (в смысле простота тестирования) кода должна быть высокая.
- Покрытие кода обязательно для всех возможных кейсов использования каждого публичного метода с моками зависимостей.

* Принципы MVC:
- Никаких обработок пользовательского ввода в моделях, от слова совсем.
- Никаких ***ть запросов в БД из шаблонов.
- Никаких верстки/js/css/sql-ин в контроллерах.
- В моделях НИКАКОЙ МАГИИ, только приватные свойства + геттеры с сеттерами.
- В моделях разрешено использовать метод save(при наличии такого разумеется) только в исключительных ситуациях. Во всех остальных - либо insert, либо update.

* Принципы SOLD:
- Никаких божественных объектов умеющих во все.
- Если метод для внутреннего пользования - private, никаких public.
- Статические методы разрешаются только в случае безвыходности.

* Принцип DRY разрешено нарушать в случаях:
- Явного разделения обязанностей
- В тестах (каждый тест должен быть независимым, на сколько это возможно)

* Работа с БД:
- Запрос в цикле должен быть РЕАЛЬНО обоснован.
- За ORDER BY RAND() - шлю на***й.
- Поиск не по ключам (конечно если таблица НЕ на 5 строк) запрещен.
- Поиск без LIMIT (опять же если таблица НЕ на 5 строк) запрещен.
- SELECT * - запрещен.
- Денормализация БД должна быть обоснована.
- MyISAM не используется (так уж)) )
- Множественные операции обязательно в транзакции, с откатом если чо пошло не так.
- БД не должна содержать бизнес логики, только данные в целостном виде.
- Не должно быть нецелесообразного дерганья БД там, где без этого можно обойтись.

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

* О людях:
- "Я привык писать так и буду дальше" - не вопрос, ревью пройдешь только когда поменяешь свое мнение.
- "Я пишу в vim-е и мне так удобно" - здорово, код консолью я тоже в нем пишу)) но есть требования к коду, если в них не сможешь - не пройдешь ревью.
- "Я скопировал этот страшный метод и поменял 2 строчки" - это конечно замечательно, но по блейму автор всего этого метода ты, так что давай без говняшек, хорошо?
- "Оно же работает!" - вот эта фраза переводится примерно так: "да, я понимаю, что пишу полную хрень, но не могу писать нормально потому, что руки из жо", я правильно тебя понял?))
- "У меня все работает!" - рад за тебя, а как на счет продакшна?
- "Там все просто" - не используй слово "просто", от слова "совсем". Вот тебе кусок кода (первого попавшегося с сложной бизнес логикой), где там ошибка (не важно есть она, или нет)? Ты смотришь его уже 2 минуты, в чем проблема, там же все "просто"))

* Всякое:
ActiveRecord (это я вам как в прошлом фанат Yii говорю) - полное говно, примите за исходную. По факту у вас бесконтрольно по проекту гуляют модельки с подключением к БД. Не раз натыкался на то, что в тех же шаблонах вызывают save, или update (за такое надо сжигать).
То, что используется Laravel - это печально((. Что бы выполнить требования приведенные выше, приходится "воевать" с фреймворком.

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

UPD

Формализировал данные критерии по ссылочке: https://github.com/index0h/php-conventions

Некорректно сравнивать тёплое с мягким. Так и здесь: DBAL, как вы правильно написали - слой абстракции, представляющий единый интерфейс для работы с различными реализациями БД.
ORM - штука, которая позволяет работать с объектами и связями в БД как с сущностями, не заботясь о том, из каких именно таблиц и полей заполняется сущность.

У вышеупомянутой Doctrine тоже есть свой DBAL, но это не мешает ей быть ORM :)

Зачем нужна репликация в принципе?

Во-первых, отказоустойчивость. Если у вас несколько реплик и один сервер сдох, приложение не обвалится с грохотом, а будет работать с оставшимися.
Во-вторых, производительность. Или один сервак будет обрабатывать 1000 запросов в секунду или 3 по 330 - есть разница.

Какие проекты требуют такого понятия как репликация?

Как следует из вышенаписанного, такие, для которых важна стабильность и в у которых нагрузка достаточно высокая, чтобы начал задыхаться один сервер.

Что называется master, а что slave?

В режиме master-slave репликации есть один master-сервер, обрабатывающий запросы на изменения данных, и несколько slave-серверов, обрабатывающих запросы на чтение. В случае выхода мастера из строя, один из слейвов становится мастером.

отличия между master-slave и master-master?

В режиме master-master все сервера равноценны и могут обрабатывать любые запросы. Но она сложнее и если один из серверов дохнет, вы можете получить повреждение данных.

$post = route('post'); // либо любым другим способом получите редактируемый пост
return [
 'title' => [
  // остальные правила
  Rule::unique('posts', 'title')->ignore($post->id),
 ],
];