Помогите убедить заказчика о вреде синхронизации методом прямой записи в mySQL #596735

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

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

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

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

Тебе-то не пофиг? Пусть использует.

Зачем?... Им то какая баня, как это будет писаться, прямым, не прямым способом :) А так, лишь бы платили, а для клиента за его бабки, хоть звезду на рабочий стол :)

Если только он не умеет этого и не желает уметь :)

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

>>> напрямую из базы сайта (mySQL). Только щас осилил... , и какие проблемы? Пускай 1С на прямую пишет туда и обратно, что хочет :) У заказчика правильный подход, 1С 8.х это умеет не хуже 1С 7.7. :)

+ Тебе только надо оговорить правила заполнения ключевых полей в SQL сайта и вперед. Не думаю, что там используются битные типы, но и с этим 8-ка умеет работать.

А что тут неправильного? Вполне нормальный подход.

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

в движке или структуре данных?

Ты на фикси? Сайт не так сильно меняется, обычно реквизиты добавляются, а не на оборот :)

Пусть напишут интерфейсные фиксированные процедуры и сами их поддерживают при изменении.

Так же придется дописывать в 1С какой-то механизм успешности внесения данных. Т.е. если в процессе внесения данных в базу сайта произошел сбой, нужно откладывать запрос и ждать пока появится возоможность его выполнить? Т.е. как быть в случае когда 1. Менеджер обработал заявку. 2. 1С не смогла выполнить запрос (нет связи с сайтом) 3. Второй менеджер обработал еще одну заявку 4. 1С еще раз пробует выполнить запрос (предыдущий от первого менеджера, и текущий от второго, но связи нет). 5. Через час связь восстанавливают 1С подымает из "буфера" все запросы и засылает на сайт последовательно? Я правильно понимаю что такой механизм придется создавать на стороне 1С, и что его готового в типовых конфигурациях нет?

Запусти обновление номенклатуры/цен(еще чего-нибудь) в хорошем объеме - посмотри, как будет в это время сайт работать. Недавно видел обратный процесс. С сайта в 1с грузится номенклатура(с характеристиками), цены, картинки и ссылки. (На сайт все грузится из агента тырнет-магазина). Все всем нравилось, но когда кво позиций приблизилось к 5000 - наступил ппц. Запрос намертво заглючивал сайт и возвращался ни с чем.

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

А это не равнозначно по затратам - парсингу XML Файла?

Учи матчасть...

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

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

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

всегда есть некий компромисс...

Каким образом они могу предоставить мне неизменный интерфейс? Путем вызова с моей стороны хранимых процедур созданных ими на сервере? Или есть еще какие-то способы? Т.е. со стороны спецов я слышал предложение: "Мы дадим тебе структуру таблиц - пиши что хочешь"... меня это настроаживает. Т.к. получается на меня ложится ответственность за успешное функционирование сайта.

сделайте обмен на веб сервисах

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

"Мы дадим тебе структуру таблиц - пиши что хочешь" - с такой постановкой вопроса я бы тоже не согласился. Или хранимки или xml или если в случаии проблем я не виноват.

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

сделать "случайно" DROP TABLE в MySQL =)

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

Делайте промежуточную базу обмена SQL

Примерно так. Ну и хотят переложить ответсвенность друг на друга...

Вариант на 5+, специально для извращенцев :) Хотя, в случае, если никто не хочет брать на себя ни за что ответственность - замечательное предложение :)

три базы... в одну выгружанется из 1с, в другую - с сайта. а третья всасывает из обоих, разруливает и раздает...

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

И кофе варит, фигли. На разработку - полгода :)

Да ну... бредово :) Все сведется к тому, что проще было бы сделать все в одной БД :)

рассуждения дилетантов на лицо...

Я хорошо знаю SQL (вернее ту его часть которая работает в MS SQL). Думаю что mySQL не на много отличается, особенно в тех маштабах которые необходимы для реализации обмена. Меня смущает только одно - 1С не имеет встроенного механизма работы с mySQL, а следовательно нужно будет цеплять или внешнюю обработоку (тут еще вопрос какую?) Или же "игратся" с OLEDB или ODBC провайдером... что бы кидать запросы и читать данных из базы сайта. Поэтому XML вариант показался мне в этом смысле более надежным решением. Вопрос прямой записи в базу сайта возможно и не подымался бы - если бы  я разрабатывал самостоятельно и сайт и 1С-часть. Но т.к. за сайт отвечает совершенно другая компания - как ни крути а в момент разбора полетов в стиле "почему все нае...лось..." хотелось бы иметь возможность отстоять свою правоту а не быть самым крайним в этом вопросе.

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

1. Возможность "случайно" дропнуть все таблицы. 2. Синхронизация ломается при изменении структуры БД сайта. 3. Доступ к БД сайта извне - дыра в безопасности и могут уплыть "данные о контрагентах и объемах продаж".

