Синхронизация прайсов поставщиков с товарами и ценами на сайте.

Главным образом на моем более чем 30-летнем опыте работы в ИТ.
В целом поддержка гетерогенных систем сложнее гомогенных. Если у вас есть одна система, у вас есть одна проблема по ее сопровождению. Если же есть две связанные системы, то проблем уже три.

Во-первых, нужно сопровождать каждую из этих систем, это две проблемы. Если системы разработаны разными компаниями, то они изменяются и сопровождаются независимо друг от друга. Т.е. если изменения в одной системе требуют изменений в другой системе, то когда такие изменения будут внесены и будут ли, заранее сказать нельзя.

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

Говоря проще, если владельцу магазина нужно импортировать прайс-лист, формат которого не поддерживается программой или сервисом импорта прайс-листов, нужно уговорить разработчиков этой программы или сервиса внести необходимые изменения. Да еще таким образом, чтобы не перестала работать интеграция. В худшем случае придется вносить изменения еще и в ПО магазина.

С другой стороны, обучение менеджеров проще, если используется одна, а не две связанные между собой системы. Дополнительно к изучению бэк-офиса магазина менеджеру не нужно еще изучать программы или сервисы импорта, а также приемы интеграции.

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

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


Не ьудем далеко ходить, возьмем к примеру 1С и Битрикс. Если бы флагману учетных систем 1С понадобилась гомогенная система - они бы включили в ядро 1С свой собственный вебсервер в том числе с поддержкой скриптовых языков php, ror и т.п., но этого по ряду причин не произошло - в итоге имеем две по сути независимые системы. Более того, вряд-ли ваш "учет" хоть немного приближается к возможностям 1С!


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


Извините, утверждение в какой-то степени верно но и в то же время абсурдно, т.к. есть еще один важный фактор - степень пряморукости разработчиков. Не факт, что этот "один" - будет с рукими из правильного места. Так же КАТЕГОРИЧЕСКИ НЕЛЬЗЯ создавать незаменимое звено - это один из канонов непрерывности бизнеса!!! Любое звено должно быть заменяемым!

В любой ситуации лучше учиться на чужих ошибках, чем на своих. У меня был достаточный опыт интеграции различных систем, и также создания наших собственных, не уступающих коробочным решениям по сложности. И это свежий, очень свежий опыт)
Кстати, не только мой, в своей компании я работаю не один.



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

Насчет проблем интеграции Битрикса с 1С и других проблем с Битриксом можно почитать на Хабре, например: https://habrahabr.ru/post/282333/. Это писал разработчик решений на Битриксе. И вообще подобных статей немало, вот еще, например: https://habrahabr.ru/post/280226/. Если кратко - все хорошо, пока все стандартное и создается с нуля. Однако на практике бывает не так.




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

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



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

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

В магазин автоматически импортируются прайс-листы от нескольких десятков поставщиков (с разными форматами, разными способами - загружаются через сайт, по электронной почте, через FTP). Под заказы оптовых покупателей этим поставщикам автоматически отправляются заявки на товары.

Когда покупатели оформляют заказы, они видят реальное наличие на складе с учетом резерва под заказ, транзитов, наличия на складах поставщиков, а также сроки доставки в свой город с учетом графиков и сроков поставок от поставщиков магазина.

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

Формируются все необходимые первичные документы: счета, счета-фактуры, ТОРГ-12, приходно-кассовый ордер, договоры с покупателями, акты сверки и др. Предусмотрены разные категории покупателей с гибкой системой скидок. Ведутся журналы действий менеджеров, отчеты по работе менеджеров, рассчитывается зарплата курьерам и т.п.

Единственное для чего используется 1С, это для формирования бухгалтерских документов, для чего в нее из магазина загружаются необходимые данные.

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

А вы найдете где-нибудь для реализации подобного проекта готовое решение?


Теперь о заменяемости.

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

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

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

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


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


Автоматизировать можно даже в Экселе!!! Ничто не мешает настроить запуск того же Excel в планировщике Windows и выполнять обновление макросом разными способами - от HTTP GET/POST, REST API до коннекта к базе магазина через ADO.


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


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


Понятие "в реальном времени" играет в вашу пользу только в том случае, если у вас резервирование и списание работает под общей транзакцией, локальной или распределенной. Но все так или иначе реализуемо. Может меня поправят знатоки 1С, но подозреваю она полностью с этим справляется.


Чем привязка к этой команде отличается от привязки к вам?!?

То есть другими словами, вы просто впарили клиенту свое решение, вместо того же МойСклад.

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



