Выбор движка для сайта ИМ/оборудовния

Я про конкретную реализацию, а не воду. В битриксе все продумано и делается все нативным кодом, вопрос был про архитектуру, которая упирается как минимум в структуру хранения их 2 основные, битрикс использует обе, у каждой свои плюсы и минусы, остальные cms используют одну из этих двух.

Вот башка мелит сама не понимает что. Откуда вам знать что есть а чего нет если вы вообще далеки от всего этого? Вы какой то говноблог там пилите, убийцу собственного времени. По моей ссылке есть например magento, на которой сделан walmart с оборотом за 2021г в $559 млрд. Или H&M с трафиком в 144 млн посетителей в месяц.

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

У меня башка, а у вас и башки-то нет.. Можно и без сайта зарабатывать создав сеть офлайн магазинов и др. Walmart разве на битриксе работает? Можно на лендинге\одностраничнике зарабатывать, речь не о доходе, а том какая система будет наиболее оптимальна для крупного интернет магазина, которую потом можно расширять и развивать... причём с минимальными затратами.

Ок, сейчас буду вспоминать как это у битрикса из коробки реализовано, ибо для своих проектов там все переделано...

И так, у битрикса есть удобный инструмент - инфоблоки, которые можно создавать под свои задачи. И это действительно удобно. Неудобно в них то, что скорость их работы оставляет желать лучшего. На инфоблоках реализовываются характеристики (свойства) товара. Когда в системе большой ассортимент, 5000 категорий и 50 тысяч свойств (к примеру) - с этим невозможно работать. Что в админке это работает крайне медленно (ты изобретаешь новые слова в русском мате, чтобы в очередной раз что-то высказать битриксу), что на странице товара подгрузка свойств занимает дохрена времени. А как работать было контент-менеджерам, которые добавляют карточки товаров, сиди ищи среди 50.000 свойств, те свойства которые тебе надо добавить?

Позже в битриксе появилась возможность привязки свойств к категориям, мы уже не грузим эту портянку в 50 тысяч на страницу. Проще контент-менеджерам стало. Но другие проблемы остались. Инфоблоки от этого работать быстрее на стали и очень медленная работа все еще актуальна (!). И, если мне не изменяет память, на программном уровне, мы все равно сначала запрашиваем огромный массив, из которого уже выбираем свойства нужные на конкретном товаре/категории. Не знаю в последних версиях (в последние годы) они это решили или нет... но согласитесь, даже если делать прямой запрос в БД, получить массив в 50.000 элементов и в 50 элементов - это совершенно разная нагрузка на БД и разное процессорное время.

Ок, не беда, можем каждую категорию вынести в отдельный инфоблок. Займемся e#лeй и создадим 5000 инфоблоков (это уже треш, но ладно, сказано сделано). И вот мы получаем уже из инфоблока всего 50 свойств для нужно категории. Процессорного времени уже меньше нужно, но это не решило проблему со скоростью работы самого инфоблока (!). Он как работал медленно, так и работает, но теперь у нас их 5000... Юзабилити просто "пресосходное" ))

Однако вырисовывается другая проблема, как быть с общими свойствами, типа - вес, габариты, цвет. И свойствами, которые повторяются, например - наличие вай-фай, порты ввода-вывода, диагональ экрана и пр. (их будет несколько тысяч, это как минимум). Что с ними предлагаете сделать, дублировать и потом костыли вставлять, чтобы объяснить битриксу, что свойство "диагональ" в одном разделе и в другом - это по сути одно и тоже и их можно между собой сравнивать. Да и что говорить, сама привязка свойств к категории для больших магазинов выглядит тупо и неудобно. Ибо в одной категории, например "аксессуары" может находится несколько десятков разных товаров... А как мне при такой структуре переносить товары из одной категории в другую? Короче гемор, как с точки зрения организации свойств на программном уровне, так и с точки зрения удобства пользования.

