Эээ... а нафига интернет-магазину БД :) ?

Ну не знаю, не знаю - может у меня фантазия плохо работает. Вообще к Битриксу долгое время скептически относился. Месяца четыре назад запустили с партнером магазин. Изначально склонялся к студийному решению, в бюджете ограничений не было, не устроили предлагаемые сроки реализации да и те кому по силам задача была - отпугнули своей неповоротливостью. В конечном счете выбрал битрикс. Сейчас параметры у магазина примерно такие, в сутки обрабатывается 100-120 заказов, среднее количество строк в заказе - 18, в среднем на посетителя приходится порядка 12 просмотров, ну и плюс многообразные и достаточно сложные фильтры, виртуальные категории, вполне себе все шустро работает

Какие?)1234567890

mendel, простота в поддержке, лёгкая управляемость проектом, гибкость, ну и чисто сеошное - это продвигаемо :)

Без СУБД?)

с какого перепуга? Бекофис то у нас утолщается. При этом еще есть точка стыковки двух систем. Это тоже дополнительная сложность.

Без СУБД?)

Без СУБД? Да 90% сеофишек на связях так или иначе завязано.

Нет, можно по сути витрину использовать чисто как кеш, но... что это даст?

Ваш подход по уносу всего оформления в ЖС, а кто не ЖС, тот или робот или ССЗБ -я знаю, и не оспариваю. Не скажу что согласен, но такие эксперименты я тоже делал, и вижу в них здравое зерно. Только муторно... но мы говорим о фронте без БД и жЫрном бекофисе. В чем бонус? Дешевле хостинг разве что. Всё остальное минусы.

mendel, на все вопросы да, при условии хорошей архитектуры проекта

Никак, нет требований.

Но вообще, не вижу проблемы, статику вы можете ведь менять и на клиентской стороне через js.

Опять-таки ОДИН раз забираете информацию с сервера, а потом уже показываете своё "ваша скидка ХХ%".

Да, на сервере надо будет как-то хранить, но опять-таки в очень "тонком" виде.

---------- Добавлено 27.12.2016 в 11:46 ----------

Да вот я к таким-же выводам пришел.

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

И как с таким феррари победить :) ?

При этом я его допилил. Он работает. Что надо делает. Едет короче.

Но времени на это ушло вагон + тележка, и делает он это "всё" всё равно не так как надо.

Ей богу, лучше бы сразу выкинул.

---------- Добавлено 27.12.2016 в 11:48 ----------

Да как-же так ?

Даже если ляжет mysql на легком фронте, даже если кончится место на диске,

даже если умрет ВСЁ, то статика будет продолжать отдаваться клиентам,

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

собственно это всё, что нужно, способность запускать 1-2 сервер-сайд скрипта

для отправки почты)

Наоборот - это безотказная система. Сами продажи продолжатся и после

ядерной войны :).

Причем заметьте, вся "точка отказа" у вас "собрана" в момент загрузки новой

информации, т.е. вы в состоянии хоть как-то протестировать, что получилось.

И никакой деградации после этого не бывает даже в принципе.

БД не переполняется, к примеру тут наблюдал, как база выростала на 100-200мб

в день, оказалось туда какая-то статистика профайлинга пишется, это какими-же

имбецилами надо было быть, чтобы писать её не в текстовый файл.

И сколько еще таких шуточек встроено в коробку ?

Там клоудфларе предлагали... не то... меня не устраивает кеширование для второго

клиента, я не хочу, чтобы робот гугла ждал по 11 секунд страницу, если он пришел первым.

---------- Добавлено 27.12.2016 в 11:57 ----------

А в чем сложность-то и затратность в разработке ?

Если вам нужны специфические требования, то разрабатывать 100% придется.

На любом "стоковом" решении вам надо будет изучить обширные и ненужные вам свистелки

и перделки, и заставить их работать (не мешать работать) вашему решению.

Если в "тонком" магазине ничего лишнего нет, то вы экономите на этом геморрое.

Я тут уже "топором навырубался", до последнего терпел, но невозможнож.

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

и вообще вы спецы - фигачьте, а у меня другие задачи и интересы в жизне".

Тогда да - клиент получает битрикс, и пусть года через три закрывается, всё равно добра не будет.

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

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

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

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

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

а от этого кстати зависит поиск

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

У меня сейчас сотни полторы запросов на страницу в моем движке.

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

Жадные связи сократят колво запросов раза в два, а то и на порядок. Кеширование футера, топменю и сайдбара - оставят в буквально 5-10 запросов, при 100% инвалидации кеша. Это допустимая цена за гибкость.

В этом месте я говорил в контексте "запросы на внешний сервер".

Ваша голая статика будет жить и при ядерной войне, да. Собственно это ее ЕДИНСТВЕННОЕ здравое преимущество. Все остальные незаметны в приципе.

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

Вы просто вынесли свою сложность в бекофис. Если бы бекофис был бы стоковым, то и с тонким клиентом была бы та же лажа)

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

В этом главный вопрос.

Когда у вас будет по 10 магазинов в месяц. Даже не новых. Старых. На обслуживании, допиливании... тогда будет совсем другое ощущение.

Сначала вас взломают. Ну вот просто возьмут и зальют шел. И то что у вас одна статика - вас не спасет. Писать долго. Но взломают. Обязательно взломают.)

В этом и смысл. Сложность там, где ей место. В бэкофисе она всё-равно будет.

Бэкофис под это приспособлен изначально.

И сделать бэкофис из интернет-магазина в общем-то можно конечно, но только

если "для дяди", т.е. это неразумное вливание денег и сил.

Именно.

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

высосать из клиентов побольше бабла. Может прям сразу реализовать то, что нужно,

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

Я не дурак, и не подлец. Я не возьму 10 магазинов "на допиливание".

Не надо в рот тянуть больше, чем можешь откусить...

Чё, правда что-ли ?

Кто-то будет взламывать самопис :) ?

Вы правда считаете, что он более уязвим, чем коробочное решение ?

Решение, взломав которое получишь сотни тысяч потенциальных жертв, а не считанные единицы ?

Я всегда очень серьезно отношусь к безопасности. Зарекаться бессмысленно.

Но точек атаки у меня в сотни раз меньше, жертва я в сотни тысяч раз менее привлекательная,

а квалификация... увы, у кодеров стоковых движков похуже моей будет.

Я был бы рад, если бы было наоборот, но увы. Что есть, то есть.

Экономический смысл взлома при всём этом как-то теряется, только если

"назло бабке уши отморожу", но при таком подходе могут и просто на улице

заказать "удар по башке молотком"...

Статика имеет и еще один плюс.

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

Никакой настройки всё это не требует. Мне пофиг и на версию php и на версию mysql,

мне пофиг на настройки БД, на кеширование, мне вообще на всё пофиг, оно будет работать

в стоковом LAMP без каких-либо модификаций. (хорошоб нгикс настроить, но сразу можно

этого и не делать). Вообще нет никаких нужных нетривиальных сервисов для работы.

И ничего со старой системы мне забирать не надо. Никаких баз, никаких данных.

Всё залью по-новой.

нет не теряем ;)

т.е. вас может положить любой школьник запустив парсер в 1000 потоков? :)