Ищу Candidat CMS

_
На сайте с 24.03.2008
Offline
357
#101
Aisamiery:
_SP_, Для ИМ задач на самом деле там много:
1. В системе хранения скорее всего учет не тот, что есть на сайте (Например на сайте продаются компьютеры, а в системе учета все по комплектующим, то есть в момент синхронизации заказов, компьютеры надо разбить на комплектующие)

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

Aisamiery:

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

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

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

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

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

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

В чём резон ?

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

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

Aisamiery:

3. Любой внешний обмен на запросе пользователя это смерть ИМ, по этому все обмены вынесены с запросов юзеров, например надо быть дебилом чтобы отправлять смс юзеру, ведь гетвей может подвиснуть на 30 секунд и юзер будет ждать загрузки страницы 30 секунд.

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

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

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

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

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

Aisamiery:

4. Никакая система учета не выдержит той нагрузки что выдерживают ИМ.

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

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

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

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

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

Aisamiery:

5. Надо вести учет, статистику и аналитику.

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

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

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

Aisamiery:

6. Надо обогащать данные карточек товаров.

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

Aisamiery:

7.Нужно строить связи для доп и крос продаж.

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

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

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

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

В мире.

Aisamiery:

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

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

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

Aisamiery:

Я не говорю что какой то классический простой ИМ нельзя построить чисто на статике - можно. Но это сильно сложнее с хотелками в екоммерсе.

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

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

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

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

Aisamiery:

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

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

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

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

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

LazyBadger:
Поднимите мне веки! И покажите того, у кого в 1С заведена таксономия вся кучерявая, даже не на очень комплексный товар... недавно вот делал фильтры ювелирщикам на "вроде бы простой" товар - кольца. И там было - много. А еще не просто таксономии, а пересечения и объединения... не, только по месту (то бишь - на морде сайта), в остальных местах народ оперирует артикулом и ему хватает

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

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

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

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

Он имеет

1С <-> ИМ

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

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

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

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

specialist-seo:

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

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

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

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

ivan-lev:
Затем, что далеко не весь "мусор" (который для ИМ - вполне рабочие и нужные, а порой - необходимые данные) нужен в 1С..
Более того, отдельная информация в 1С категорически не нужна..
* это в дополнение к личному кабинету пользователя с данными, историей и "плюшками", который, строго говоря, не совсем админка..

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

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

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

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

ivan-lev:

Представляю, как некий условный озон-амазон...

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

ivan-lev:

(чтоб считать "круглее" было - берём грубо условных 4000 байт на товар)... Т..е 1к товаров будет занимать примерно 3,8 Мб (без сжатия). 10к товаров, соответственно - 38Мб, 100к - 380Мб...

Пусть мы на лету эффективно сожмём это раз в 10 до 38 Мб..

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

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

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

ivan-lev:

А зачем изобретать "что-то ещё", если можно вполне нормально делать?..

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

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

ivan-lev:

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

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

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

ivan-lev:

На таких объёмах товаров (условные 100к) на "нормальном" хостинге с поиском справится и MySQL без эластиков-сфинксов..

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

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

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

ivan-lev:

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

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

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

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

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

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

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

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

IL
На сайте с 20.04.2007
Offline
418
#102
_SP_:
Зависит от реалий. Они у каждого свои.

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

... :) Облачные серверы от RegRu - промокод 3F85-3D10-806D-7224 ( http://levik.info/regru )
Lazy Badger
На сайте с 14.06.2017
Offline
192
#103
_SP_:
ИМ как вы понимаете работает и принимает заказы абсолютно автономно

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

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

_SP_:
Тысячи позиций "в пределе".
Таких ИМ полагаю 99.9% от общего количества.

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

Производство жести методом непрерывного отжига
Aisamiery
На сайте с 12.04.2015
Offline
217
#104

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

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

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

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

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

Разработка проектов на Symfony, Laravel, 1C-Bitrix, UMI.CMS, OctoberCMS
_
На сайте с 24.03.2008
Offline
357
#105
LazyBadger:
Нет. Если "автономно", то это не "магазин", а витрина.

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

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

LazyBadger:

Хотя бы немножко если подумать, то получится, что с внешними системами взаимодействовать все же надо, в реальном времени (или "почти в реальном"), если вы продаете фиический товар с физического склада, который (пичалька) может получиться "out of stock",

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

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

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

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

LazyBadger:
если у вас есть всякие фишки для юзеров, применяемые динамически, в зависимости от условий "прям щяз".

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

О чём речь :) ?

LazyBadger:

Да, все это возможно и не нужно прямо в самом ИМ, но из внешней системы тянуть надо. И связи эти - классические реляционные, так что не надо натягивать сову на глобус и заводить еще один layer преобразования SQL-noSQL

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

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

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

LazyBadger:

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

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

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

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

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

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

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

Aisamiery:

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

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

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

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

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

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

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

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

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

Aisamiery:

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

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

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

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

Aisamiery:

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

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

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

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

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

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

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

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

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

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

S3
На сайте с 29.03.2012
Offline
236
#106
_SP_:
Зачем использовать sql БД если можно делать и без неё ?

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

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

Aisamiery
На сайте с 12.04.2015
Offline
217
#107
_SP_:

Поднимаю отдельный сервис расчета скидок имеющий доступ к моей CRM (к которой доступ ограничен по ip итп)
Написанный на том, на чём удобно.
В нём делаю все правила и математику
Когда необходимо посчитать - шлю ему запрос.
Получаю результат и показываю его.
Тут да - нужно почти в реальном времени, но не на уровне показа товара, а на уровне добавления в корзину, что согласитесь происходит гораздо реже.

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

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

_SP_:

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

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

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

D
На сайте с 18.12.2015
Offline
147
#108
LazyBadger:
Интуитивно понятный интерфейс, да??? А в Меркуриале то же самое - один короткий revset на пару функций

git branch --contains abcdefh

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

Разработка и поддержка высоконагруженных проектов.
_
На сайте с 24.03.2008
Offline
357
#109
Sly32:
Очень бы хотелось посмотреть, как бы вы решали без БД задачу по написанию сайта с моей прошлой работы, когда мало того, что вариативынй товар, так и еще три прайса существует и кабинет клиента отдельно для которого есть свой уровень цен.
Удивительно, как инструмент, созданный для упрощения работы с данными, тут превратился в главного врага и помеху. Скажите это Ораклу)))

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

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

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

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

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

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

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

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

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

Aisamiery:

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

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

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

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

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

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

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

Aisamiery:

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

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

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

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

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

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

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

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

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

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

D
На сайте с 18.12.2015
Offline
147
#110
_SP_:
Продан последний "велосипед А", мастер-система извещена об этом.
Она выкладывает новый html для велосипеда А с нулем и новую категорию без велосипеда А (если надо).
Ничего никто не пробегает вообще, меняется либо 1, либо 2 файла.
Зачем вы собрались что-то перебирать ? В чём смысл ?

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

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

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