Ну и что? Это нормальное решение цель которого универсальность. Плюс минус такая же ситуация и в битрикс. Вот тебе пример из мира битрикс запрашиваю типовым методом элемент из инфоблоков (аналог того к чему у тебя претензия в ВП). Способ получения устаревший, но уверен 3/4 если не больше разработчиков сделают именно так:
$res = CIBlockElement::GetList( [], [ 'IBLOCK_ID' => '15', 'PROPERTY_PATTERN' => 'manstan' ], false, ['nTopCount' => 1], ['ID','NAME'],);
Это порождает (уточню я фильтр сделал всего лишь по одному свойству)
SELECT BE.ID as ID,BE.NAME as NAME FROM b_iblock B INNER JOIN b_lang L ON B.LID=L.LID INNER JOIN b_iblock_element BE ON BE.IBLOCK_ID = B.ID INNER JOIN b_iblock_element_prop_s15 FPS0 ON FPS0.IBLOCK_ELEMENT_ID = BE.ID WHERE 1=1 AND ( ((((BE.IBLOCK_ID = 15)))) AND ((((FPS0.PROPERTY_135 LIKE 'manstan')))) ) AND (((BE.WF_STATUS_ID=1 AND BE.WF_PARENT_ELEMENT_ID IS NULL))) LIMIT 1
И многие кто ушел продукт и "когда то имел дело с этим ужасным битрикс" сделают так же и будут мне показывать "безумное количество джоинов", которое по мерками их текущих крупных проектов кажется чем то ужасным..
Но вот кто в теме изменений, тот уже сделает иначе
\Bitrix\Iblock\Elements\ElementPatternTable::query() ->setCustomBaseTableAlias('e') ->setSelect(['ID', 'NAME',]) ->setLimit(1) ->where('PATTERN.VALUE', 'manstan') ->exec();
И получим уже менее ужасный запрос
SELECT `e`.`ID` AS `ID`, `e`.`NAME` AS `NAME` FROM `b_iblock_element` `e` INNER JOIN `b_iblock_element_prop_s15` `iblock_element_prop_s15` ON `e`.`ID` = `iblock_element_prop_s15`.`IBLOCK_ELEMENT_ID` WHERE `iblock_element_prop_s15`.`PROPERTY_135` = 'manstan' AND `e`.`IBLOCK_ID` = 15 LIMIT 0,
Так что уверяю - я представляю запросы. :) Но еще раз уточним: это решение из коробки, и оно используется до тех пор, пока все устраивает. Как только упираемся в ограничения - можно принимать другие решения. Как частный случай в ВП есть некие плоские таблицы, в Битрикс из коробки под это можно заточить так называемые HighloadBlock . Но и так же можно создать нужную для задачи структуру таблиц (хочешь нормализованную, хочешь нет)
Согласись любая CMS это попытка уменьшить работу программиста до минимума. Т.е. достаточно странно примерять высоконагруженную систему на универсальное гибкое решение и клеймить за неповортливость cms. Если эти таблицы узкое горлышко - не используй. Таким образом условно всякие статьи, блоги, и прочее подобное (по сути статический контент) храниться в штатной системе, а каталог (возможно только свойства) в отдельных таблицах... тут уж дело архитектуры конкретного проекта - все решаемо.
Мы имеем универсальное годное решение для минимизации вложений в проект. По крайней мере в пору "до ИИ" время программиста стоило дорого. А тут контент менеджер зашел в админку потыкал мышкой, а то и вообще просто в 1Ске новое свойство товарам завезли, произошел обычный обмен ... и вот уже на сайте пользователи в фильтре выбирают товары по этому свойству. И это все без участия разработчика.
Не согласен. (по крайней мере с рядом оговорок)
1. Денормализация данных вполне распространенное решение там где встает вопрос производительности
2. Я погуглил про ВП и вариации. Т.е. если я правильно понял "вариация" === "торговое предложение в Битрикс" и основное проблема это большие запросы. Так наверно эти "плоские таблицы" которые из коробки просто надо грамотно использовать.
3. Вообще я считаю тут нет проблемы вообще. Из коробки имеем гибкую систему, но дорогую. Как только это начинает напрягать - переписываем часть проекта без использования этой системы. и все.
Ну все разные. Я например с 2009 года на битрикс (правда только с 13го полностью в веб нише, до того это было на уровне доп "развлечения" :). Ведь дело то не в Битрикс/не битркис, а в решаемых задачах. По сути у меня сейчас проекты в которых основное это некий модуль большой.
Опять же это речь о программистах. Но здесь, как я понимаю, больше речь про СЕО.
Хм. не видел такого. Видимо это осталось за пределами этого обсуждения. ок. В любом случае наверняка это было в контексте их задач. И сомневаюсь, что FastApi помогла бы им при прочих равных.
Ну это попахивает высокомерием. Вполне ожидаемо что капитализация проектов типа вайлберис, авито, вк, и прочих продуктовых большая и не сопоставима с большинством сайтов. Но такие проект и не нужны в больших количествах. Какая нафиг разница сколько продукт занимает на рынке? Что от этого нельзя получить достойный доход конкретному человеку? Давай сравним тогда спейс икс и твой рабочий проект - смысла нет, но наверно в космической нише бюджет чутка повыше.... ты уже считаешь себя нищебродом? ;)
Ну т.е. вся беда апоннентов в том, что у них другой круг задач?
Ну судя по названию задачи кеширование вполне рабочее решение. Т.е. вся суть, кака я понял, найти дубли. Если там есть динамические тайтлы, то их надо все вычислить и куда то сложить. Если товаров очень много и все это в памяти накапливать то вполне может быть что в один прекрасный момент все отваливается. Ну а если скидывать в кеш (не важно как реализованный) - это выход. (но тут конечно нужно знать детали задачи)
Первый вопрос и мешает все в кучу. Там противопоставляется FastApi и ВП. Что уже в корне некорректно. Т.к. тут сразу несколько тем для баталий: питон/пхп, фреймворк/CMS, синхронное/асинхронное. Т.е. FastApi логичнее сравнивать с фреймворк + road ranner например..
Далее. Исходя из моего опыта холиваров (там где сходились Битрикс vs ВП) - в Битрикс должно быть в твоем сравнении все еще хуже :) (и именно в обсуждаемом направлении). По этому я думаю, что обобщить в CMS вполне допустимо.
А так же в тех же холиварах сталкивался с теми к то "когда то что то делал на битрикс", а сейчас уже давно сидит в большом продукте и примерно понимаю "источник" их позиции (и их позиция ОЧЕНЬ похожа на твою). :)
И что? Спроси у GPT что такое инфоблоки в Битрикс. Вся эта цитата мне понятна. "Кастомные поля" - в битрикс это пользовательские поля инфоблков. Эта мега удобно для расширения сайта без привлечения программиста. Но. Сайт с 10тысячами товаров и с 3мя тысячами свойств может работать тормознее чем сайт с 150 тыс товаров + 150тыс торговых предложений (в ВП судя по твоему сообщению выше тоже есть аналог ты говорил что то типа "вариации"). Там даже если глянуть запрос: там пипец какая портянка. И на это заточены все компоненты того же каталога. И так же есть мнение что все "жостко". Но в реальности ни что не мешает нам в каких случаях какие то данные перенести в отдельные таблицы. И взаимодействовать с ними хоть без ОРМ битрикс, хоть вообще не используя битриксный коннект к БД. Да потребуется сделать свои компоненты, потребуется доработать индексацию для умного фильтра. Но весь вопрос в том что в конкретном проекте "дешевле": переписать все или достаточно только какую то часть реализовать. В общем, судя по твоим же сообщениям, в этом плане много общего в битркис и вп (что в принципе логично) потому я и думаю, что в данном сравнении вполне норм объединить в CMS. Или хочешь сказать что в ВП, как то технически смогли работать с базой данной на прямую и нет возможности создавать свои модификации компонентов?
А ну вот и ответ.
Ну т.е. тут речь вообще не о ВП? Просто тут речь про пользователей конкретно этого форума? (который, скажем так, не совсем про программистов). Думаешь если говорить о таковых "пользователях ВП" они ринуться фигачить на FastApi ? :) Согласись в таком разрезе сравнение вообще не корректное.
Ну так в этом и суть. Все зависит от решаемых задач конкретного проекта. Как выше и говорили: если CMS решает значимую часть задач проекта, то почему бы и нет? Для примера сайт эльдорадо на Битрикс. Там уже точно так же дофигища кастома. Но тем не менее они так и не ушли с него окончательно. Хотя там и товаров (правда сейчас в принципе как то эльдорадо уже не тот) и свойств товаров, и посещаемость думаю в лучшие времена была "значимая". (в общем то я знаю инсайды и других крупных магазинов - то что так же решающих точечно вопросы производительности)
Это не обязательно решать переходом на лару полностью. И архитектура тут тоже не причем. Надо понимать, что абсолютно любая CMS это всего лишь набор готовых решений, который ни как не ограничивает. Если тот же ВП решает большую часть задача зачем переписывать все? Ни когда не поверю что на ВП нельзя написать модуль, который будет по своему хранить информацию. А значит все узкие горлышки можем реализовать как потребуется. Мне кажется я писал, но повторюсь: с ВП я не имел дело, но уверен, что ситуация не сильно отличается от Битрикс. Так вот на проекте где встали вопросы нагрузок, мы просто часть информации вынесли из инфоблоков (а это гибкое, но тяжелое решение, как раз таки про хранение данных) в сосбственную историю хранения. Тут же и денормализованные данные в той же БД, часть данных перенесли в отдельную БД, а часть данных стали писать в кликхаус. Так же, надо понимать что есть и другие инструменты в наличии, те же FFI, да хоть что то на микросервисы убрать а там хоть Go, хоть франке пхп...... Да хоть даже на той же ларе можно спокойно написать.. Это же php - CMS не накладывает ни каких ограничений. Единственный "минус" - старт ядра. Не знаю как в ВП, в Битриксе это "тяжелое"... Но надо понимать и почему оно тяжелое. (Опять же ни кто не мешает выделить что то в микросервис - там хоть на асме ваяй :) ).
В общем тут вообще вопрос не спора ВП/не ВП. Если есть проект 90% задач справляется ВП, зачем переписывать все, если нужно только часть? Там в ВП нет кеширования совсем что ли?
Ну такое себе. Это не на этом форуме если серьезно обсуждать. И по опыту баталий подобных про Битрикс, практически уверен, что именно программист постоянно работающий с ВП на хорошем, глубоком уровне, спокойно все обоснует и докажет... Все же если мировую стату брать то ВП среди CMS популярный, не думаю что он был бы таким популярным, если был бы на столько плох, а битрикс не мог бы его по мировой стате обогнать... :)
ЗЫ Опять е все упирается в конкретику. Уверен подавляющее большинство сайтов из категории где CMS достаточно. Вопрос только в том, какой объем задач проекта она решает
