ThunderCat

На сколько популярно и корректно хранить данные в столбце в виде JSON строки?

А это зависит от того, что с этими данными делать.

Если сохранить/вернуть - да, вполне.
Если найти по фрагменту - 50/50, и зависит в основном инструментов, имеющихся в конкретной СУБД.
Если выполнить более сложную обработку (сумма, в т.ч. с накоплением, среднее, медиана и пр.) - скорее нет.
Если использовать для связывания по фрагменту - почти наверняка нет.

самый простой вариант это прописать классы от родителя
.main-pagination .swiper-pagination-bullet {}

- if ($query = $db->query(statement: "SELECT * FROM products")) {
+ if ($query = $db->query(query: "SELECT * FROM products")) {
- $info = $query->fetchAll(fetch_style:PDO::FETCH_ASSOC);
+ $info = $query->fetchAll(mode: PDO::FETCH_ASSOC);

Не надо придумывать названия параметров из головы. Надо брать их из документации.

Да, единственный хороший вариант хранить картинки в базе - это не хранить картинки в базе, а хранить лишь пути или идентификаторы картинок.

Главный минус картинок в ФС - это то что они будут привязаны к одному серверу. Лучше хранить картинки в другой системе (S3 или CDN) и хранить в базе их идентификаторы, чтобы потом клиент мог сам их скачать, если это необходимо. Так раздача картинок не будет привязана к основному серверу.

А клиент пусть их кэширует также у себя на диске.

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

Если ты хочешь, чтобы разные пользователи имели доступ к единой базе модов, то действительно надо сделать какой-то сервер.

Ну и клиент на WPF не должен напрямую подключаться к MS SQL.
MS SQL должен находится где-то на сервере и спрятан за каким-то другим web-сервером (который будет написан с использованием ASP NET Core например), который будет уже отвечать за всякую логику.
Если тебе нужна локальная база данных на клиенте (для кэша например), то лучше использовать sqlite.

Как нужно вызывать js-функцию, чтобы она брала данные с той формы которую отправили? И как передать через ajax или ID, или Class формы?

Модифицировать кнопку форм, чтобы она вызывала событие формы submit:

<button type="submit" class="button">Отправить</button>

Создадим один обработчик для всех форм:

async function sendForm(form) {
  const data = {
    name: form.querySelector("input[name='name']").value,
    email: form.querySelector("input[name='email']").value,
    phone: form.querySelector("input[name='phone']").value,
    message: form.querySelector("textarea[name='message']").value,
    formId: form.id,
    formClass: form.className
  }

  try {
    const response = await fetch('php/send.php', {
      method: 'POST',
      headers: {'Content-Type': 'application/json'},
      body: JSON.stringify(data)
    });

    if(response.ok) {console.log('Success send form')}
    else console.log('Error send form', response);
  }

  catch(error) {console.log('Error: ' + error.message)}
}

Вешаем слушателей на submit форм:

document.querySelector('#form1').addEventListener('submit', (e) => {
  e.preventDefault();
  sendForm(event.target);
});

document.querySelector('#form2').addEventListener('submit', (e) => {
  e.preventDefault();
  sendForm(event.target);
});

В зависимости от формы нужно в PHP-скрипте менять тему письма.

В php обработчике формы обрабатываем полученные данные от js (php у меня не очень):

$json = file_get_contents("php://input");
$data = json_decode($jsonData, true);

// get formId and formClass
$id = $data['formId'];
$class = $data['formClass'];

// this change type email message

Вы не попадаете под действие этого закона, если не сдаете свои мощности в аренду.
Если сайты тестовые и размещаются вами просто в общий доступ - это не хостинг

https://youmightnotneedjquery.com/

Это у вас, похоже, не опции, а свойства в неограниченном количестве.
Если бы это были опции, то можно было бы или добавить просто колонки в основную таблицу, либо сделать одну колонку с битовой маской

А свойства хранить либо в EAV, который у вас второй вариант, либо в JSON поле.
И искать по ним отдельным не вот этим вот, а отдельным сервисом типа Эластика.

В любом случае, первый вариант, понятное дело, это вообще не вариант

Развернуть JSON в таблицу через JSON_TABLE().
Потом обнаружить, что запрос работает медленно, найти того, кто записал активно используемые поля в JSON и заставить его переделать на нормальную таблицу.

Никак. Выбор инструмента - это задача тимлида и/или техлида. Т.е. ведущего/главного разработчика, отвечающего за принятие ключевых технических решений. Ваша задача, как заказчика, четко оформить требования, ограничения и сформировать начальное ТЗ и описание, что вам требуется от проекта, прототипы интерфейса, например. Без вникания в технические детали. Т.е., "хочу чтобы были фичи такие-то и работил они так-то, ограничения такие-то, требования такие-то". Далее уже задача найти разработчика/команду с большим или достаточным для данного проекта опытом. Далее из начального ТЗ формируется полноценное техническое задание: описывается весь требуемый функционал, рисуется дизайн, прописываются требования, ограничения и прочие хотелки. И на основе ТЗ, тим/тех лид уже подбирает/подбирают наиболее оптимальные и конкретные инструменты и решения, основываясь на собственном опыте и знаниях для конкретно этой задачи. Например, если человек хорошо знает несколько разных инструментов и есть достаточный опыт их использования - он может реализовать проект используя любой из них как одинаково хорошо, так и одинаково плохо. У разных ЯП и фреймворков свои плюсы и минусы. Далее из ТЗ формируется более детальное ЧТЗ и происходит разработка проекта.

Вот вы говорите:

Нужно будет выполнять много запросов к БД

Важная быстрая скорость работы нашего сайта

Много/быстро это сколько? 100 запросов в час? 1000 в минуту? 1М в секунду? Загрузка страницы за 30/10/1с или даже 100мс? А к какой именно БД? Какая характеристика самих данных и какого типа запросы? На какое количество соединений? В каком регионе? Есть ли там тяжелые или еще какие-то вычисления? Медиа файлы - картинки, видео? Тут очень много нюансов. В идеале следует определиться с конкретными значениями/параметрами и их описать в ТЗ. Ну или определить примерное, а фактическое значение определить на стадии прототипа/MVP и/или провести какое-то исследование/тестирование. Можно потратить десяток лямов на написание крутого кода на го/расте/С++/ассемблере в течении года и все будет летать на простейшем сервере. А можно купить свой сервер за лям (ну, условно, конечно), нанять питонщика или PHP-ника за 300к и он за пару-тройку недель добьется такого же результата. Большинство веб-задач сегодня достаточно просто или с минимальными усилиями решаются абсолютным большинством решений для веба. Да, у всех решений есть свои плюсы и минусы.

Безопасность от всяческих XSS и SQL атак.

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

А так - уже правильно посоветовали сразу брать дот-нет, т.к. у вас требование к использованию конкретной библиотеки для дот-нета.