ThunderCat

Imho:
1) БД 7 гигов как бы не много. Оно должно дампиться за несколько минут.
2)
- Зачем каждому разработчику актуальный дамп продакшена?
- Зачем это все хостить на боевом сервере?
3) Идея писать логи в основную БД весьма порочна. Поднимите под неё какую нибудь монгу, ну или хотя бы отдельный sql сервер.
4) Идея хранить картинки в базе конечно имеет право на жизнь, но для этого нужны веские аргументы.
Мне кажется вполне можно вынести работу с картинками в отдельный сервис (единый для всех) и хранить это все дело в файловой системе.

Начну с конца.

1. RESTfull - это архитектурный стиль. Он никак не коррелирует ни с быстродействием, ни с трафиком, ни с чем.

2. Проблемы с серверами решаются очень просто: Hetzner всего 4000 рублей в месяц.
Вообще идея отдавать проект на размещение в другую компанию, это потенциально дикий геморрой.
Сервера всегда должны быть свои.

3. Про технологии: открываете hh и смотрите на количество резюме по разным языкам и уровень зп.
Опять же не нужно зацикливаться одним городом, смотрите в целом.
По моим наблюдениям самым популярным является lamp стек.
В некоторых регионах на первом месте Java, но оно сильно выше по зарплатам при примерно таком же среднем уровне.

UPD@Airat1995

1. Я просто считал, что если будет сервис statefull, то это нагрузка на сервер, ведь надо хранить данные о пользователе и т.д. Значит я ошибался)
2. Да проблема в том, что вряд ли такое будет возможно сделать, у них строгая политика по поводу пользованием сети интернет (ИМХО скорее всего из-за узкого канала связи)
3. По поводу того, что не нужно зацикливаться на одном городе, у них есть своя фирма подрядчик, которая занимается всем, что так или иначе связано с IT. Когда поставили задачу, мне сразу сказали, что необходимо сделать так, чтобы это было более-менее дешево сопровождать и какая организация будет этим заниматься.

Airat1995:
1. а) STATEless и RESTfull это в принципе разные вещи которые никак не пересекаются.
Сервис вполне может быть STATEless, но не RESTfull и наоборот.
b) Хранение данных о пользователе есть в STATEless сервисе. В STATEless нет хранения данных пользователя (но не бизнес логики) между запросами.
Если у Вас пользователи не измеряются миллионами это ничтожная нагрузка.
* Хотя STATEless бесспорно удобней в интеграции

2. Это интранет приложение и нет денег на отдельную железку? Рискну предположить что нагрузки там не будет по определению никакой.

3. Постановка вопроса несколько странная если честно.
Вы в соседних комментариях пишите что разрабатывать будете сами лично.
Вы мастер на все руки готовый написать на любом из существующих языков с использованием любого фреймворка?!?

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

scandir + рекурсия

Кириллица в РНР - вообще не очень хорошо.
Если вам доведется как-нибудь перевести проект с cp1251 на utf8 или обратно - прочувствуете, почему...
Ну, и пара мелочей:
1. ($array != $аггау) === true. Сами догадаетесь, почему?
2. Вам же оплачивают ваше время работы? Добавьте к нему бесплатную практику в английском - думая о процессе по-английски, называя переменные по-английски, добавляя комментарии по-английски. Гугля, если понадобится, на английском... Со временем вы не только прокачаете язык, но и действительно будете думать о коде в английских терминах. Не понадобится переключать контекст в голове. А это дольше, чем переключение раскладки, даже если вы этого не замечаете.

UPDATE product
LEFT JOIN (SELECT id_products, name_product FROM newProduct) as np ON np.id_product = product.id_product
SET product.name_product = np.name_product

update tablename set fieldname = concat('prepend', fieldname) where /**/;