Ок, не беда, у нас же есть highload блоки, которые работают гораздо шустрее чем инфоблоки, можно что-то из этого реализовать на них. Но у них меньше возможностей в админке (из-за этого они и легче) и для этого придется все переписывать. Нанимать программеров, писать ТЗ, платить для этого много денег... Также нужно вставить тонну костылей, чтобы весь оставшийся битрикс понял и учитывал наши изменения по свойствам и что бы вся логика работы не поломалась. А лучше сразу ввести такой термин как тип товара, к которому уже будут привязываться свойства, тогда мы этот тип без проблем сможем переносить из категории в категорию и т.д. В общем надо городить огород в любом случае. И так мы на ровном месте получили танцы с бубном! )) И спрашивается, а нахрена?!

А еще, чтобы что-то настроить битриксе, надо кучу телодвижений совершить - зайди туда, поставь галочку там, потом зайди сюда тут поставь несколько галочек, потом зайди в свойства чего-нибудь и там не забудь вот эти галочки убрать... И главное ты должен все это знать и помнить! А если ты новичок в общении с битриксом, то без помощи программера можно и не разобраться! По итогу получаем большой и неповоротливый движок. Который на бумаге такой классный, все так радуются когда им пользуются, а на практике имеем что имеем - жирного, медленного, с кучей нюансов и компромисов франкенштейна. А если у тебя еще куча плагинов готовых из маркетплейсов установлены, которые как-то завязаны на стандартные свойства битрика, то добро пожаловать в АД, уважаемый! И это я сейчас только верхушечку айсберга обрисовал, меньше 1% тех проблем, которые придется как-то решать.

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

З.ы. в свое время, не безызвестный Ситилинк сидел на битриксе (если мне не изменяет память), но уже много-много лет назад они сделали свое решение на Симфони (опять же, если память мне не изменяет). Зачем было переходить с такого "замечательно" битрикса на самопис? Вопрос оставим открытым ))

М -маркетинг. Вот и пользуются. В свое время кто-то очень грамотный, сделал приписку 1С к битриксу, и предприниматели начали думать, что он с 1С-кой интегрируется лучше всех. А битрикс и сторонние разработчики только распускали слухи, что это действительно так (хотя это не так). Они просто получали "откаты" (партнерские отчисления) за битрикс. Ну и разработка на нем дороже, поэтому они еще поверх больше зарабатывали. Жажда наживы сделала свое дело, и рекомендовать битрикс стали из каждого утюга! Вот и весь секрет )

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

С чего вы взяли, что Walmart на magento сделан? Погуглил, нашел новость за 2018 год, что они позволили пользователям magento продавать у себя товары. Иными словами сделали плагин интеграции. Как у нас делают плагины интеграции с Озоном или ВБ, так и там...

В подобного рода крупных сетевых гипермаркетах, основной бизнес-процесс - это логистика (закупочная, складская, транспортная), это 90-95% всех бизнес процессов там занимает. Magento под эти бизнес-процессы не заточен даже рядом! Не удивлюсь, что там настолько своя система, что у них под себя собственный фреймворк написан! Не потянет никакой magento такой масштаб.

А где удобно? В опенкарте что ли? 50 000 атрибутов то пробовали заполнять? У вас кривое представление битрикса или вам попались кривые разработчики.

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

Во-вторых, если в выборках указывать какие свойства нужны, то будут не 50 000 запросов, а ровно столько сколько свойств вы указали.

В-третьих, да можно для каждой категории указать какие свойства должны быть, подскажите CMS где ещё так можно сделать чтобы были только нужные в каждой категории? А еще сразу подскажите, когда у вас есть 50 000 свойств, то есть менеджеры которые отвечают только за определенные свойства/категории, так вот в какой CMS кроме битрикса можно настроить форму товара под себя? При том каждый пользователь админки может настроить форму под себя исключительно?

Да не работает битрикс медленно, вон у людей на предыдущих страницах пустая по сути страница с 10 товарами на ней грузится по 5 секунд  с каталогом в 5к товаров, а вот так грузится у меня битрикс с 48 товарами на странице и кучей всяких модулей типа отзывов с маркета, фильтрами и кучей еще инфы 

при том там в инфоблоке как то так

