У вас задача - сделать очередной сайт. Вы спрашиваете - какой фреймворк выбрать? При том, что фреймворков для создания сайтов - уйма. На каком основании вам советуют те или иные фреймворки - непонятно, люди ничего конкретно не знают про вашу задачу, ничего конкретно не знают про вас, а советуют. Вы же не хотите следовать за чужим некомпетентным мнениям? Выберите сами, почитайте в чём разница между фреймворками.
Если данные читаются часто, то они точно будут лежать в буфере postgres. Если у вас статический контент, который вы просто забираете по ключу, то разницы с Redis не будет никакой почти, больше времени коннект происходит, чем выборка данных.
Так кто вы, новичЕк или новичОк? А методы pAblic или pUblic?
"Как преобразовать (вынести) View из контроллера в модель?" - это как сделать из неправильного ещё более неправильное. Вьюхи должен вызывать контроллер, а не модель, и данные из моделей в них должен передавать контроллер. А вообще, посмотрите как делают нормальные люди, например, во фреймворках - вот CI делает так: https://github.com/bcit-ci/CodeIgniter/blob/develo...
Навигация по каталогам в несколько раз быстрее (просто листать, вернуться в конец/начало списка, перепрыгнуть на имя файла который начинается с определенной последовательности...)
Любое действие с файлами и папками на расстоянии одного хоткея. Поиск, создание, просмотр, редактирование, копирование, удаление, вставка.
И всё это без малейшей задержки, мгновенно. Всё в одном окне. Никаких даблкликов, ожидания открытия сторонней программы, сохранения, закрытия программы...
Для меня ещё плюсом прозрачная работа с архивами - словно это папка.
Консоль прямо тут же. В гит закоммитить там, например.
Ну и да, ежели нужно подключиться на удаленную машину - ftp / ssh всё тоже предёльно просто и быстро. Как работа с файлами, так и удалённая консоль.
Ну и да, для самых любителей есть user menu - в него можно понадобавлять любимые места на диске или любимые консольные команды, чтобы перемещаться в папку "загрузки", "сайты" и т.д. тоже за один хоткей.
Если максимум 6 и точно больше никогда не будет, то не грех и через pid. Но это вообще самая хреновая структура. Лучше всего Nested Sets, сразу с хранением уровня вложенности.
Херово сделана база. Несогласованность базы приводит к тому, что сама база перестаёт понимать как сопоставлять сущности друг с другом, в вашем случае вы не можете запросом к таблице товаров узнать, какой из них дороже, а какой дешевле. Храните либе два поля - в рублях и в нужной валюте, либо общайтесь с базой только в рублях а конвертацию производите на каждом запросе.
Вполне можно написать такой чат используя API телеграма. А ежели не хочется писать свой клиент, то можно вообще воспользоваться tg-cli как бекенд для вашего чата на сайте.
Набор бессвязных фраз, а не вопрос. Пожалуйста, попробуйте задать вопрос в максимум одно предложение, не более 140 символов. Глядя на исходный код - в чём проблема сделать массив с ключами равными значениям 001 002, а значениями массива - то, что в $data?
Преждевременная оптимизация - зло.
При разработке системы следует уделить внимание её архитектуре, а не замене одних методов на других. Ну и, конечно, оптимизировать надо там, где надо. А то понапишут кривых запросов к БД, зато вложенные циклы на PHP соптимизированы.