Василий Назаров

ООП для веба - это так же, как в книжках.
Делаете класс ПостВБлоге
Описываете его свойства (они же атрибуты).
Реализуете методы для чтения и записи из/в БД.
Получается что-то вроде

class BlogPost {
    public $id;
    public $title;
    public $text;
    public $date;
    
    public function write() {
        // код записи в БД
    }
    
    public function read() {
        // код чтения из БД
    }
}

Делаете класс Комментарий

class Comment {
    public $id;
    public $text;
    public $date;
    public $blogpostId;
    
    // чёрт, здесь почти такой же код, как и в классе BlogPost
}

Придётся делать класс-предок для BlogPost и Comment

class DatabaseRecord {
    public function write() {
        // универсальный код записи в БД
    }
    
    public function read() {
        // универсальный код чтения из БД
    }
}
class Comment extends DatabaseRecord {
    // ....
}
class Comment extends DatabaseRecord {
    // ....
}

Потом идёте на https://laravel.ru/docs/v5/eloquent и с восхищением обнаруживаете, что всё уже написано за вас и для вас, и как раз с использованием ООП.

Laravel 5 или Symfony 4.
На другие лучше даже не смотреть, ни один из прочих не обладает ни актуальностью, ни распространённостью этих двух.
Ценность параметра "распространённость" вы оцените, когда будете искать работу в достаточно большой команде.

Дело в том, что сейчас приложения для Win в принципе малоактуальны.
(Заметьте, тут не написано "вообще никому не нужны", как любит формулировать хипстота).
Львиная доля новых приложений разрабатывается либо под моблю (iOS/Android, никакого WinPhone в мире не существует), либо под веб, либо гибридно.
И целая M$ сама же выпустила один из самых её успешных из новых (или единственный успешный) продуктов без WPF и прочей ..ни типа .Net - https://ru.wikipedia.org/wiki/Visual_Studio_Code

15 млн для MySQL при грамотной схеме и запросах вообще ничто.
Впрочем
1. Памяти хорошо бы побольше (и это не зависит, MySQL или что-то более модное), и эту память нужно ещё правильно "отдать" (настроить конфиги) MySQL-ю.
2. Смотрите конкретный SQL-запрос.
Возможно, его имеет смысл разбить на несколько, без JOIN-ов (JOIN-ы часто хотят ооочень много памяти, а если её не хватает, тормозят жутко). Особенно при использовании сортировки. (Ваше "когда сортировку включаешь" косвенно указывает, что тут и есть проблема).

Вы, возможно, сегодня не сможете это съесть, но когда сможете, запомните:
1. Никаких коммитов в master, кроме как мержа (лучше с --squash) из оттестированного коммита в ветке релиза
2. Никакой ветки stage, ибо stage - это состояние релизной ветки. Если у вас есть сервер stage (что более чем разумно), заливайте на него релизную ветку.
3. Фичи, по возможности, пилите в отдельных ветках, которые по возможности ответвляйте от master-а и мержте в релизную ветку.
4. В любом случае, релизную ветку ответвляйте от последнего [стабильного, в master-е других быть не должно, см. п.1] коммита в master-е

План слабо возможен в том смысле, что современная веб-разработка
1. Очень объёмна с т.з. нужных знаний/умений
2. Очень динамически развивается (особенно фронтовая часть)

Но в вашем конкретном случае просто
1. Найдите тему для веб-приложения, которое вы хотели бы создать
2. Начинайте учить те технологии, которые для реализации понадобятся "по ходу" ("по ходу" - это "по ходу дела", не дурацкий жаргонизм вместо "похоже")

Скорее всего, лучше всего двигаться сюда https://ru.vuejs.org/v2/guide/

1. Попробуйте заменить ng на Vue. Вы реально поразитесь, насколько сменится парадигма на фронте.
2.1. На бэке, если уже не можете слезть с .Net, пробуйте хотя бы .Net Core (в связке с тем же Vue)
2.2. Если сможете - пробуйте какой-нибудь нормальный ЯП, типа PHP7 (https://habrahabr.ru/post/332868/), JS (Node.JS), или хотя бы Go.

В сети прочитал, что нужно

ну, Сеть нужно уметь читать..
может, это?
https://habrahabr.ru/company/infopulse/blog/330708/

1) Сервер нужен, чтобы отдавать те данные (JSON), на основе которых React (лучше - не React) нарисует DOM. Обычно сервер генерит JSON из данных в БД. Но вы верно мыслите, в начале обучения можно положить статические файлы с JSON на любой доступный веб-сервер.
2) Можем посоветовать лучше: https://ru.vuejs.org/v2/guide/

если сайт начать писать с API ( json ) и потом на всех требуемых страницах сайта делать запрос к АПИ?

да

И как было бы удобнее обрабатывать это АПИ? Не через curl же запрос делать на свой же сервер?

через AJAX

Опишите, какие знаете плюсы и минусы такового. Как мне показалось, это достаточно удобно.

всегда удобно, кроме случаев, когда неудобно

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

такой

1000+ таблиц

Очень вероятно, что это и есть ответ.
Если вы все связи объявите как FK, модификация (вставка, изменение, удаление) одной записи в случае, когда у вас уже провалидированы все значения (а так бывает, видимо, всегда в грамотном коде), будет ощутимо замедленна этими самыми проверками на консистентность.
В противовес другим высказавшмся.
С базами я работаю 20+ лет.
10+ лет назад, когда начал работать с MySQL (он тогда никакой консистентности не умел) очень сильно удивлялся, как на таком можно работать. Но вариантов не было, работать пришлось.
Так вот.
За эти 10+ лет никогда не возникало никаких проблем, связанных с отсутствием контроля FK на стороне БД.
Впрочем, возможно, для этого таки обязательно сильно применять мозг при разработке.

Встречаю много

Да, в интернетах много чего встречается.
Если бы эти "статьи" не были полное давно, вы бы не задали здесь этот вопрос.
Знаете, почему?
Потому что в нормальных источниках было бы написано
1. Не юзайте то, потому что ....
2. Юзайте вместо того это.
В хороших статьях ещё и будут описаны плюсы и минусы как того, так и этого.

Зачем вот так объединять - "php/python/ruby"?
Где PHP, на котором 90++% веба (в т.ч. ВКонтакте, Фейсбук) и где Ruby (примерно в нигде)?
А форумы читайте осторожно, без разбора полной статистики (полной, а не выборки вокруг одного человека) любая инфа будет искажена вплоть до фактически полной противоположности реальности.
Например, вокруг меня за год действительно отказались от 4 стажёров на PHP, которых взяли, чтобы они обучались в процессе работы (причём даже за небольшую, но з/п). Это был эксперимент, и обучались они плохо.
Другое дело, что вокруг меня же никого не уволили "на Java", потому что никого не взяли, потому что Java вокруг меня никому не нужна.

Нашёл обзор.
https://postovoy.net/13-luchshih-konstruktorov-for...

Ваши эти commit1 и commit2 должны быть в разных ветках, причём ни один из них, по-хорошему, не должен быть в master-е.
В master они попадут как раз после того, как фичи будут готовы (или даже уже оттестированы на stage).