и там еще 12 типов цен и да не 50 000 свойств конечно, а всего 300 и да там всего по сути 2 разработчика, при том не за железо ни за разработчиков проект не платит каких то "космических" денег.

Когда они называются одинаково (у них одинаковый код), то проблем обычно не возникает, так как свойства обычно выбираются по коду.

Битрикс вам ничего не запрещает, вы можете сделать там все что угодно при помощи программиста. И это будут не костыли, просто к сожалению те кто разрабатывает штатные компоненты они не могут учесть все ситуации жизненные, согласитесь, проект на 50 000 свойств очень уникальный и под него в любом случае возьмут программиста.

Это может быть и сложно первую неделю работы с битриксом, но тут как бы вообще странная придирка, а где нельзя помнить? погуглите, есть вопросы как ЧПУ включить на каком нибудь OC, а вроде базовый функционал, а надо было раньше лезть в код.

А что его открытым оставлять, давайте закроем. Битрикс это бомж вариант, это когда надо много и по дешевле. Вот у компании есть 2 млн и надо сделать проект, на битриксе вы сделаете достойного конкурента в ниши, а на симфони даже боюсь что MVP не сможете запустить. Когда компания перерастает битрикс, она уходит на самопис и так делают многие не только ситилинк, но вот чет я не слышал чтобы Эльдорадо с битрикса ушли на вордпресс или опенкарт... а почему? или его как раз и оставим открытым? У нас сейчас несколько десятков миллионов пользователей и да мы с битрикса уходим на самопис на go, в этом нет ничего страшного, просто под новую архитектуру больше подходит самопис на go в нашем случае и на это есть много миллионов ресурсов.

У вас какое то шаблонное мышление. Какой маркетинг? Вы знаете что если продукт говно то никакой маркетинг его не вытянет? А битрикс в целом даже ни разу не переименовывали с года так 2003 точно. Какие отчисления, вы о чем? О проценте с лицензии? Да это крохи при разработке ИМ, настолько крохи что их и считать как то глупо. Битрикс успешен оказался из за партнерской сети. Из за обучения разработчиков и из за опыта этих разработчиков. Люди которые готовы потратить миллионы на проект не придут к местному барыге, а придут в студию, которая сделала им конкурента или просто те кто на слуху, а такие студии работают с битриксом, потому что проще найти людей, проще обучать людей и проще передавать экспертизу. Найти толкового вордпрессера среди тысяч школьников достаточно сложно, а еще и такого кто бы смог спроектировать каталог на 50 000 свойств.

Где то слышал давненько, сейчас выкупили их адобэ и чет нет такой уже инфы на сайте. Но тут тоже список солидный так то https://staylime.com/insights/top-10-companies-using-magento/ У вас какое то странное представление о платформах CMS, магенто как раз вытянет, она хорошо и модульно расширяется, её можно дописать при наличии нормальных разработчиков не хуже, чем если просто взять с нуля симфони и писать. Так же как и битрикс это просто фреймворк, который поставляется с кучей готовых компонентов, но вас их использовать на самом деле никто не заставляет, пишите свои, которые будут делать то что вам надо хоть кота с яйцами сравнивать. Битрикс как и магенто даст вам богатое апи для старта, готовые модули в виде корзин, скидок, фасетных фильтров, рассылок, абтестов и прочего прочего прочего, при наличии разработчика который со всем этим умеет работать можно запустить большой и функциональный магазин в короткие сроки и вменяемый бюджет для старта.

Вы каждый раз доказываете обратное:

Вы определитесь, либо для мелких магазинов которые себе позволить не могут, либо .... да даже не заю что либо. Сначала пишите одно, я говорю что на CMS делают те у кого денег задницей жуй и тут же вы переобуваетесь.... Хотя о чем это я говорю, тут всегда так, в башке то один костыли судя по всему =))

Там, скорее всего, какой то раздел сайта/где то на другом домене, но в инфраструктуре валмарта.

Вроде https://accessories.ford.com/ (который первый по вашей ссылке):  Top 10 companies using Magento,  а форд.ком, скорее всего, на чем то другом. Иначе, просто бы написали форд.ком наш.

