Хотел обратить внимание на странную вещь в ценах, а именно поле list_price в таблице products. Предлагаю убрать данную цену из таблицы товаров и вынести к другим ценам, для унификации. А то очень странно выходит - и то и это цены, но одно мы храним в product_prices и меняем одним способом, а другое - эдак. Не логично. При этом что в источнике данных для сайта, что на выходе(фронте, фидах и т.д.) работа с этими ценами по своей сути идентична. Выходит не удобно и в целом странно.
Помимо прочего это позволит добавить более гибкий функционал для кастомного ценообразования, модулей.
Аналогичным образом я бы полностью отказался от хранения amount в products. Будь то остатки в самом простом CS-Cart или с многоскладовостью или мультивендор с общими товарами, логичнее было бы не плодить товары в products(а что в связи с этим в характеристиках и т.д. творится… в общем, много проблем бы решилось одним разом), а задать соответствующие значения остатков в отдельной таблице. 1 товар на 10 складах - 1 запись в таблице products, 10 в таблице товарных остатков. 1 товар, 10 вендоров - 1 запись в таблице products, 10 записей в таблице товарных остатков. 1 товар, 10 вендоров у которых по несколько складов… ну, думаю, и так понятно.
Давайте отделим мух от котлет, ради более светлого будущего? Только подумайте, насколько упростится и оптимизируется код, насколько сократятся таблицы в БД, сколько уйдет логических ошибок? Знаете как заколебало, например, поле amount в головной карточке товара в MVP с общими товарами продавцов? Я уже не говорю про то что в процессе исправления логической ошибки просто колоссально возрастет производительность в большом числе случаев прямо на порядок. А то на некоторые блоки из того же MVP без слёз смотреть сложно(с точки зрения оптимизации).
Так в итоге в cs-cart будет 400 таблиц в одних цены, в других кол-во, еще таблица с артикулами и тд и запросы будут же прям еще более “join”-ые и нас ждет еще больше тормозов.
Тут скорее речь исключительно про MVP
В обычном цс-карт “насколько сократятся таблицы в БД” - этого не будет, только увеличится и кол-во таблиц и объем, если разбить products по таблицам и убрать даже 2 колонки по отдельности, это +2 таблицы в каждой минимум по 2 колонки = 4 колонки, оптимизация минусовая, плюс 2 запроса join, чтобы узнать кол-во и допустим артикул (цены и так спрашиваем).
Как минимум будет из коробки корректная заготовка под многоскладовость, которую останется только включить. И корректные цены(тут вообще новые таблицы не нужны, стандартных достаточно).
Меня тоже по началу смущало, что одинаковые данные хранятся в базе в нескольких местах. Вообще я конечно понимаю логику разработчиков. На самом деле проще один раз занести данные сразу в несколько мест, и это потом упрощает последующие поиски по ним. Тут вопрос в другом. Архитектура была построена много лет назад, и с тех пор немало воды уже утекло. И в первую очередь надо менять именно архитектуру, а это будет уже совершенно новый продукт. С теми же заказами: заказ - это номер и адрес получателя. Заказ состоит из одного или более отправлений, и вот уже в отправления должны привязываться товары, способы доставки, статусы итп. Так же и с ценами про товарам, копий немало сломано, что list_price устарел. И к промо акциям подступа особого нет, так как сильно глубоко все завязано туда, куда лезть опасно, чтобы все не порушить.
По факту в CS-Cart list_price - это просто информация, чтобы замотивировать пользователя (типа цены у конкурентов). Поэтому особого смысла помещать ее в цены, думаю, нет, т.к. непосредственно на стоимость товара она никаким образом не влияет
Ну изначально позиционирование этой цены было неверное, так как она могла сильно вести в заблуждение, о чем много раз писал. Лист прайс 1000, прайс 800, в карточке отображается лейбл скидки 20% (первый “почему” - какая скидка от цены конкурента?). Ну ладно. Даю скидку для зарегистрированных 5%. Что видит человек? Он в первую очередь видит не цену, а лейбл, а тот говорит, что пока ты был не зарегистрирован, у тебя была скидка 20%, а как только зарегистрировался - всего 5%… Отсюда и все танцы с бубнами: либо разработчики полностью логически отделят это понятие от всех остальных цен, либо, если логически интерфейсом они связывают их воедино, то и программно они должны между собой быть связаны. Лист прайс позволяет очень быстро и просто через импорт назначить большому количеству товаров индивидуальные скидки, что невозможно с использованием промо акций. Поэтому удалять поле лист прайс я бы не стал. Но давно пора отойти от его первоначального значения, и вести в общую логику расчёта скидок.