и с таким подходом даже практически отпадает желание смотреть на фреймворки MODX — это тоже фреймворк. Так, на минуточку :)

xPDO на уровне выборки формирует только SQL-запрос. Сам же запрос выполняет СУБД. Это важно помнить. Это я понимаю, просто для упрощения работы использовать xPDO. На самом деле от очень многих… А расширение шаблонов — это вообще просто мегафича, освоив которую, уже никогда от нее не откажешься. Вот я и посматриваю в эту сторону, это более «вкусно» выглядит по использованию ModX + ускоряет работу, уменьшает нагрузку и с таким подходом даже практически отпадает желание смотреть на фреймворки

Просто сам факт, что можно отказаться от многих сторонних сниппетов и это все быстрее делать в шаблоне, не дает голове покоя. На самом деле от очень многих… А расширение шаблонов — это вообще просто мегафича, освоив которую, уже никогда от нее не откажешься.

Я подумываю для выборок использовать xPDO xPDO на уровне выборки формирует только SQL-запрос. Сам же запрос выполняет СУБД. Это важно помнить. Многие этого не знают или забывают. , а для вставок(там их будет не много) чистый sql. А вам в любом случае придется юзать чистый SQL :). xPDO не умеет формировать запросы на вставку, как это не печально. Вот смотрите xPDOObject::save(). Как видите, там чистый INSERT INTO… А xPDOQuery::command() поддерживает только SELECT|UPDATE|DELETE.

Насчет базы данных, то пока однозначно MySQL. С таким объемом она справиться на ура. C nosql не так все просто, один очень крупный белорусский портал с посещением примерно в 1 000 000 пользователь в сутки, на кеширование использует mongodb и хлебонул с ней горя. Я подумываю для выборок использовать xPDO, а для вставок(там их будет не много) чистый sql. Насчет смарти я имел ввиду чисто с практической точки зрения использования для себя. TV параметров предполагается использовать по минимуму, стандартных modx полей в шаблоне тоже не много будет. Просто сам факт, что можно отказаться от многих сторонних сниппетов и это все быстрее делать в шаблоне, не дает голове покоя.

P.S. Николай, извини, не сдержался. Бесят такие советчики, которые представления не имеют о предмете. Все ОК.

minishop не рекомендую, он неплох из коробки но что-то допиливать там тяжело Вот прям тяжело? Судя по вашему комментарию в другом вопросе, вы мега-специалист по всему на свете. Не знаю, как в других решениях, но в MS2 из коробки есть возможность: — Замены класса корзины — Замены класса оформления заказа — Возможность создания любых методов доставки со своими классами-обработчиками — Возможность создания любых методов оплаты со своими классами-обработчиками — Каждому методу доставки можно назначить свои методы оплаты — Возможность расширить модель и таблицу товаров плагинами Итого, обладая только базовыми знаниями PHP можно унаследовать и расширить корзину, заказы, оплаты, доставки и товары. И этот магазин потом можно смело обновлять, ничего не сломается и не перезапишется. Куда еще гибче-то? P.S. Николай, извини, не сдержался. Бесят такие советчики, которые представления не имеют о предмете.

Спасибо. Тоже склонялся больше к Shopkeeper, хотя боюсь, здесь такое решение не приветствуется))

но во первых это кошмар для заказчика, он выколупает себе и тебе мозг, пока в нем разберется Делайте нормально для него, и не выколупает. Мне же не выколупывает. Остальное — ваше ИМХО, ничего не имею против.

то тут даже битрикс ляжет при выборке А что, битрикс с каких-то пор считается высоконагруженной платформой? Если что, он жрет гораздо больше, чем MODX. Не зря для него на том же таймвебе специальный тарифный план есть с повышенными теххарактеристиками. Это во-первых. А во-вторых, при чем тут вообще платформа, если речь о пользовательских таблицах, пользовательских данных и пользовательских запросах? И с чего вы взяли, что обязательно все должно развалиться? Если что, мускул давно уже многие миллионы записей тянет. На том же новостном портале (который я недавно разработал) одних только индекс-записей для морфологического поиска более 11 000 000 строк, не считая 75 000+ статей и всяких связанных с ними записей. Это еще при том, что сервер довольно-таки средненький (4 core 8 GB). А тут по всем таблицам всего 5 000 000 записей. Откуда такой испуг? Не надо предположений. Такие неуверенные предположения хуже молчания. И далее идем по списку… Смарти поможет в случие нагруженного шаблона (когда там много чанков в которых еще и сниппеты есть) Не буду это утверждение опровергать. Но при чем тут вообще Смарти и 5 000 000 записей? Да хоть 500 млн, или наоборот всего 500 записей. Смарти-то что с того? Это шаблонизация, а не работа с БД. Его тут в данном контексте вообще не имеет смысла обсуждать. xpdo при такой нагрузке ляжет, Опять-таки, при чем тут xPDO? И в каком именно месте ляжет? Понятно дело, что getCollection() многих тысяч записей делать не надо, но xPDO этим не ограничивается, getCollection() здесь вполне можно и не юзать. Да и на 10 000 записей getCollection() может развалиться, не говоря уже о миллионах записей. Но это, если и с 10 000 записей не умеете обращаться, так за миллионы точно браться не стОит. впрочем как и обычные sql запросы Учите SQL-запросы, и все у вас получится, может быть. Индексы и правильно составленные запросы рулят. Да и сам представь какая будет нагрузка если ты «тяжелый» запрос с join-ами по всем 5 таблицам выполнишь? А вы не юзайте «тяжелые джоины». Настройте нормально индексы, и лучше парные первичные/вторичные. И будет вам счастье. А если 30 человек примерно в одно время его выполнят? тут DDOS атака рядом не стояла, даже VDS ляжет. Делать все нормально надо, и работать будет ОК.