Ищу Candidat CMS

Так разбивайте, в чем проблема ? Всеж равно придется.

В CRM... ИМ-то тут причем. Причем в CRM данные только приходят, оттуда они не уходят уже.

Я что, придя к вам в оффлайн-точку буду как-то авторизован через ИМ как покупатель ?

А когда ваш ИМ под "ддос" мне будут говорить "не можем пробить скидку потому, что что-то не работает" ?

Взачем вам это ?

Хотите ЛК... нет проблем, только зачем его в базе хранить ?

В чём резон ?

Части ЛК всё равно не меняются.

Статус заказов ? Выгружается из системы управления при изменении.

Разумеется. Однако не очень понимаю, зачем вы вообще внешние обмены какие-то хотите осуществлять.

Не надо этого делать. Вообще не надо.

Исключение - подтвержденный заказ. Его надо "пропихнуть" туда, куда надо.

И, разумеется, копию сохранить локально.

Кстати, можно просто локально сохранять и потом уже забирать по sftp и разворачивать в свою систему.

Я не очень понял о какой нагрузке речь, проясните пожалуйста ?

Что, на 99% статический сайт с одним скриптом приема заказа будет выдерживать меньше нагрузки, чем ИМ в котором для показа любой страницы по 100 запросов в базу и по 300мб php кода "собирается" ? почему ?

ИМ как вы понимаете работает и принимает заказы абсолютно автономно.

Система учета-то тут причем.

Даже если она "ляжет" ИМ будет продолжать работать.

Учет ведет система учета, при факте заказа она меняет соответствующую страницу(ы) ИМ уменьшая количество товара.

Статистику собирает гугл, яндекс и нгикс.

Аналитика... не знаю о какой речь, но, полагаю она тоже легко реализуется отдельно.

Если статически - вообще 0 проблем.

Смотря какие связи. Если статически - нет проблем, стройте. В ИМ-то зачем тащить.

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

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

Пожалуй, наверное, 100-1000.

В мире.

Если резервация и заказ осуществляется внутри вашей системы управления, то там будут и ваши транзакции.

Как таковые "транзакции" обеспечить можно и без БД. В том одном месте, где это нужно.

От хотелок зависит ей богу.

Если ИМ - это интерфейс "продажи", то проблем не будет.

Если кто-то хочет использовать ИМ, как средство автоматизации бизнеса, то ничего не получится.

(а таких дебилов все больше).

Я уже 20+ лет назад так и делал.... и продолжаю.

Даже свой аналог смарти написал ничего про него не зная. (когда нашелся смарти - выкинул)

Оказалось, что всё это и на простые ИМ с легкостью "натягивается", а при некоторых условиях очевидно можно и на непростые

---------- Добавлено 13.01.2020 в 12:31 ----------

У меня в ювелирке как-раз :)) заведена. Но не в 1С правда, а в собственную систему управления.

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

В целом 1С тут неправильно припоминать. Проблемы вашего клиента в том, что вместо того, чтобы иметь связку типа

1С <-> Моя система управления <-> ИМ

Он имеет

1С <-> ИМ

И вынужден реализовывать многие вещи не там, где удобно, а выбирать один из двух сортов "говна", или в ИМ их пихать, или в 1С, а им не место ни там, ни сям.

Но "ваша правда" - это то тонкое место, которое надо очень тщательно продумать.

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

---------- Добавлено 13.01.2020 в 12:35 ----------

В чем проблема ? Есть логин пользователя, есть файл в котором хранится его ЛК. БД тут зачем ?

Авторизация по СМС либо через соцсети. Пароль вообще не нужен, кто его помнит-то ?

---------- Добавлено 13.01.2020 в 12:51 ----------

Мусор ? Мусор лучше не хранить.

Нужные данные надо где-то хранить. И как правило "это" - это система управления.

Какая-то штука, в которой делать это удобно, и которая "кормит данными" 1С, ИМ, CRM и всё остальное

Давайте с примерами, а :) ?

Иногда лучше читать, чем бредить. Без обид...

Ничего, что речь шла об ИМ на +- 1000 товаров, а вы пытаетесь натянуть эту сову на 100к :) ?

И да, раз в 10 сожмете, а может и в 20.

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

ВЕРНЫЙ ВОПРОС !

Зачем использовать sql БД если можно делать и без неё :) ?

Зависит от реалий. Они у каждого свои.

И скажите, что там с поиском получается при таком увеличении ассортимента :) ? Текстовый по описаниям ?

Дайте что-ли пациента, я вам его с сотни-другой прокси на поиск "проверю".

И посмотрим через сколько времени вас отключит хостер.

Думаю мгновенно.

Вы читали тезисы ?

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

Тысячи позиций "в пределе".

Таких ИМ полагаю 99.9% от общего количества.

Если надо больше - лучше сувать в специализированную БД и доставать оттуда.

Но только поиск.

Остальное в sql БД сувать бессмысленно.

На том и порешили.. =)

Нет. Если "автономно", то это не "магазин", а витрина. Хотя бы немножко если подумать, то получится, что с внешними системами взаимодействовать все же надо, в реальном времени (или "почти в реальном"), если вы продаете фиический товар с физического склада, который (пичалька) может получиться "out of stock", если у вас есть всякие фишки для юзеров, применяемые динамически, в зависимости от условий "прям щяз". Да, все это возможно и не нужно прямо в самом ИМ, но из внешней системы тянуть надо. И связи эти - классические реляционные, так что не надо натягивать сову на глобус и заводить еще один layer преобразования SQL-noSQL