Да можно, конечно, кто же спорит. Но нужно ведь чтобы это работало надежно и было удобно для менеджера. А что может быть удобнее, чем средство, уже встроенное в бэк-офис, с которым менеджер работает каждый день, чему не нужно учиться и что не вызывает лишних вопросов.

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



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

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

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




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

Но это и не WMS, так как в то время требовался учет только на виртуальных складах.

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




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

Наверное, реализовать подобие "реального времени" можно и передавая данные через API в 1C и обратно, но накладные расходы по времени будут несравнимы с реализацией на единой СУБД. Просто это все будет работать очень медленно по сравнению с простым выполнением запроса SQL. И при больших нагрузках это просто встанет (или ляжет, как больше нравится). Вот представьте себе несколько десятков менеджеров, интенсивно обрабатывающих заказы. Вы предлагаете все это гонять по сети между сервером магазина и сервером 1С?

А ради чего? И зачем держать еще 1С, и платить за ее сопровождение?




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

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

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

Есть хорошие разработки по импорту прайсов, например для Опенкарт есть модуль "Автоматическая обработка прайслистов", я уже молчу про массу программ и SaaS которые могут всю эту работу с прайсами автоматизировать, от загрузки с сайтов поставщиков и почты до парсинга конкурентов, тут вы ничем не отличаетесь от них. Я не увидел ни одного конкретного аргумента в вашу пользу, только какие-то общие фразы.


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


Я вам про "горячее", вы мне про "мягкое". Что мешает делать это централизованно? Та же 1С например работает с сервером СУБД а клиенты только подключаются к базе непосредственно или через терминальный доступ. О какой персоналке идет речь и вообще к чему этот текст!?? SaaS - тоже по факту централизованное решение...


Я не программист, мне трудно об этом судить. Но простой логический вывод показывает, что количество багов зависит в большей степени от объема кода и это скорее всего касается всех программных решений как "ваших" так и не "ваших". Потому, если вы утверждаете, что у вас большая учетная система - можно сделать вывод, что багов там наверное не мало.


Мне кажется это решается правильным выбором базы данных. Если система построена на основе MSSQL или ORACLE, то там есть возможность создавать отказоустойчивые кластеры или кластеры высокой нагрузки (и репликация только как средство создания резервных копий), а если система работает на такой пародии как MYSQL, то да - тогда репликация, всякие API, REST, SOAP и т.п. От каком тогда "реальном времени" может идти речь???


Вопрос, зачем???!? Все ставится на один сервер. Или на несколько, база 1С на одном, терминалы на других, дополнительные сервисы и автоматизированные (автоматические) системы на третьих и все работает "в реальном времени" без всяких полусистем на вебе. Причем это все можно оформить в отказоустойчивый кластер.


Тут вопрос сложный. Если это большой торговый бизнес, то 1С не подойдет, как и ваша система. Скорее всего понадобится ERP с мощным WMS, это действительно дорогие и кастомные решения, но и компаний которым они нужны наверное намного меньше тех, кому хватит 1С.

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



А вот и не только )
Конечно, если поставщик время от времени меняет формат прайс-листа, приходится настраивать, а то и переделывать соответствующий модуль импорта. Да, мы используем автоматический мониторинг успешности импорта, чтобы отловить наиболее очевидные проблемы с импортом. Да, это все равно не дает 100-процентной гарантии успеха, если формат прайс-листа вдруг поменялся.

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

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



Да, никто не спорит, сама по себе 1С - это монолитное интегрированное решение. Исторически это архитектура толстого клиента, когда клиентом является приложение Windows или Linux. Это приложение и база загружаются с диска сервера и такая архитектура не имеет ничего общего с архитектурой Web-приложений, к которым относится интернет-магазин.

При интеграции приходится обмениваться файлами между сервером интернет-магазина и сервером 1С, через API или FTP. Это медленный процесс, не обеспечивающий работу в реальном времени именно из-за своей низкой скорости.

Что касается персоналки, то здесь имеется в виду, что программа импорта прайс-листа запущена на компьютере менеджера. Менеджер вручную загружает в нее прайс-лист и сохраняет результат на сервере магазина. Либо для сохранения используется API. В любом случае такой процесс вызывает, с одной стороны, необходимость прогонять через компьютер менедежера все прайс-листы, с другой - этот процесс также очень медленный и не пригоден для работы в реальном времени. А если в офисе торговой компании пропал интернет или компьютер менеджера сломался, прайс-листы вообще не будут импортированы.

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