://accessories,  кстати, предполагает более менее ассортимент и вариабельность его, в отличии от собственно машинок. Выбор магенты, если это она, что то значит.

Кстати,

(py39a) [www@localhost ~]$ wrk -c 500 https://accessories.ford.com/
Running 10s test @ https://accessories.ford.com
  2 threads and 500 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency   269.66ms  232.65ms   2.00s    89.79%
    Req/Sec     0.91k   168.08     1.32k    77.27%

18028 requests in 10.02s, 104.30MB read
  Socket errors: connect 0, read 0, write 0, timeout 86
  Non-2xx or 3xx responses: 
18028
Requests/sec:   1800.05
Transfer/sec:     10.41MB

vs

(py39a) [www@localhost ~]$ wrk -c 500 -H "user-agent: Mozila qqqq"  https://accessories.ford.com/
Running 10s test @ https://accessories.ford.com/
  2 threads and 500 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     1.39s   349.45ms   1.98s    65.08%
    Req/Sec    24.45     15.20    80.00     69.86%
  382 requests in 10.01s, 103.09MB read
  Socket errors: connect 0, read 0, write 0, timeout 319
Requests/sec:     38.16
Transfer/sec:     10.30MB

Non-2xx or 3xx

Non-2xx or 3xx

Грамотно, но мб примерно одинаково отдали. Видимо 404/... по объему сопоставима.

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

Тихонько поворачиваемся к веб строительству. И начинаем формировать понимание  заказчика про ТЗ/бюджет 

Я про опенкарт вообще ничего не говорю. Я в самом начале сказал, что бесплатные CMS недолюбливаю. И опенкарт в их числе )

По поводу разработчиков: Ну можно конечно допустить, что штат программеров с зарплатным фондом более 1 млн рублей в месяц и еще несколько удаленщиков, все попались бездари... но есть у меня сомнения на этот счет. У ребят опыт работы за плечами не маленький и в достаточно крупных проектах. По сути я сам разработчик, в этом плане (сам конечно не программирую уже давно, чисто руковожу). Все разработки делаются своими силами, изредка привлекаются люди из-вне. Плюс я очень много общаюсь с бизнесменами, которые также сталкиваются с аналогичными проблемами. Очень сомневаюсь, что у всех работают программисты-дурочки.

1) Овощи с компьютерами никто не мешает. Например мышки компьютерные, могут находиться в разных разделах - в периферийных устройствах, в аксессуарах для ноутбуков, и в аксессуарах для компьютеров. И таких товаров очень много. Там карточка товара одна, а показывается в разных категориях. Более того скажу, в больших магазинах структура каталога постоянно меняется. Постоянно добавляются новые категории, трутся старые, товар из одной категория в другую переезжает и т.д.

2) Не совсем понял что вы предложили, честно говоря... Прежде чем запросить какие свойства мне нужны, нужно понять, какие из свойств соответствуют конкретному товару. Иными словами мне нужно знать сначала коды свойств (ID свойств), а уже потом их запросить из тех 50.000, значения этих свойств. Да и когда вы запрашиваете 20 свойств из таблицы с 50.000 свойствами, это работает на несколько порядков медленнее, нежели вы запрашиваете те же 20 свойств из таблицы где всего 100 свойств... Иными словами мы упремся не совсем в функционал битрикса, а в скорость работы БД. Из-за того, что битрикс так решил хранить свойства в этой самой БД.

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

3) Указывать в категории какие должны быть свойства - это костыль, который работает через задницу. Мало того, что мне нужно добавить новое свойство, мне еще нужно не забыть его прописать для категории. И в случае, если у меня в одной категории разные типы товаров лежат, мне нужно заранее продумывать и добавлять туда свойства из других категорий. Это и куча телодвижений, и в общих категориях для контентщиков будет снова портянка свойств, которая будет снижать скорость заведения карточек товаров.

А то решение, с вводом понятия типа товара (которое описал во втором пункте), на сегодняшний момент наиболее жизнеспособное (на мой взгляд). И с точки зрения удобства и быстроты пользования, и с точки зрения скорости вывода на страницу.