Berkutman

Id, который первичный ключ в таблице заказов, вполне достаточно

Смотря для каких целей, понятно что в бд уникальный id, но для клиента может содержать что угодно, например id торговой точки + порядковый номер

рандом конечно же

если заказ можно посмотреть по его id в интернете без регистрации и смс, и не должно быть возможности смотреть чужие заказы, я бы при генерации ид использовал текущую дату и 9-символьное случайное число, то есть

20200728123456789

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

DB::connection('sqlsrv2')->select("SELECT price_rub FROM product WHERE item_id = ".$req->input('item_id'));

. И да, некоторые так делают, и не только при прямом использовании mysqli, но и при использовании pdo и разных там query builder'ов. Ну а альтернатива - eloquent и прочие orm. Нужна она или нет - решать вам

Docker хорошо подходит для staitless приложений.
А какие преимущества останутся для базы данных? Взять и запустить на другом хосте без данных на диске уже не получится - переносимость утрачена.
При высокой нагрузке узкого места добавят и volume mounts.
Т.е. на практике БД, чаще всего, разворачиваются вне docker / kubernetes кластера. Возможно, кто-то назовёт в ответах преимущества от БД в докере.

Не надо использовать дата-контейнеры, это изначально плохая практика, спорная даже в тех редких случаях, когда их всё же используют.

Дата-контейнеры использовали во времена, когда ещё не завезли пользовательских volume в докер, тогда типичным способом создания такого, не принадлежащего явно ни одному "тяжёлому" контейнеру", было создание лёгкого ничего не делающего контейнера, от оторого все тянули данные к себе.

Сейчас же просто делаешь volume и всё. Но для базы данных нет никакого смысла делать volume, проще и надёжнее пробросить физический каталог.

Сколько подсетей может быть в 1 VLAN?

Да сколько угодно.

Это возможно вообще? Разве не 1 сеть - 1 VLAN?

Это абсолютно разные и никак не связанные вещи.
Вилан это виртуальная сеть на 2 уровне OSI.
А подсеть - это просто сеть с определенной адресацией.

Сколько вы там сетей сделаете в физической или виртуальной сети - ваше дело.

Сделайте просто var_dump($element) вот так

foreach($html->find('div._img') as $element) {
var_dump($element);
}

и посмотрите, присутствует ли ключ с назнанием style в свойстве $attr данного объекта $element. Или в каком - либо другом свойстве. Если нет - значит проблема в библиотеке. Библиотека не читает inline-стили на dom-элементах.

$('#show_more').addEventListener('click', () => {
    $('#some_block').removeClass('d-none')
})

Нет не будет
Доменое имя это чисто человеческий фактор, чем легче и понятней для твоего клиента тем лучше.

Какие доменные зоны лучше всего прикрепить к салону красоты? Например имеются подходящие как .studio и .salon, будут они влиять на поиск значительнее зоны .ru по категории салоны красоты?

Домен значения не имеет. Но если брать .salon клиентам будет неудобно каждый раз вбивать его в строку. Но для эксклюзива взять можно. Лучше, если город брать "городской домен" например exp_krasotka.mos.ru. Или можно взять org или рф например. Но рф в некоторых браузерах не работает.

Так же будет ли дефис в имени домена и имя города в кратком формате влиять на поиск на пример NAME-spb.ZONE , NAME-msk.ZONE или же только ухудшать?

Улучшать поиск будут только городские домены. Приставки будут только портить, потому что поисковик ищет самые короткие адреса. Проверено на практике