Adamos

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

Пока vless. Дальше я думаю будет пофиг - потому как у нас на горизонте стремительно, как тропический ураган разворачиваются "белые списки" - сначала как обычно у опсосов, потом и проводники подтянутся.

"...Я знал, что будет плохо, но не знал, что так скоро..." (С) В. Цой

Считайте, что указание наименования шрифта - это как рецепт на сайте.

Если в рецепте написано, что для выпечки пирожка требуется взять 100 грамм муки высшего сорта (Arial), это не значит, что вы передаёте читателю эту муку, которую вы где-то украли.

Купить, украсть или отобрать у кого-то реальную физическую муку - это уже дело читателя. К тому же вы в своём рецепте даже пишете, что если у вас нет муки высшего сорта, то вы можете взять и любую муку другого сорта (sans-serif), а не красть Arial

> Хочется практиковаться в изучении linux, двигаться куда-то в сторону девопс

Для этого достаточно виртуалки на рабочем компе. Ну или совершенно убитого десктопа или подержанного ноута.
А ещё лучше - в плане "практиковаться в изучении linux" - поставить его на рабочий комп.

Откуда эти завиральные идеи про выделенный комп, да ещё и с каким-то специальным серверным железом, про 8 ядер! - совершенно непонятно. Всё перечисленное ещё 15-20 лет назад работало на 1-2 ядерных серверах в продакшене. А не дома, с нулевой загрузкой.

Решали ровно эту задачу для склада Детского мира. Техническая часть решения состояла в увеличении размера штрихкода (за счет полей), 2мп камеры с матрицей sony exmor r и обозначении на столе цветным скотчем поля обзора камеры, внутри которого сборщик должен был проводить операции с коробкой.
Поле обзора камеры - за счет объектива 5-50мм с лотка освещения на столе составляло около 1×1м. Технически вопрос был урегулирован, но интегратор обломился на стоимости тушки камеры более 40к.

Я просто оставлю это здесь: отображение объектов на реляционную БД - это Вьетнамская война компьютерной науки

Ужасы нашего городка. "испросите ИИ". Это все, на что способна нынешняя молодежь? Рука-лицо...
1) перелить из экселя в базу - задачка простая, день-два, максимум неделя.
2) написать страничку с поиском и выводом результатов, примерно также.
3) а вот далее, сложно, ибо нужно многое уточнять, кто, как куда, зачем, почему.
Ps. Если есть вопросы, контакты в профиле, пишите, пообщаемся,

Проще написать скрипт на php, python и т.п., и уже на уровне ЯП выполнить очистку и прочую обработку.

Дисковое место: сам Битрикс в редакции Бизнес жрёт меньше 1.5 Гб . Остальное зависит от того, сколько у вас картинок и какого они размера.
Памяти как-то мало. Полгига надо отдать под мемкеш или редис, потому что файловый кэш проблемный. Битрикс хочет 384 Мб оперативки на процесс PHP - считайте сами, сколько получится запустить параллельно.
Ещё MySQL отожрёт гига два.
По ядрам:
одно - под MySQL,
одно - под nginx ( ладно, системные процессы сюда же),
и ... ничего не осталось..

10к уников - для простоты можно считать, что они ходят только в рабочее время, то есть 10 часов. То есть 1к уников в час, 1 уник в 3.5 секунды. У Битрикса "эталон" задан как генерация страницы за 0.3 сек - в реальности, конечно больше ( если кто-то станет Вам говорить про автокеширование - плюньте ему в лицо), но вроде вписываетесь.
Сейчас ещё надо учитывать паразитный трафик от нейросетей и всяких парсеров, он может быть очень значительным, но можно его зафильтровать.

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

Вопрос сформулирован по-дурацки, из серии преждевременной оптимизации. "У меня ещё ни базы, ни запросов, ни нагрузки и никогда не будет, но желаю чтобы всё летало!"

Но тем не менее, ответ на него существует. И он гораздо проще, чем все извращения, которые тут наперебой предлагают всякие доброхоты.

Во-первых, увеличить innodb_buffer_pool_size до 80% от доступной памяти на сервере. Mysql совсем не дура, и прекрасно сама подтянет используемые таблицы в оперативку. И вселенская проблема нашего фантазёра будет решена.
Отдельно здесь следует упомянуть случай, когда этому буферу не просто задан недостаточный размер, а жалкие 128 мегабайт, поскольку никто не догадался поменять значение, стоявшее в конфиге по умолчанию.

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

Это не просто подсказки, это контроль типов. То, что зная какой тип возвращается Шторм может подсказать варианты это побочное удобство. Основное же должно быть то, что конкретная переменная имеет определенный тип, а значит не нужны дополнительные проверки и методы будут лаконичны и конкретны. У вас пока, то ли объект, то ли массив, то есть каждый раз нужно проверять что это. Лучше бы сделать объект-коллекцию.
Чтобы указать Шторму, что в конкретной переменной лежит только этот тип используется хинт, типа такого:
/** @var User $user */
но разумеется, он должен быть только в том коде где в $user лежит обязательно объект класса User и ни что иное.

Будет ли разница в результате между двумя вариантами

Да. См. fiddle

CREATE TABLE a SELECT 'a' x UNION SELECT 'b';
CREATE TABLE b SELECT 'a' x UNION SELECT 'c';
CREATE TABLE c SELECT 'b' x UNION SELECT 'c';

select a.*, b.*, c.*
from a left join b using (x) left join c using (x)

x	x	x
a	a	null
b	null	b

select a.*, b.*, c.*
from a left join (b left join c using (x))  using (x)

x	x	x
a	a	null
b	null	null

Есть ли какое-то правило, которое определяет порядок связывания таблиц?

Да. Порядок связывания определяется требуемой логикой.

PS. В качестве самостоятельного задания - найди истинную причину разницы.

PPS. При абсолютной эквивалентности обеих форм - разницы нет.

разработчики все время советуют перейти на новые технологии а если точнее на Laravel и с MySQL на PostgreSQL чтоб сайт не только стал современным но и работал шустрее.

Переход с самописа на лару - хороший шаг, переход на постгрес нужен только если нужны конкретные задачи, решаемые постгресом лучше чем мускулем. Например, если у вас есть большой массив json данных, хранимых в соответствующих полях и требующий каких-либо выборок на основании этих полей, то есть по сути - если у вас база хранит ненормализованные сортируемые данные. В остальном выгода от перехода с мускуля на постгрес будет не видна без микроскопа.

Если база нормально спроектирована, то модели лары могут практически налету подхватить таблички, останется только написать зависимости в моделях, пошаманить контроллеры и перевести хтмл в блэйды. Задача не смотрится как "работы на год", однако сложно сказать за сколько справятся ваши прогеры, тут сильно зависит от исходных данных, типа насколько правильно спроектирована бд, что есть сложного в функционале такого, что долго переносить в ооп/мкв, насколько хорошо разбираются ваши спецы в том что было написано в легаси проекте, насколько они хорошо знают лару...

Обычно заявы по типу "мускуль гуано, надо менять на постгрес" без конкретных аргументов признак поклонников карго культа, а не профи. Так что я бы послушал аргументы для начала, а то потом окажется что там индексы только первичные на таблицах, про explain никто никогда не слышал, а выборки идут по тысяче в циклах, но виновата, конечно же, тормознутая бд.