+ скажи заказчику "зачем вам дважды платить при изменении сайта - и им за сайт, и мне еще за доработку синхронизации".

Спасибо. Наконец-то пошли аргументы. 1. Пункт - отметут сразу. Т.к. вина программиста - раз дропнул пусть восстанавливает. Да и в системе которая написана и отлажена такое врядли случится. 2. Контрагумент со стороны веб-студии: "Сайты не меняются, он будет работать вечно" (я конечно утрирую - но ключевая мысль их ответа такова). 3. Дыра в безопасности - это "зачетный" аргумент, только его нужно более аргументированно озвучить -приведя пример, как этой дырой может воспользоваться злоумышленник. Я не ломал сайты, поэтому даже принципов не знаю... кроме общих фраз такх как "SQL-инъекция" и т.п. которые щас у всех на слуху...

я за XML с ЭЦП (подпись), чтобы потом если что, можно было этот XML предъявить сайтоделам..

Нехорошо делать умное лицо и говорить при этом глупости. Не люблю очень, когда так делают. >1С не имеет встроенного механизма работы с mySQL, А с Ms SQL - имеет? >следовательно нужно будет цеплять или внешнюю обработоку (тут еще вопрос какую?) Что страшного во внешней обработке? Другой вопрос, что по смыслу тут не внешняя обработка, а внешняя компонента, в которой в общем тоже нет ничего страшного. >Или же "игратся" с OLEDB или ODBC провайдером... что бы кидать запросы и читать данных из базы сайта. А в этом что страшного? Это абсолютно стандартное средство, используемое не только 1С. >Поэтому XML вариант показался мне в этом смысле более надежным решением. Он показался более надёжным решением потому, что других решений кто-то в глаза не видел. В целом, недостатки есть у любого подхода, правильный подход - некое соглашение о форме обмена, неизменное с обеих сторон, то что обычно именуется интерфейсом(не пользовательским, а интерфейсом обмена, если угодно). В какой форме это соглашение будет реализовано(файловый обмен в любом формате, веб-сервис, прямой запрос к бд, хоть обработка голубиной почты с распознаванием рукописного текста) - дело десятое. Основной проблемой в данном случае мне лично видится недостаток квалификации с обеих сторон при нежелании нести ответстсвенность за этот недостаток. Всё, я кончил и закурил :)

ЭЦП не имеют юридическую силу, а те ЭЦП которые имеют юридическую силу в Украине - лучше ими не пользоваться. А так идея прикольная, тот же pgp подписал закрытым ключем и "от меня снаряды ушли".

1. Вина - это понятно. Всегда есть бэкап, но время на восстановление - это деньги заказчика в виде потерянных заказов. 2. Можно сказать "я на этих ваших сайтах собаку съел, и ни разу обещание студия не сдержала". Проверить они это все равно не смогут, а у вас лишний аргумент :) 3. Злоумышленник, поняв что на данном хосте открыт mysql, может начать его брутфорсить, и, подобрав пароль, дропнуть таблицы. Тут опять же потери те же что и в п.1. А может не дропать, а тупо воровать инфу о клиентах и их заказах. Или базу сливать и продавать налево. Оперируйте понятиями "коммерческая тайна", "убытки" и "потеряные клиенты" при общении с заказчиком. В конце концов можно сказать "я вам пишу систему и условие ее бесперебойной работы - наличие xml-обмена. если его не будет - претензии по стабильности работы не принимаются" и написать так, как хочет заказчик.

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

если перед этим сделать тунель ssh по ключам, то может и не совсем нубы. :)

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

ага и конектиться к базе конечно рутовыми правами) походу 1сники вообще не понимают что такое базы)))

+ По той простой причине, что проблемы с БД могут быть вызваны не только злыми намерениями. Нубы-параноики это не учитывают.

1с-ники как раз-таки против..

мое мнение что выгрузка-загрузка что через XML что через конект один фиг дыра

Мне понятен Ваш праведный генв, и прошу прощения, что в сообщение высказал несколько неточную информацию. 1. Говоря что 1С не имеет встроенных механизмов - я не сравнивал отсутствие одних с наличием других. Я просто констатировал факт отсутствия механизма как такового. 2. Да, действительно, произошла опечатка с подменой понятий. Действительно имелась ввиду "внешняя компонента". И к моему стыду, я не знаю, и не проводил поиск еще, какие из подобных компонент доступны на "рынке". 3. Под "игратся с ODBC" я не имел ввиду ничего страшного. Подразумевалась существенно-болшее количество трудозатрат на подготовку, обработку и настройку, что в свою очередь увеличивает стоимость решения для заказчика, и тем самым уменьшает вероятность его реализации. 4. За 10 лет кодинга на 1С 7.7. (пусть и с перерывами), кое-что видел. И некоторе количество собак съел, поэтому обращаясь к решению с использованием XML вижу в нем некоторые преимущества связанные с универсальностью решения, а так же с минимизацией трудозатрат. Что касательно разработки общего интерфейса - тут я сгласен, и поддерживаю Ваше мнение целиком и полностью. Более того, на данным момент, есть информация, что заказчик склоняется именно к решению записи в БД сайта (по результатам его консультатций с различного рода специалистами и собственниками реализованных подобных решений)... Так же предстоит еще как миниум одна встреча на которой я буду пытаться договорится о разработке этого "интерфейса"...

