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

потому что все подобные продукты пишут программисты - они по другому думать не умеют ;)

Кхе... кхе... у меня опыт "программирования" 30+ лет.

При этом попробовав третий раз "натянуть" требования на то, что предлагает рынок в качестве заготовок, я ДУМАЮ, что мне этот секс не нужен совсем.

Лучше тонкий простой движок, чем та порнография, которую предлагают как "готовый интернет-магазин из коробки".

ERP доделывать всё-равно, так не проще ли выдавать на её выходе либо сразу статический html, либо ресурсы, которые легко шаблонизатором в такой html превратить. Остается добавить корзину, one page checkout и всё...

ЗЫ. Это все не теория, доделываю уже, нет сомненья, что "взлетит". Фактически осталось подправить верстку итп. В результате "написать всё это с нуля" оказалось даже быстрее, чем заставить хоть как-то работать "изкоробочный" вариант.

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

тем более маркетологи от разработки навязывают мнение что всё вообще должно храниться в сети и быть доступно из любой точки мира (что по своей сути уже является полным бредом)

а если часть функционала переложить на "клиента", то можно ещё более упростить серверный функционал ;)

Корзины все одинаковые.

Чекаут всё равно переписывают на 70-100%.

А что ёще разное-то ? Такое разное, что в типичном интернет-магазине оно типа "универсальное" ?

Как по мне, так любой магазин состоит из категорий, товаров, и возможно каких-то поисков-сравнений (не у всех).

Первое и второе почти у всех одинаковое. (забудем на минутку об атрибутах, оказалось что их тоже гораздо проще интегрировать с нуля).

Поиск и сравнение тоже приходится переписывать в стоковых движках.

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

Или нам надо, чтобы название организации в БД хранилось, и для генерации каждой страницы десятком запросов оттуда доставалось :) ?

У вас получается большая собственная система ERP. которую нужно писать. Таких "из коробки" нет. У других ее нет. И многим оно не нужно.

Просто нет другого сервера (или локального компьютера с локальной 1С и отдельным софтом), отдельных тикет-систем, систем анализа статистики, обработки этих логов статистики, затягивание этого в вашу систему, генерации из этой статистики рекомендаций и т.п.

Тут два момента - либо у вас весь функционал магазина (то что обычно) сделан в отдельной ERP, либо половину от него вы вообще не используете. Зависит от задачи.

Но держать большой зоопарк разного софта удобно не всем. вернее никому не удобно.

В вашем случае уменьшение зоопарка получилось написанием своей системы ERP/CRM.

Другим проще иметь многофункциональный магазин.

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

У меня поиск только по названиям нужен, и товаров до 1000 шт.

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

и искать в нём вообще не напрягая сервер. Да и в 10 раз больше можно былоб

сжать, загрузить и распаковать.

Сравнение атрибутов не вижу почему нельзя сделать тоже средствами js.

(но в этот раз задача почти не стоит)

Хуже с валидацией почтового адреса, но тут можно какой-нибудь сторонний сервис

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

---------- Добавлено 26.12.2016 в 18:45 ----------

А как они вообще существуют ? Этож даже для маленького магазина из <1000 позиций

без нормальной (своей или чужой дописанной) системы смерть.

Небольшой, но заточенной под конкретный бизнес.

Так магазин нифига нормально не делает. "Из коробки".

В результате вместо использования хороших отдельных систем и инвестиции в

их интеграцию друг с другом, люди пишут "модули", которые "кое-как делают хоть что-то".

Но этож самоубийство в условиях конкуренции.

Не очень понятно чем зоопарк качественного специализированного софта хуже, чем

зоопарк некачественных модулей.

Т.е. есть четкое ощущение, что тикет-система "из коробки", склад "из коробки" итп,

будут всё-таки лучше, чем самый навороченный интернет-магазин с 100500

установленных модулей.

Но общую мысль я понял: они думают, что экономят потому, что покупают одно решение,

а не несколько.

структура, возможность нахождения товаров в разных категориях с единым url, взаимосвязь параметров товаров (очень сильно облегчает поиск)

страницы акций/распродаж... и вывод товаров на них, реферальная система для партнёров

наверните на всё это требования сеошников и получите взрыв мозга :)

да всего этого нет ни в одной из существующих коробок

Ну вот простой магазин у клиента.

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

Сеошник в Киеве, контент.манагер - Харьков.

Программисты - Одесса.

Админ - Винница.

Всем им с той или иной периодичностью приходится иметь доступ в бекофис.

Директолог еще из Киева (на момент старта проекта был из Донецка).

Может кого-то и не знаю.

Маркетологи конечно лохотронщики. Зачем этому магазину доступ онлайн? Ума не приложу. Пусть всё через тимвьювер делают :)

Здесь две проблемы в кучу.

1 - стоковая порнография. Это реальная проблема. Сток ужасен, особенно бесплатный, но и платный тоже.

2 - отделение витрины от ERP действительно неплохая идея с точки зрения безопасности и т.п. Минусом здесь только поддержка двух различных архитектур. Если у вас уже есть полноценный фреймворк, готовый набор моделек и т.п., то проще дополнить одну платформу кодом для витрины, и отдельно кодом для бекофиса, а не делать ВЕЗДЕ разные вещи. Ну есть у меня уже ORM. Зачем мне еще свой велосипед городить для фронт-витрины. Ну понадобится. Все равно понадобится. Попадется вам большой магазин в заказе и понадобится....

Не очень понял о чем речь ?

Обычно структура задается так или иначе либо в складе, либо где-то еще,

где товар УЖЕ учитывается. Надо дублировать.

Не вижу проблем. Хотя допил какой-то будет нужен конечно.

Тоже не очень понял, можно пример ?

Речь о фильтрации товара на основе выбора каких-либо параметров ?

(т.е. фактически поиске). Тут согласен - придется что-то на серверной стороне

писать, что-то лёгкое и быстрое желательно. Возможно да - придется

что-то держать в БД.

Статикаж. Из ERP прям может и браться. По кронтабу крутиться.

Вряд ли чаще раза-другого в сутки всё это меняется.

Допилю сделаю тесты, как быстро рефрешится скажем 100.000

страниц статики, но не думаю, что долго.

Тут не компетентен, врать не буду. Однако полагаю она в ERP должна работать

исходя либо из точки входа, либо из реферрера. И только для оплаченных

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

с меткой.

Да ктоб спорил, особенно если в вашей коробке еще 100500 фич, которые

затрудняют реализацию нужных.