Выбор CMS для ИМ на 500-1000 товаров

Это да, отличное времяпровождение для тех, кому делать больше нечего.

Есть некоторое количество подписчиков давно находящихся в моём "черном списке". Я просто не вижу потоков их сознания.

Но вижу, что они "подтянулись".

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

***

Тут многие просят "показать результат".

Не буду. Просто потому, что докопаться можно и до столба.

Вкратце. За пару недель получился статический ИМ обновляемый из имеющейся системы управления товаром.

Страницы товаров-категории-корзина-чекаут.

Поиск со стороны клиента.

Личный кабинет по ряду причин делать не стали. Этого не требуется. CRM реализована отдельно. Но можно было бы.

В планах было мобильное приложение, но решили не делать.

Админка содержит три кнопки по-моему :). Не помню, она в общем-то не нужна вовсе.

Кода самого ИМ - десятки килобайт. И столько-же со стороны системы управления.

Обращается к основной системе только в момент оформления заказа.

(заказы попадают в туду, клиенты в CRM итп)

Обрабатывает ошибки. В случае проблем - предлагает солидные скидки за багрепорты.

Выглядит в соответствии с тем, как хотелось.

Чистый код страниц.

По факту: обычная "витрина" с возможностью заказа.

Многие полагают, что ИМ должен делать что-то еще, я с этим категорически несогласен.

Не должен. Это придумки.

Всё остальное должно (и делается) под капотом и не должно "ложиться" из-за того, что 10 пользователей решили что-то поискать у вас в ИМ.

Возможно что-то забыл. Спрашивайте - отвечу.

Что-то там делал еще для сбора статистики... не могу вспомнить сейчас.

Всё это, в состоянии написать любой джуниор по сделанной для него спецификации.

Думается за 2-4 недели. Хотя современных джунов давно не видел.

Это не шедевр.

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

Если надо что-то доделать - можно дописать.

Если надо поменять - вполне реально найти место и поменять. Кода мало. Менять и искать просто.

Но надо уметь программировать.

Нет. "Они" дают оценку высказываний величайшего программиста нашей эпохи.

Это вообще 55 вопрос. Все умеют сделать фронт каким угодно. Вменяемые аргументы есть на многослов про?

(а это сильно помогает)

и далее по тексту.

и про

Далее не к вам.

Большинство перечисленного у danforth, поможет сильно

Но, там еще 100500, начиная с того что

while ($row = $res->fetchArray( SQLITE3_ASSOC )) {

  if(is_callable($this->selCallBack)){

    call_user_func_array($this->selCallBack, [ &$this->res, $row ]);

--------------

Тест на беременность (кто то выше пошутил😂 )

5000 запросов, по возможности 100 за раз ( ab -n 5000 -c 100 )

Профайлер (без нагрузки)

40 категорий, 11620 товаров, доставлено 200 хитов (лимит200), 4 подборки выборок товаров

Нужен толковый прогер с опытом, в принципе это единственный пункт, над которым нужно думать. А вы занимаетесь классическим бегом по граблям, выбирая cms. Я просто хочу напомнить, что cms на визитке не напечатаешь и в рекламном билборде не отразишь. И конечно идет наивный заход про seo :)

Я так понимаю, 10 страниц снова спорят про движки, фреймворки и методы. Классика.

У одного витрина, у другого блокируемая напрочь SQLite при записи и они доказывают за скорость, самописы и ИМ =))) Я с вами согласен ребят, инструмент надо выбирать под задачу, я рад что у вас такие задачи, что вам хватает 3х файлов и БД SQLite и вы даже не в курсе что такое очереди, nosql, шардинг, реплики и прочая херня, без которой и так можно сделать 3000 rps или 30000 rps. К сожалению у меня таких задач как у вас нет.

Aisamiery, речь про магазин на 500-1000 товаров. Зачем там очереди и шардинг, если это не маркет-плейс по продаже наркотиков?

Вообще я отвечал ребятам за скорость их самописов и удобство использования. При том они дальше старта (который закрывают CMS на 99%) в самописах не продвинулись, именно там где самописы в основном и раскрываются. При том люди, которые сами эти самописы пишут для себя и поддерживают. Они не понимают как это выглядит со стороны клиента и поиска и работы с подрядчиками.

А так, как количество товаров определяет сложность интернет магазина, это вот самое сравнение меня ставит в ступор периодически, неужели вы считаете, что для той же MySQL есть разница работать с 500 строками в таблице или с 500к строк?

И именно, тут речь что человеку нужно всего то развернуть магазин на 3.5 калеки, с функционалом который есть в опенкарте + шаблон за 3500р + 10 часов доработки напильником от спеца в итоге по времени за пару дней. А тут про самописы загоняют, чего нет то.

Конечно есть, на 500 строках даже индексы скорее всего не будут использованы.

Все зависит от дизайна.

CREATE TABLE product
(
    id                     INT UNSIGNED PRIMARY KEY AUTO_INCREMENT,
    name                   VARCHAR(255) NOT NULL DEFAULT ''
);

CREATE TABLE category
(
    id        INT UNSIGNED PRIMARY KEY AUTO_INCREMENT,
    parent_id INT UNSIGNED,
    name      VARCHAR(255) NOT NULL DEFAULT '',
    include_sub_categories BIT(1)       NOT NULL DEFAULT 0
);

-- design #1 --
CREATE TABLE product_category_flat
(
    category_id INT UNSIGNED,
    product_id  INT UNSIGNED,
    sort        INT NOT NULL DEFAULT 0,

    PRIMARY KEY (category_id, product_id)
);


-- design #2
CREATE TABLE product_category_parent
(
    category_id INT UNSIGNED,
    product_id  INT UNSIGNED,
    sort        INT NOT NULL DEFAULT 0,

    PRIMARY KEY (category_id, product_id)
);

Сами таблицы одинаковы. Но они содержат разные данные.

Первый product_category_flat в тупую добавляет товары в категорию, если у родителя установили include_sub_categories, нужно взять товары всех подкатегорий, и добавить в родителя.

Или

Взять другой дизайн product_category_parent, где при выборке товаров из категории, при наличии include_sub_categories = 1 у родителя, мы вынуждены ещё получить эти подкатегории, затем получить товары включая подкатегории, и только тогда вывести их. А сам запрос превращается в SELECT DISTINCT(product_id) FROM product_category_parent WHERE category_id IN (...)

Это реальный пример из реального проекта на CMS, ко мне обращались люди, у которых листинг товаров грузился по 12 секунд. 12 секунд, Карл! Виновников было много, начиная с плагинов, которые возвращают по 40к строк зачем-то, заканчивая отсутствующими индексами. Конкретно пример выше позволял делать три запроса быстрее, один из которых на тот момент выполнялся за 0.531 секунд, после смены структуры стал выполнятся за 0.003 сек. На самом деле, смены структуры не было (делали на тестовом сервере), потому что это сломало бы все обновления. Поэтому терпят до сих пор.

Здесь дисертацию защищают?

Opencart 3.* сразу по спидомерке показывает 80-90+ / 90+ без заморочек на шаредном хостинге (если слайдеры тяжелые не вешать) (другие измерялки подтверждают скорость)

Прогеры нафик не нужны, без них всё работает и даже лучше без них, мороки меньше