при прикручивании ЭЦП и проверки целостности данных - нифига не дыра.

В общем случае - да, но что мешает уменьшить размер дыры в частном случае? :)

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

* добавит

синхронизация подразумевает чтение и запись/удаление. Разве нет? Там где есть удаление, есть возможность удалить все записи таблицы. Пусть не всей БД, но таблицы. А заказчику наверное всё равно с чем связаны его проблемы - с полным факапом БД или только нескольких пустых таблиц.

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

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

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

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

+1, или хотя бы таблички в базе сайта для импорта-экспорта

Объяснять надо на пальцах. У меня половина заказчиков далеки от компьютерных технологий, и тем не менее меня как-то понимают.

проводите аналогии. Например: Представьте что у вас есть сейф с деньгами. Вы сажаете у окошка кассира, которому говорите что вам оттуда нужны деньги, сколько и кто вы вообще такой. Кассир знает код от сейфа и может либо дать вам деньги, либо не дать, если посчитает что вы какой-то левый человек. А можно в окошко выставить сейф, и каждый проходящий мимо может попробовать подобрать код к сейфу. И когда-нибудь код подберется. Так вот сейф - это БД сайта, а кассир - это XML-обмен. А сайты с личным кабинетом и историей заказов не существуют?

у нас на прямых запросах. нет проблем.

а сзади у кассы есть дверь (FTP) подобрав пароль к которой ты увидишь на сейфе бумажечку с написанным на ней кодом от сейфа) и плакали твое денежки потраченные на кассира)

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

про "разделить сервер фтп от сервера БД" не слышал...)))

xml медленное и унылое г. если прямая видимость в локали что мешает дать права в базе и писать прямо в таблицы... если не прет самому копаться - пусть функции сами напишут которые ты дергать будешь

Все правильно предложили. XML это прежде всего вам гемор. Но это понимание придет позже.

Сайт и так будет хранить минимум информации. Вопрос поднят не в связи с объемом хранимой информации а в связи с выбором способоа доставки информации на сайт и обратно.

Сайт не в локалке, и вероятность появления его в локальной сети невелика.

Именно.. медленное и унылое... но как бааааааа "методически правильное решение сертифицированное курсами 1С и тд. .. и тп .."

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

Кто вам такую глупость сказал? 1С теперь решает, как правильно на сайты данные закидывать?

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

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

1С-неги как всегда, рассуждают о сферической безопасности сферического сервера в вакууме, подразумевая непричастных к теме обсуждения идиотами )

Если есть канал - проблемы скорости канала и его доступ в компетенции того кто его обслуживает.

пошли они на...

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

Оценил литературный талант! Обзываю я в других выражениях.

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

прямой обмен со скулем однозначно лучше

мы подразумеваем что там именно студенты, которые не умеют / им западло писать xml-обмен.

аргументация на высоте!

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

+ А все вопросы безопасности и доступа к БД Мускула - вопросы к админу мускула. К его политике безопасности и пр... 1С негу дали логин и пароль к БД и усе.

легко. нормальный обмен по крону, запись/чтение без ворочания xml файлов(скорость, гибкость), возможность изменения на лету скриптов, + "ВнешниеИсточникиДанных" пора для себя открыть. Нежелание писать сразу в скуль скорее всего от того, что просто нет умения.

+ накуя гемороиться им, открыли доступ к БД и все.. а XML писать надо, работать тобишь..

если ошибочное, то мы перебдели, что неплохо. гораздо хуже если мы недобдим, а наше "подразумевание" попало в точку. А вообще странно. На месте студии я бы зарядил за xml-обмен дополнительные деньги и тогда вопрос решался бы заказчиком очень просто - платить/не платить.

Вот развели флуд. Без разницы хоть прямая запись, хоть xml. Главное, что бы были согласованы правила обмена и записи. С логированием всех действий со стороны 1С в отдельный файл. Тут больше всего неправильна постановка задачи в "Мы дадим тебе структуру таблиц - пиши что хочешь"

+ Особенно когда наступит время бесконечных сверок  номенклатурного и прочего мусорка в 1С и Мускул.

Вижу, имеет смысл добавить голосование :)

!

Для всех самое простое и в плане согласования данных и в плане работы.