Заказчик, попросил установить 8-ку, с целью дальнейшей интеграцией с Интернет-магазином.
Интернет-магазин разрабатывает сторонняя веб-студия.
Установлена мной была типовая УТП для Украины. Когда дело дошло до синхронизации с сайтом, сошлись на мнениях что нужен двухсторонний обмен. Т.е. информация о товарах и ценах из 1С на сайт. Информация о заказах (товар, количество) с сайта в 1С.
Изначальное предложение сделать обмен посредством XML-файлов, на первом этапе был принят за рабочую версию.
После недели раздумий спецы из веб студии сказали что лучше будет если данные писать и читать напрямую из базы сайта (mySQL).
Я против такого подхода, но у меня нехватает аргументов объяснить почему так делать нельзя.
Помогите объяснить это заказчику, т.к. на лицо нежелание программеров веб-студии возится с парсингом XML файлов.
Аргументы со стороны веб-студии - мол парсинг XML будет занимать слишком много процессорного времени и будет "ложить" сервер. Т.к. мол, сайт заказчика на сервере не единственный и т.п. (сайт первое время будет хостится на сервере веб-студии).

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

Очень прошу помогите, только пожалуйста, без свойственных этому форуму замечаний о уровне интеллекта участников и всех остальных. Только аргументы которые можно озвучить заказчику.

ответ в (89)
хотя не совсем понятен пункт 4...

конечно так

(107) чорт, я не хотел голосовать за 3 ))

XML - тормознутый монстр без индексов и прочего

Вот так вот

(138) Вообще то самый лучший вариант, если объем данных позволяет.

Нафига огород городить, если можно писать напрямую?

Если есть возможность, всегда лучше напрямую.
Каждый божий день с mysql работаю.

БД это правильно, файлы - нет

Прямая запись  - это круто. А то выгрузил в 1С, ждешь ответа, подгружаешь ответ - долго все это, а так бац-бац - им мимо!

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

другое дело что и сайтописцы должны предусмотреть безопасный обмен с 1с, писать интернет магазин и не планировать соединение с 1с это феерическая глупость )))

Bulk Insert во временную таблицу Скуля, синхронизация, удаление времянки. быстро и элегантно. загрузка прайса на 10000 позиций при прямых руках несколько секунд.

у нас тоже так... через ssh

Почему никто из "сайтописцев" не ноет, что мол я боюсь ответственности, если что я тут не приделах, тем более не пытается просто сбить бабло за парсинг Xml. Все просто веб разработчик имея опыт реализации таких проектов может легко спрогнозировать будущие косяки при работе через xml и предлагает это выполнить прямым обменом данных(это как правило не удается реализовать так как большинство 1С спецов включают заднюю). Мое мнение не хотите реализовать это из 1с просто скажите нет. Тогда уверен студия сделает xml парсинг и вам не прийдется ни за что отвечать.

C XML выгрузкой тоже проблем много.
1) первая выгрузка: По личному опыту парсинг xml'ки в ~10к-16к товарных позиций с последующей их выгрузкой на сайт занимает от 1 до 2 часов. Тем более если так же нужно сравнивать с уже существующими товарами, дабы избежать дубликатов.
2) Синхронизация остатков, цен и т.п.: Зависимо от требований заказчика, а если он скажет, что цены должны каждые 10-30 минут обновляться. Начнете вы выгружать остатки, со стороны сервера настроится крон.. ну заглючил инет, или канал слабый, не доольется XML, крон ведь этого не знает... вот и попытается спарсить.

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

Второй вариант - веб-сервис.

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

1) если есть гуру 1С - Прямая запись в таблицы mySQL
2) если нет спеца 1С, но есть спецы веб-разработчики - Веб-сервисы
3) если нет ни ого ни другого - меняйте обе стороны)

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

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

Лично у меня обмен крутится на прямых запросах. 2 года крутится. Никаких проблем не наблюдалось доселе и вряд ли такое будет. Самая трудоемкая задача которую видел - выгрузка порядка 2к позиций - время выполнения порядка 7-8 минут с учетом всех проверок.

В подходе с прямой записью проще реализовать схему когда сайт ТОЛЬКО витрина, а весь backend находится в 1С и обмен ориентирован в первую очередь на события именно в 1С(изменение элементов справочников, проводка документов). Такой подход позволяет в конечном итоге сильно разгрузить сайт в смысле функционала коего в последнее время на интернет-магазины навешивают тонны. Загрузка заказов лично у меня реализована раз в 10 минут, такой оперативности вполне хватает. То есть со стороны сайта к 1С обращений нет вообще.
Это есть определенный подход к реализации системы в целом, а не отдельной задачи обмена.

Впрочем не имею ничего против файловых и прочих обменов если кому-то удобно. Мне лично нет.

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

Семь сайтов интегрировал через MySQL и пока все норм. Так что важна не технология, а тот специалист который с этой технологией работает.