А вот это - как его сделать. У нас, например, есть клонирующая машина, которая штампует готовые решения. Однако у разных клонов судьба может сложиться по-разному. Клон может быть перенесен на выделенный сервер (или кластер выделенных серверов), он может быть существенно доработан и превратиться в самостоятельный проект. Один из наших самых продвинутых магазинов прошел такой путь от простейшего готового решения до чрезвычайно сложного магазина со встроенной CRM, с элементами EPR и, конечно, со встроенным складом.

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

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

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




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

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





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

Для реализации такой возможности, как предложение дополнить корзину товаром, чтобы при этом не увеличилась стоимость доставки (особенность конкретного магазина), мы используем базу MongoDB, в которой содержится примерно 6 Гбайт предварительно подобранных вариантов. Это позволяет предлагать товары в реальном времени на шаге оформления заказа.

Среди других возможностей - это поиск с помощью поискового сервера Sphinx. Он работает примерно в 100 раз быстрее MySQL, учитывает морфологию. С его помощью можно организовать параметрические фильтры (да, такие как на Яндекс.Маркете), а также подбор результатов поиска в реальном времени по мере ввода символов в строке поиска.

Ну и конечно, Nginx, кеш Memcached, куда же без них.

Так что все можно сделать, и без дорогущих решений от Microsoft и Oracle, нужны только квалифицированные системные архитекторы и администраторы.





Как я уже говорил, чем система проще, тем она надежнее и дешевле в сопровождении. Не нужно содержать специалистов в 1С и заниматься интеграциями. Можно сделать сразу такую архитектуру, которая будет оптимальна в данном проекте. Архитектура Web-приложений позволяет создавать полноценные, отказоустойчивые решения, выдерживающие высокие нагрузки. Да вот сходите на форум HighLoad или почитайте материалы, там все рассказано и показано, что и как делают.

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

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



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

А если тяжелого наследия 1С нет, то можно и не связываться с этим монстром. Вы, кстати, ящик с документацией по 1С видели?

На Web-приложении можно сделать намного более простое и легковесное решение, которое будет дешевле в эксплуатации. Да, в том числе за счет отсутствия 1С.


И еще немного про реальное время, зачем оно вообще нужно.

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

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

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

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

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


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


Для менеджера удобное решение обеспечивается удобным интерфейсом который состоит из минимального количества таблиц и кнопок. Из каких источников брать информацию для этих таблиц, вопрос суто технический, т.к. для выдачи одной веб из php можно подключиться к любым источникам данных MYSQL, ORACLE, CACHE и.т.п., надежность этих источников должна обеспечиваться на уровне самих баз данных, а не вашими разработками с затратами на тестирование и т.п. ЛУчше один раз купить лицензию на надежную базу данных чем постоянно кормить команду ИТшников которые должны поддерживать свою же систему, все-равно что повесить себе гирю на шею.


Что и требовалось доказать - менеджер не может сам наладить работу (хотя так наверное и должно быть), но скорее всего так же вряд-ли специалист со стороны сможет быстро разобраться в коде и делать какие-то плагины, это снова о "гире".


Кажется мы тут обсуждаем автоматизацию, или нет? Настроенный и отлаженный процесс всегда можно запустить на автоматическое выполнение (во всяком случае я так думаю), даже макрос в Экселе можно записывать (это как маленький пример). Такие процессы только периодически проверяются и контролируются, а не "вставил не туда колонку или что-то еще" и кажется так делают все, тут ничего нового (все-равно, что я скажу что у меня есть носки или в моей машине есть руль и педали).


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


Напоминаю вам, что 1С позволяет писать практически любые дополнения на собственном языке и использовать множество других готовых библиотек и объектов операционной системы. Ваша "репликация" - это не режим реального времени, потому что они так же имеет дискретность!!! Режим реального рвемени возможен только на RAC высокой доступности, которого судя по вашим рассказам у вас нет. Хватит уже использовать это "маркетинговую фишку". При помощи того же API наверное можно достичь такого же "реального времени" как у вас.




Есть и такие решения, например старый добрый ПДС-Прайс. Но так же есть масса решений которые работают на MYSQL и других базах которые могут работать централизовано на сервере (в том числе и в кластерах или с облачными базами), а клиент по сути так же как и у вас получает данные о товарах из цетрализованного источника. Обеспечение надежности и отказоустойчивости источника - третий суто технический вопрос, и к данной теме он никак не относится, вернее относится косвенно. Более того MYSQL это не полноценная БД, хотя там есть возможность кластеризации и платная версия (поправьте если я ошибаюсь).

