CMS для интернет-магазина

Я бы попросил обосновать. Без конкретики типа "а вот сайт на попенкарт, зацени лаги", но фундаментальные трудности хотелось бы узреть.

kostyanet, фундаментальная трудность в том что кол-во товаров имеет значение т.е 1 товар в базе и 1000 товаров это все-таки разные вещи, иначе исходя из вашей логики у всех хостинг-провайдеров для всех сайтов должен быть всего 1 тариф )))

Как интерфейс может работать без скрипта в интернет-магазине мне трудно понять, предлагаете все страницы магазина перевести в обычный HTML и править каждую страницу вручную?

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

---------- Добавлено 04.08.2015 в 10:28 ----------

приятного аппетита )

Если бы вам нужно было только выводить данные об одном товаре за раз, то да, а если нужны все телефоны красного цвета с клавиатурой и ценой от и до? А на странице с одним товаром вы не будете выводить похожие, рекомендуемые, популярные? Кроме того, ТС ясно заметил, что хотел бы давать товарам свои атрибуты, что означает и их участие в выборках. Даже с двумя тысячами товаров можно сложным запросом напрячь базу, особенно, если она со связями многие-ко-многим.

З.Ы. "конечная станция интерфейса" - это что-то новое в юзабилити?

Как-то не слыхал такого термина...

Всем спасибо за комментарии, необходимые мне ответы были получены. Тему можно закрывать :)

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

Я же четко описал задачу - сайт состоит из продуктовых страниц и количество товара на сайте существенным образом не может влиять на скорость выдачи этих страниц. Добавив банальное кеширование мы сведем к нулям затраты на количество вообще.

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

Так вот количество товара, все эти перечисленные в предыдущем абзаце факторы - усугубляет. Сам по себе это количество ничего не определяет.

---------- Добавлено 05.08.2015 в 07:18 ----------

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

---------- Добавлено 05.08.2015 в 07:23 ----------

На сайте с миллионом продуктовых страниц добавить новую категорию в миллион раз труднее?

---------- Добавлено 05.08.2015 в 07:30 ----------

Короче, научитесь мыслить индустриально. Магазин - это товары. Залы, отделы, полки, продавцы - интерфейс доступа к товару. Цены, кассы, упаковка, доставка - условия сделки. В парадигме каталога ваш сайт должен иметь интерфейс клиента базы данных, в парадигме поиска - полнотекстовый поиск, скорость которого зависит от всех перечисленных, а количество лишь проявляет особенности реализации.

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

Разве вы ТС?

Как сферический конь в вакууме нет, а в обычных реалиях да.

Определитесь уже, все или один.

Коллега, эпоху коллективизации и индустриализации мы уже прошли.

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

Кэширование? Его никто не отменяет, но оно опять таки желательно не постраничное, а поблочное. Если говорить об описанном ТС количестве в тысячу или две товаров, то ломать копья в этом споре вообще нет резона, но если сравнивать тысячу и миллион, то разница очевидна. Например тысячу товаров я могу закинуть в XML (да пусть 1С мне его сгенерирует), а XML вообще сунуть в память, и всё будет просто летать. И я плюну на кэширование и буду всё генерировать контент страниц только динамически и творчески, без оглядок. С миллионом товаров всё несколько по иному. Если бы мне нужно выбрать только один товар по ID, то о количестве я и словом бы не обмолвился, но это ведь не так.

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

Я и говорю что количество товаров не имеет значения для выбора скрипта, поскольку в конечном счете цель - выдать искомый продукт. Что из миллиона один выдается за 1 сек, что из 10 штук - за 1 сек - этот факт доказан и никто не оспорил.

Что касается заморочек описанных в последних трех абзацах claygod, то это хороший пример как НЕ надо делать ИМ.

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

Юзабилити не является темой обсуждения, каждый делает в меру своего понимания.

Применять или не применять, это одно, иметь возможность применить, это другое.

Так напишите, что имеет.

Это провокация на холивар, не будем.. всё-таки топик пусть остаётся полезным.

Это(и) "трудности" служат только для развода лохов, а никак не для обсуждения специалистами.