Михаил Р.

— как правильно делать по 30-50-100 сайтов с точки зрения дальнейшего продвижения? один из вариантов: сделать "главный сайт", а на каждый город делать поддомен. какие бывают ещё варианты?


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

— как эффективно этим всем управлять, например в WP?

Есть плагины позволяющие делать хорошее разделение на поддомены во многих CMS.

— как правильно организовать бэкенд под огромное количество поддоменов и что вообще нужно учесть?


Снова вам нужен хороший плагин и консультация грамотного сеошника.

— стоит ли делать ли всё на 1 хостинге?


Если проект "белый" то да, можно делать все на одном хостинге.

— на 95% одинаковый контент не будет причиной бана? какая есть лучшая практика с точки зрения SEO?


Не будет.

— какие лучшие практики вы знаете по построению сеток сайтов?


У вас не сетка, у вас региональное разделение по поддоменам. Сетка - нечто иное.

1. а почему именно wp? Когда 1 блог - понятно. Но при сложной кастомной структуре готовая cms может оказаться ошибочным выбором.
2. как можно что-то обсуждать при абстрактном "сайт". Где конкретика, взаимосвязи и различия сайтов?

По сути Ваш вопрос звучит так "Я тут решил кое-что сделать, главное что пока в одном экземпляре, но потом будет много. Решил использовать лобзик. Как думаете пойдет и какую фанеру лучше брать?"
Как тут ответить? Вы объясните что именно делать будете. "Сайт" - это ни о чем. Вам или лень описывать или Вы вообще не понимаете, что делать будете.

Начальное значение для суммы не указал

let array = [-2, 0, 1, 2, 3];
let result = array.reduce(function(sum, element, index, thisArray) {
  if(element >= 0) {
    return sum + element;
  } else {
    return sum;
  }
}, 0);
console.log(result); // 6

Последним аргументом у reduce иде стартовое значение sum, если оно не установлено, то берется нулевой элемент массива, и итерация начинается с первого. Поставите там ноль.

Как вариант

БД нужна там, где данных реально много и/или ими нужно оперировать.
Логи можно хранить и в файле (настроив ротацию) и в бд. Просто потому, что данные из логов достаточно редко анализируются.
Ключи для продажи сторятся в базе тупо для учёта, чтоб каждому Васе можно было показать какие ключи он купил.

Ну и вишенка на торте-бд это частный вид файлов.

document.getElementById('acting').onclick = function() {
  document.getElementById('zakaz').setAttribute('action', '/zakaz.php');
}

console.log(value.replace(/\bJava\b/g, 'Python'));

1) Не очень понятно назначение таблицы product_value, допустим у вас есть товар Куртка зимняя, у него есть два варианта (цвет: черный, размер: 42), (цвет: красный, размер: 43), и что будет в таблице?
Четыре записи:

Куртка зимняя	Цвет черный
Куртка зимняя	Цвет красный
Куртка зимняя	размер 42
Куртка зимняя	размер 43

И как вы определите, как эти свойства соотносятся и главное как вы это будете использовать?
У вас же будут вноситься данные по продажам?

Назначение этой таблицы в таком виде непонятно, я бы предложил сделать таблицы

attributes_sets (модификации товара)

• id
  
• product_id
  
• title
  

и

attributes_sets_values (значения свойств данной модификации)

• attributes_set_id
  
• value_id
  

Тогда получится таблица вида

Куртка: вариант 1	Цвет черный
Куртка: вариант 1	размер 42
Куртка: вариант 2	Цвет красный
Куртка: вариант 2	размер 43

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

Также можно писать в поле title таблицы attributes_sets значения модификации через запятую "черный, 42", это упростит вывод информации о модификации в отчетах.

2) В product_value(или attributes_sets_values, если примените пункт 1) можно добавить поля attribute_id, value_int, это позволит для числовых атрибутов не задавать заранее список значений в values, а сразу указывать числовое значение

3) Цены лучше не хранить в товаре, а сделать отдельные таблицы

price_types: id, name
prices: price_type_id, product_id, set_date, price

Это позволит назначать товару разные цены в зависимости от всякого рода условий, можно также добавить в prices поле user_id, чтобы не возникал вопрос кто поменял цену

Неверно в корне.
Вы нарисовали по сути EAV (есть такая готовая схема данных под эту задачу - погуглите, примеров много).

Плюсы:
Удобно ложиться в реляционную модель, удобно программируется (если вам удобно работать с реляционной моделью), на первый взгляд хорошо подходит под любую реляционную СУБД (MySQL, PostgreSQL, Oracle).

Минусы:
Неоправдано малоэффективно по производительности.
Есть решения на порядок более быстрые.

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

По мне так EAV удобен как средство редактирования (ну и хранения первичной информации).

А вот собственно сам поиск гораздо эффективнее осуществляется на full-text search engines, например:
SphinxSearch (или его клон Мантикора), ElasticSearch и т.п.

И чем по большему количеству фильтров идет поиск - тем больше этот разрыв (хотя он и по одному фильтру уже весьма заметен).

В наиболее развитых full-text search engine поиск по свойствам является "дешевой" операцией, совершенно совместимой с основным полнотекстовый поиском.

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

Бонусом практически "бесплатно" получаете т.н. "фасеточные итоги", отвечающие на вопрос "сколько у нас товаров с таким то свойством" (это часто используется в отображении фильтров на сайтах).

====================

Вывод:

Если вам принципиально на MySQL - просто см. описание схемы данных EAV. Она как раз именно что для этого.
Если вам нужно чтобы все летало - см. SphinxSearch (он крайне быстр и нетребователен к ресурсам).

P.S.:
SphinxSearch
Умеет выдирать данные из MySQL. На их основании строит уже свой собственный узкоспециализированный но очень быстрый поиск для выборок, в вашем случае, по названию и по свойствам товаров.