Т.е. я трачу время и бабки, привожу клиентов, ваши менеджеры по телефону отвечают только одну фразу "пошел ты в жопу" и я не имею "честно заработанных" бабок :) ?
Понимаете ? Купит человек или нет зависит не только от того, кто его "привел", но и (и сильно) от того, как вы с ним работать будете. И на это никак влиять со стороны того, кто "приводит" невозможно.
Тут пирог нормально не делится... вообще.
В жопу не будут посылать ? А как по-поводу того, что в середине продаж товар закончится.
И что ? Вы вовремя не заказали, я подсчитываю убытки ? Зашибись перспективка.
Как насчет пьяных курьеров :) ? Сломанных страниц вашего магазина ? Неработающих телефонов. Итд итп.
Чтобы привязать чью-то работу к вашему "выхлопу" надо брать его в долю.
Т.е. делать совладельцем. Кто на это пойдет :) ?
Ваше желание понятно.
Но так не получится. Максимум - создадут видимость связи.
Я не могу привести никакого примера одинакового и сделанного нормально, чё уж тут говорить об уникальном...
Давайте откроем какую-нибудь "коробку" и посмотрим "чё там сделано-то" :) ?
Какую будем обсирать ? Ссылку на демку пришлите.
Способы группировки товара, фильтры, фотки итп, все это довольно сильно отличается в зависимости от предметной области.
Отличаются и артикулы, их формирование, да и просто товары очень разные бывают.
ИМ - это некое отражение реального бизнеса.
Бизнес может быть более или менее одинаков только если это франчайзинг одной компании.
Во всех других областях он всегда и очень разный.
Продажи подразумевают наличие конкурентного преимущества.
Если вы хотите отказаться от технического конкурентного преимущества и делать "как у всех", то это ваше право.
Таких в последние годы немало. Мало тех, кто не закрылся в первый год.
ЗЫ. Даже вопрос "какие товары разные, а что является вариацией товара" для разных владельцев ИМ с одинаковым товаром приводит к разным ответам.
ЧТД
К слову сказать... не исключено что у вас с железом проблемы.
Проверьте актуальность бэкапов. Просто от греха.
За какое время теперь исполняется ?
В среднем(0.5?)/мин/макс ?
Не читал.
В целом: ни для каких.
Маркетинг заключается в том, что надо создать продукт, который можно впарить и затем поддерживать.
Если ваш продукт не требует постоянной поддержки, то это плохой продукт. На нём не заработать.
Проблемы тех кто платит, безусловно никого не волнуют.
Привыкайте. Капитализм.
С фильтрами, если не хотите показывать товар out of stock придется да, сгружать в пользователя новую инфу.
При большом ассортименте, вероятно придется не базу целиком, а "патчи" ему присылать. Но это вполне посильно.
Не очень понимаю в чем проблема в генерации десятков тысяч страниц при изменении курса.
(кстати, откуда они взялись в магазине на тысячу товаров :) ?)
Вы их и так сгенерируете, как только любой поисковый бот или юзер придет.... только будете делать это неоднократно.
А перегенерить можно и аккуратно, в удобный момент.
Но да, согласен, если в среднем у вас что-то там обновляется гораздо чаще, чем пользователи видят страницу, то да, скорее всего её имеет смысл формировать что-то "к показу" только по запросу.
Но мне казалось это для дорвеев, а не ИМ актуально.
Тут не только в точке отказа проблемы.
С одной стороны система при которой страницы каждый раз генерятся для показа однозначно порочна.
Да, можно решать эту проблему через кеши, но как правило получается не очень прямо.
Собственно в описанной схеме ваш ИМ - это и есть кеш вашей системы управления :) приготовленный для показа пользователю.
Его и инвалидируем.
С другой стороны система, в которой в slq базу зачем-то записано "всё" для меня тоже как-то "верхом совершенства" не является.
Я вижу к чему это приводит в даже довольно популярных продуктах.
Безусловно есть немало кейсов, в которых надо использовать БД.
Но я не могу себе представить кейс в котором надо использовать БД для хранения названия ИМ :).
А ведь хранят. Многие.
А дальше логичное развитие мысли: что еще не нужно в БД...
С третьей стороны всё становится совсем грустно когда начинаешь думать как-бы ты сам подобную систему "ронял".
Ну т.е. где и какие те самые "точки отказа". Как нагрузить сервера. Итд итп.
И как-то идея писать что-то нужное не только ИМ в его базу сразу перестает быть... актуальной.
А значит... придется где-то всё это хранить, синхронизировать, еще и в две стороны иногда... итд итп.
Очень бы хотелось посмотреть, как вы решали бы с БД задачу по управлению кардиостимулятором.
Удивительно, как некоторые люди стремятся сделать любую работу одним инструментом.
И гвозди забить, и инфузорию рассмотреть....---------- Добавлено 15.01.2020 в 12:31 ----------
В чем трабл-то ?
Выгружаете 4 цены в каждый товар. Показываете ту, к группе которой принадлежит пользователь.
Или 3 оставшиеся "очень секретные и должны быть доступны только после авторизации" ?
Тогда вы "в беде" и придется что-то придумывать.
В каком промежутке ?
Не очень понимаю что вы собрались пробегать.
Продан последний "велосипед А", мастер-система извещена об этом.
Она выкладывает новый html для велосипеда А с нулем и новую категорию без велосипеда А (если надо).
Ничего никто не пробегает вообще, меняется либо 1, либо 2 файла.
Зачем вы собрались что-то перебирать ? В чём смысл ?
ЭЭЭ... увы нет.
Что вы собрались там увидеть-то ?
Фронтэнд внешне не отличается ничем, кроме как мгновенной работой в некоторых местах, скажем в снипетах поиска по названию.
Тысячи позиций работают. (правда без полнотекстового поиска по описаниям, был не нужен)
В условиях высокой культуры внутри компании и небольшом количестве хотелок - это работает.
В других условиях работать может и не будет. Как и многое другое.
С дебилами не работал, но представляю какие могут быть проблемы.
Сотни тысяч товаров, по всей видимости не будет работать локальный поиск итп.
К каждому гвоздю надо подбирать свой микроскоп.
Вариации 0.5-40 в принципе "не норма"...
Он ответил, что читает по 4000 файлов.
Отсутствие перебора насколько я понимаю он тоже подтвердил экспериментально, читается именно те 4 байта что надо.
После вторичного запуска при прогретом файловом кеше как я понимаю всё происходит быстро.
Налицо какие-то проблемы на уровне файловой системы и задержек.
Возможно это всё снаружи VPS обрезано как-то.
Яб попробовал с "рамдрайвом". Это быстро, просто и может дать результат.
Чтобы не быть в рабстве, надо поддерживать нормальный механизм создания ПО.
Когда есть документация, тесты итп. А не просто что-то "побырому наделать".
Но это дороже. В 3-10 раз. Увы, такова жизнь.
У многих есть иллюзии, что мы тут "возьмем битрикс и будем независимы" :).
Как-бы это сказать... чтобы ваш битрикс "взлетел" его надо будет "пилить и пилить" и попадете
точно в такое-же рабство. Точнее в другое: за битрикс берут обычно х2 х5 от цен за что-то еще...---------- Добавлено 14.01.2020 в 15:40 ----------
А зачем вы собрались менять версию php для работающего продукта :) ?
Неужели из-за уязвимостей :)))) ?
Я сколько эксплойтов на 5.3 что-то там не пробовал на своей, не работают хоть убей.
При переходе на 7+ куча "коробочных продуктов" окирпичилась, а самописный код как работал, так и работает.
В результате своё на 7+ гоняю, а "чужое" на 5й ветке.
Это многообещающая инфа, значит читаете сразу из нужного места. Иначе 0.5 не выходило бы.
Я tmpfs не пользовался, но подозреваю просто скопировать туда данные и пользоваться как обычным диском.
Рамдрайвом я пользовался на клиентских машинах, под дос и виндовз, там всё обстояло именно так.
Нельзя-ли вместо 4000 файлов с узлами сделать 1000500 файлов в каждом которых будет все для одного узла и читать один файл, а не 4000 ? (как вариант по 10-100 штук объединить, да фиг с ним, даже в один файл всё собрать если можно по оффсету читать корректно)
Кстати попробуйте свою функцию на чтение из любого файла длиной скажем 1гб, попробуйте последние байты прочитать и замерьте время. Просто, чтобы убедиться.
Вопрос исключительно терминологии в вашей голове.
Но в целом да. Магазин не может быть "интернет". Магазин должен быть только оффлайн.
И в чем тут проблема ? Объем этого взаимодействия микроскопический и происходит только во время чекаута фактически.
При заказе что-то извне ИМ уменьшает кол-во "на складе" и обновляет одну страничку в ИМ количеством
При неудаче выдает ошибки итд итп.
С какой целью вы хотите каждый раз при показе товара что-то там "дергать в реальном времени" ?
Очень трудно комментировать мнимые проблемы в мифических частях.
О чём речь :) ?
Да какие-ж они реляционные ?
Связей и нет в общем-то. Когда данные пользователя выбираются только по ключу "userId" - это не работа для БД ей богу.
Контактные телефоны зачем в БД писать ? А что еще можно НЕ писать :) ? А еще...
Да ктож спорит. Скоро будет один амазон и всё.
Только вот... в этой парадигме никакие БД вам вообще не понадобятся.---------- Добавлено 14.01.2020 в 12:16 ----------
Каталог товара с возможностью заказать его, оплатить.
Но уж никак не систему управления бизнесом, завязывать её на базу в которую может стучаться "кто угодно" неумно.
Поднимаю отдельный сервис расчета скидок имеющий доступ к моей CRM (к которой доступ ограничен по ip итп)
Написанный на том, на чём удобно.
В нём делаю все правила и математику
Когда необходимо посчитать - шлю ему запрос.
Получаю результат и показываю его.
Тут да - нужно почти в реальном времени, но не на уровне показа товара, а на уровне добавления в корзину, что согласитесь происходит гораздо реже.
Учитывая, что те-же скидки мне надо как-то в оффлайн-точках считать, то какой смысл делать это в ИМ ?
Как потом с этим работать ?
А у вас и так никакой уверенности не будет, транзакция всё-равно нужна.
Поэтому в момент продажи, вам нужна транзакция со стороны мастер-системы и ответ, удалось ли действительно купить.
Я не призываю вас не учитывать остатки со стороны вашего ИМ, я призываю вас хранить эти остатки прям в странице, а не в какой-то БД, ведь больше они в ИМ нигде не нужны... проверять всё равно в мастер-системе.
Несчастные идиоты, что я еще о них могу сказать.
К сожалению, иногда мне приходится иметь с ними дело... ну знаете ведь, обычная ситуация, когда "на кассе" вам говорят "а вот скидку пробить не можем, что-то интернет-магазин у нас не очень пашет, а без него ничего не работает".
Да что там скидку, чек иногда не могут "посчитать".
А в это время 10000 прокси насилуют их ИМ хитами в страницу поиска... просто потому, что их конкурентам тоже жрать хочется, а они поумнее.
Вначале люди запихивают в БД всё как в "помойное ведро".
Потом "страдают" от того, что любой чих и всё начинает не работать.
Что работа склада мифическим образом перестает быть возможным при наплыве ботов в ИМ.
Что невозможно обслужить клиента стоящего перед тобой, т.к. принтер не печатает из-за того, что подключен по интернету, хотя находится у вас на столе :).
Но я с вами согласен на 100%. Ныне о таких вещах думают немногие.