---------- Добавлено 13.01.2020 в 17:25 ----------

Нет. Это мелочь, которую вытесняют успешно середняки с десятками тысяч позиций (беру массмаркет, не "авто"/"ювелирка", у меня статистика на несколько десятков шопов таких свежая, овер 100 - если интервально)

_SP_, Я с вами полностью согласен, только что вы вкладываете в понятие ИМ тогда? каталог товаров только? Так это называется интернет витрина так то.

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

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

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

И у тех 99% магазинов про которые вы говорите, есть своя бизнес логика, только вы её вынесли в понятие "Моя система <-> ИМ", а так то обычно все что вы выносите из ИМ, можно так то оставить и внутри ИМ, что большинство и делает.

Вопрос исключительно терминологии в вашей голове.

Но в целом да. Магазин не может быть "интернет". Магазин должен быть только оффлайн.

И в чем тут проблема ? Объем этого взаимодействия микроскопический и происходит только во время чекаута фактически.

При заказе что-то извне ИМ уменьшает кол-во "на складе" и обновляет одну страничку в ИМ количеством

При неудаче выдает ошибки итд итп.

С какой целью вы хотите каждый раз при показе товара что-то там "дергать в реальном времени" ?

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

О чём речь :) ?

Да какие-ж они реляционные ?

Связей и нет в общем-то. Когда данные пользователя выбираются только по ключу "userId" - это не работа для БД ей богу.

Контактные телефоны зачем в БД писать ? А что еще можно НЕ писать :) ? А еще...

Да ктож спорит. Скоро будет один амазон и всё.

Только вот... в этой парадигме никакие БД вам вообще не понадобятся.

---------- Добавлено 14.01.2020 в 12:16 ----------

Каталог товара с возможностью заказать его, оплатить.

Но уж никак не систему управления бизнесом, завязывать её на базу в которую может стучаться "кто угодно" неумно.

Поднимаю отдельный сервис расчета скидок имеющий доступ к моей CRM (к которой доступ ограничен по ip итп)

Написанный на том, на чём удобно.

В нём делаю все правила и математику

Когда необходимо посчитать - шлю ему запрос.

Получаю результат и показываю его.

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

Учитывая, что те-же скидки мне надо как-то в оффлайн-точках считать, то какой смысл делать это в ИМ ?

Как потом с этим работать ?

А у вас и так никакой уверенности не будет, транзакция всё-равно нужна.

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

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

Несчастные идиоты, что я еще о них могу сказать.

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

Да что там скидку, чек иногда не могут "посчитать".

А в это время 10000 прокси насилуют их ИМ хитами в страницу поиска... просто потому, что их конкурентам тоже жрать хочется, а они поумнее.

Вначале люди запихивают в БД всё как в "помойное ведро".

Потом "страдают" от того, что любой чих и всё начинает не работать.

Что работа склада мифическим образом перестает быть возможным при наплыве ботов в ИМ.

Что невозможно обслужить клиента стоящего перед тобой, т.к. принтер не печатает из-за того, что подключен по интернету, хотя находится у вас на столе :).

Но я с вами согласен на 100%. Ныне о таких вещах думают немногие.

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

Удивительно, как инструмент, созданный для упрощения работы с данными, тут превратился в главного врага и помеху. Скажите это Ораклу)))

То есть у вас есть 4 группы пользователей у каждого своя цена и они могут свою цену посмотреть только в корзине?

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

PS. Можно пример самого большого ИМ на файлах у вас, чисто ради интереса посмотреть, можно в ЛС в принципе. Хочу оценить масштаб ваших мыслей.

git branch --contains abcdefh

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

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

Удивительно, как некоторые люди стремятся сделать любую работу одним инструментом.

И гвозди забить, и инфузорию рассмотреть....

---------- Добавлено 15.01.2020 в 12:31 ----------

В чем трабл-то ?

Выгружаете 4 цены в каждый товар. Показываете ту, к группе которой принадлежит пользователь.

Или 3 оставшиеся "очень секретные и должны быть доступны только после авторизации" ?

Тогда вы "в беде" и придется что-то придумывать.

В каком промежутке ?

Не очень понимаю что вы собрались пробегать.

Продан последний "велосипед А", мастер-система извещена об этом.

Она выкладывает новый html для велосипеда А с нулем и новую категорию без велосипеда А (если надо).

Ничего никто не пробегает вообще, меняется либо 1, либо 2 файла.

Зачем вы собрались что-то перебирать ? В чём смысл ?

ЭЭЭ... увы нет.

Что вы собрались там увидеть-то ?

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

Тысячи позиций работают. (правда без полнотекстового поиска по описаниям, был не нужен)

В условиях высокой культуры внутри компании и небольшом количестве хотелок - это работает.

В других условиях работать может и не будет. Как и многое другое.

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

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

К каждому гвоздю надо подбирать свой микроскоп.

А ещё все варианты фильтров (коих может быть сотни и тысячи) в которых этот товар находится, добавив сюда пагинацию и сортировку, можете посчитать сколько будет вариантов. Более того, проще найти товар под условие, чем условия, под который попадает товар. Обновление курса валют приведет к полной перегенерации десятков тысяч страниц, и это для небольшого магазина. Потом приходит мамкин маркетолог, и говорит нам нужен A/B тест.

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