Ответ не верный. Надежность информации (вернее целостность) при обмене обеспечивается транзакциями. Если у вас длинные транзакции, то это нагрузка на общую базу магазина или блокировки. Чтобы не было блокировок - нужна версионноть. Может я ошибаюсь, но в MYSQL этого нет, отсюда и репликации с фиктивным режимом "реального времени". Повторюсь, даже простой скрипт который будет скачивать файл с сайта поставщика или парсить сайт или еще что-то, можно поставить в крон и по сути автоматизировать, это делают наверное все: от плагинов и модов для интернет-магазинов до программ обработки прайсов и расширений 1С. Ноу-хау тет нет...


Как я понял - у вас своя CMS, что уже по сути ограничение. Возьмите к примеру Опенкарт, Престашоп, Магенто с их многотысячными сообществами, коллективными знаниями и массой наработок, полезных расширений - это рыночная конкуренция разработчиков (о качестве каждого судить не буду, это отдельная тема), вы же по сравнению с ними - гиря, потому что без вас скорее всего ничего нельзя изменить, дополнить, расширить. А то, что вы не можете конкурировать с такими сообществами - даже не стоит обсуждения, это факт.


Про Sphinxsearch знаю, для Битрикса есть кастомные разработки поиска и фильтрации товаров на его основе, как и для массы других CMS, кеширующий вебсервер Nginx использует большинство шаред-хостингов и веб-серверов высокой доступности для распределения нагрузки, кеширования статики ипроч, кеш Memcached тоже может использоваться в ряде CMS как локальный демон, так и удаленно распределённый с выделением отдельного сервера под этот демон. Не понятно к чему все эти утверждения. Такое впечатление, что вы решили вывалить весь арсенал который к теме автоматизации обработки прайсов особого отношения не имеет вообще.


Вот это единственное верное утверждение в пользу опенсорс ПО Linux и mysql которое можно использовать в вашу пользу, все остальное - чистая вода и профанация. Я бы на вашем месте больше акцентировал внимание на этом, а не на режиме мнимого "реального времени". Вот только напрашивается вопрос, для поддержки вашей системы со всякими Sphinx, nginx, memcache, mysql, linux, репликациями и прочим - квалификация вобще не нужна? Как по мне, квалифицированных специалистов по Windows из-за ее массовости больше чем по Linux, а соответственно обслуживание Windows - дешевле.


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


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


Я не представляю смысл таких действий. Любой здравомыслящий человек не будет афишировать и раскрывать детали своей деятельности на всеобщее обозрение, кроме как бессмысленно похвастаться. Тут даже коммерческий шпионаж не нужен, все сами преподносят. Хотя стоящими идеями просто так не разбрасываются.


Снова трактат о каком-то мифическом реальном времени. Что мешает сделать триггер в базе данных и синхронно обновлять информацию о товарах в интернет-магазине?!? Или запускать синхронизацию через API с минимальной дискретностью???


Я торговец, а не ИТшник. Меня интересует обстановка в общих чертах для понимания причинно-следственных связей. Если нужно будет углубиться в какие-то конкретные детали того или иного механизма чтобы решить некую конкретную задачу, я это сделаю. Но для общего развития я не буду захламлять мозг не нужной информацией в доскональных знаниях про 1С.


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


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


И снова: распределенные транзакции, кластеризация, общее файловое хранилище, распределенные операционные системы, облачные серверы - технологий достаточно (если я где-то ошибся, то извините, таки я не спец в эти вопросах). Наверное есть и другие. Самая простая - работа компонентов в одной "локальной сети" без затрат времени на передачу информации.

В mySQL возможность использовать триггеры, процедуры и функции появилась не так давно, но это все равно пока не позволяет разрабатывать бизнес-логину на стороне этой СУБД в отличии от MS SQL Server и Oracle. Как тут уже правильно заметили - это пародия на базы данных которая годится только для хранения и выборки информации, но не для разработки бизнес-приложений особенно для больших компаний.

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


Ну так жизнь такая... Потому программеры выкручиваются как могут и стараются парить нам все, что только можно. Самому приходится вникать во все технические детали чтобы не попасть в просак и не покупать бесполезные или не нужные вещи. Весь маркетинг как раз состоит в срезании "острых улов" и по сути так или иначе - в обмане клиента. Закон рекламы, что тут еще добавить.

Про миф о системе реального времени понравилось, спасибо.

Да, пора уже закрывать обсуждение. Кому нужно реальное время, тот понимает зачем )

Читаем: "MySQL является частью платформы LAMP (Linux, Apache, MySQL и Perl/Python/PHP) и используется в таких крупных проектах как Twitter, Facebook и Flickr." http://servernews.ru/tags/mysql

Все можно сделать, было бы умение.