Разработка крупного интернет-магазина

А где взять деньги? Надо просто стать бизнесменом. Бизнесменов много.

А понимаю, что так можно на любой вопрос ответить в принципе, но вести беседу в таком ключе - это такое себе занятие 🚬

Не понял, в каком таком ключе. У людей есть сайт. Если делали сами – то такого вопроса не возникает. Если заказывали у специалиста, но специалист пропал – найдут другого специалиста.

Пятница, однако.

Если вы не разработчик, то вопрос битрикс/опенкарт (не к ночи и тот и тот ) или что-то-там-еще стоять не должен. Это задача архитектора, а не ваша.

Если поставлена задача. Делаете ТЗ, считаете бюджет и понеслась.

Если разработчик и у вас появляются такие вопросы, то лучше в подобную задачу не лезть.

Если 100 000 товаров всего итого в базе - то конечно имеет смысл CMS и только CMS. Но на практкие такая постановка задачи может означать, что товаров в базе 1 000 000, а есть в наличии и продаются 100 000, но остальные 900 000 по разным причинам выкинуть из базы нельзя.

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

Мы как-то слышали шедевр "мне мои прогеры советуют магенто, но ставить не битрикс как-то перед пацанами неудобно, у всех на битриксе"© 😂

Тут есть нюанс.

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

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

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

Это если вы туда elasticsearch повесите, то тогда конечно при большом количестве свойств надо будет намного больше работы, потому что он де-факто строит индекс по всем индексируемым полям. Но эластик можно настроить так, чтобы он работал даже не при миллионах записей, а при миллиардах.

Битрикс вычеркивайте. Опенкарт можете оставить, но...

У крупного интернет-магазина нет денег на IT директора?

Или они наняли такого, который здесь помощи ищет? Тогда выбирай Опенкарт. Так наверняка дешевле получится, раз дилетант.

Если речь о коробочных решениях магазинов, то даже поиск по свойствам (тут тоже с терминологией бы договориться.. речь, видимо, о тех, которые не добавляют "вариативности" у отдельных товарных позиций) , реализованным путём хранения EAV без "дублирования" в отдельную "поисковую" таблицу может солидно грузить базу.. )

+1.. В компьютерных комплектующих тоже интересно.

Вы на ходу придумываете? Где я сказал что битрикс лучше магенто? Я сказал что битрикс во владении и сопровождении априори дешевле чем магенто, владеть проектом на битриксе дешевле чем на магенто и всего лишь. Все ваши потуги надавить на говнокод вообще мимо. Вы вообще вон оптимизатор, а говорите "экспертно" за стоимость разработки на разных платформах еще и в отрыве от задач.

---------- Добавлено 25.04.2020 в 20:03 ----------

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

Их двое, и никогда не знаешь, с кем из едогсов дискутируешь.