Тут уже были аналогии мне пришла в голову другая. Есть Вася он водитель БелАЗа и возит камни по 140 тонн за ходку. Есть водители газелей которые тоже возят камни, но по 2 тонны. И вот Вася приходит к ним и требует доказать, что Газель крутая машина. При этом по условиям его задачи доказывать нужно исходя из того что надо перевозить по 140 тонн. Не понимая, что 140тонн за раз им вообще ни кому нахрен не уперлось перевозить, а так же у них есть важная необходимость передвигаться по обычным дорогам в т.ч. и в населенных пунктах. Так же он только по 140тонн считает "серьезной" грузоперевозкой, т.к. он оперирует своими личными критериями серьезности. А для газелиста Пети важнее, что он подписал контракт на поставку с крутым ландшафтным дизайнером у которого клиенты звезды и получает по ляму за камень. (да может быть еще 100500 причин по которым дела тех газелистов могут считаться серьезными)
Итак погнали
Для этого в первую очередь ты должен понять их цели и задачи, а не пытаться натянуть сову на глобус. Им не нужны твои 140тонн. Это только в твоем мире это критерий серьезности. Для большинства критерии иные. Для них твои перевозки лишь частный случай перевозок со своей спецификой.
Костыль они только для тебя потому что это не подходит для твоих задач. (Напоминаю 140 тонн перевозить нахрен ни кому не надо кроме Васи)
А может потому что изначально обсуждение не подразумевает технической четкости обоснований ввиду несуразности поставленных условий.
Зачем мне объяснять им то, что я считаю глупостью? Да Вася перевозит по 140тонн за раз и не понимает, зачем газелисту Пете склад (ведь это уже не газель). А так же, по прежнему, не понимает, что Пете не нужно ни 140тонн за раз перевозить ни, даже, склад на 140тонн.
Хочешь грамотного обсуждения возможностей ВП, так и обсуждай его в контексте задач для которых его используют.
Ведь есть еще танкеры который перевозит 320тысяч тон, и капитан которого считает БелАЗ Васи абсолютно дебильным ни чего не умеющим транспортным средствам. Он придет к Васе и потребует доказать что белаз это круто для задачи перевозки 320 тысяч тонн
Вот именно в этом и ключ. У тебя есть свое восприятие серьезности ввиду твоей работы. И ты начинаешь измерять абсолютно все этими мерками. Примерять на свой рабочий проект ВП. (об этом тут уже не раз говорили по сути). Инструмент должен соответствовать задаче. Возможно для тебя 300К товаров и 3000 свойств товаров не серьезно, возможно RPS 1500 не серьезно. Но, поверь, это ситуация далеко не всех и даже не большинства интернет магазинов. И задачи там бывают достаточно интересные под капотом. Согласись на многих сайтах то что видит посетитель может быть лишь вершиной большого айсберга. И задачи бывают такие, что не "уровень джуна" или читателя "Сайт за 24 часа".
Ну а если такими аршинами как у тебя измерять. Так серьезных проектов то не так много ну может тыща - десять тысяч на весь мир - нет смысла обсуждать. Ни кто с ВП в их нишу не суется.
В общем если суть темы "Вп не подходит для создания ВК" да ты прав. точка. ни кто не пытается и даже не говорит что ВП годен для этого. тему можно закрывать :)
Ну и что? Это нормальное решение цель которого универсальность. Плюс минус такая же ситуация и в битрикс. Вот тебе пример из мира битрикс запрашиваю типовым методом элемент из инфоблоков (аналог того к чему у тебя претензия в ВП). Способ получения устаревший, но уверен 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го полностью в веб нише, до того это было на уровне доп "развлечения" :). Ведь дело то не в Битрикс/не битркис, а в решаемых задачах. По сути у меня сейчас проекты в которых основное это некий модуль большой.
Опять же это речь о программистах. Но здесь, как я понимаю, больше речь про СЕО.
