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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

(15) Учи матчасть...

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

(27) Я хорошо знаю SQL (вернее ту его часть которая работает в MS SQL). Думаю что mySQL не на много отличается, особенно в тех маштабах которые необходимы для реализации обмена.

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

Поэтому XML вариант показался мне в этом смысле более надежным решением.

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

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

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

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

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

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

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

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

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

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

Оперируйте понятиями "коммерческая тайна", "убытки" и "потеряные клиенты" при общении с заказчиком.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

* добавит

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

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

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

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

зы
сам писал и всякие схемы, в том чиcле и на этом движке http://www.osg.ru/

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

только прямой доступ к таблицам сайта из 1с
сам сайт вообще не должен даже знать о 1с
как безопасник я ни в коем случае не согласен с ТС

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

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

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

(58) проводите аналогии. Например:

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

(61) А сайты с личным кабинетом и историей заказов не существуют?

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

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

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

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

xml медленное и унылое г.

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

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

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

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

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

(66)+

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

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

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

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

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

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

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

(73) пошли они на...

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

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

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

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

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

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

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

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

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

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

(87) если ошибочное, то мы перебдели, что неплохо. гораздо хуже если мы недобдим, а наше "подразумевание" попало в точку.

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

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

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

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

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

!

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

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

конечно так

Нападение - лучшая защита: предложить им самим читать из баз 1С, напрямую или через COM [шутка].

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

Не, погодите.
xml через фтп - это какое-то gov.no.
Нужно передавать xml-файл запросом (POST или GET - не знаю точно, не специалист, вобщем так же как картинки загружаются), а на сайте уже скрипт должен его парсить и что-то делать. Ответ также должен получаться в виде xml-файла.

(100) отсыпь...

+(101) уже вижу POST на 10 метров...

поясните пункт 4, пожалуйста :)

(101) да бери
(102) а в чем проблема? можно его пожать.

(103) Не ты делаешь update, delete, insert а хранимые процедуры, которые и проверяют правильность полученных данных и возможность записать, а также например пересчет остатков.

Короче: типа API, на запись, получение данных.

"4. Через "интерфесы" (вызвов хранимок серве"
тема сисег и "серве" не раскрыта. если ТС так же небрежно и код пишет - пиши пропало. :-)

(104) угу, надо еще и метод сжатия/распаковки уточнить с разрабами сайта... хотя они такие... у нас разрабы уже полтора года пилят обмен данными с БИТРИКСОМ, и ничего...
(105) а, ок. а в каком виде это добро отсылается на сервер? подход занятный, интересуюсь :)

(104) размер POST данных регулируется хостером, все равно можешь упереться в размер.

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

(107) gzip, что там уточнять ...
(108) прийти к соглашению о максимальном размере - это не проблема

(110) И что делать если достиг максимального размера, но не достиг конца передаваемых данных?

(110) будет круто, когда заказ на 200 строк не влезет в один файл. и как ты будешь их пилить/собирать?

(107)  Примерно так
Если ВыполнитьКоманду("EXEC i_price " + Стр,"ВыгрузитьПрайсЛист()") = 0 Тогда
   Возврат
КонецЕсли;

(110) На другой хостинг переехал и пришел белый северный зверек.

(111) писал на 77 такое (лет 6 назад), устанавливал для себя определенный размер файла, выгружал по аналогии как делает это RAR, типа part1..10, и ниче, на стороне загрузки собирал, все работало.

(111) делить на несколько сеансов синхронизации

(114) мазохисты %)

(113) мерси. а тыкни носом, где можно почитать об этом, плз.

гугль знает все "adodb + хранимые процедуры + mysql ". Ссылку сейчас не найду. Извиняй.

(118) та окей, нагуглю, спасиб

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

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

(120) я пользовал, вполне себе годно

Вот так вот

(122) а писать через ЭТО тоже можно, не только читать ?

(124) писать не пробовал, щас посмотрю

(119) почитай мои посты, там практически все грабли с мускулем

http://yandex.ru/yandsearch?text=MySQL+vde69&site=mista.ru&rstr=&zone=all&wordforms=all&lang=all&within=0&from_day=&from_month=&from_year=&to_day=&to_month=&to_year=&mime=all&numdoc=10&lr=213

(126) окей. спасибо

(124) нет, писать нельзя, по крайней мере пока

ИМХО, самое грамотное - через веб-сервисы. Хотя ни разу не делал, делал как раз напрямую :)
Зато красотень какая - все через четкие интерфейсы и 1С не обязательно в той же локалке. Легко в будущем еще с чем-нибудь интегрировать.

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

Напрямую - отличная производительность и масштабируемость (если по уму все делать), но прозрачности нет и к локалке привязка. Частично лечится путем (11)

2. Через XML (обмен файлами через nnCron по FTP)

(100) Очень правильно мыслишь. Еще чуть-чуть фантазии и ты изобретешь веб-сервисы :)

(131) правильная мысль - это главное и основное :)

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

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

Ага

(133) +1

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

1cнику одинэсово) а админу админово)
каждый должен в своей области заниматься)

кстати и по разработке самый дешевый вариант

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

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

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

(140)Собственно любой обмен(интеграция) геморой по определению. Куда лучше формочку написать с десять полями и долбить на запись. А как и куда они будут "улетать" это "наймем специально обученного человека" :)

лол 1сники в своем репертуаре,
заказчику пофиг как вы сделаете его волнуют сроки и стоимость.
стандартный обмен работает почти из коробки, и стоит 0 денег. Зачем строить велосипед с квадратными колесами, у вас что задача сделать промышленный билинг?
Подключай заказчика, нагибай веб-программистов.

(0) Кури типовые доки, допиливай стандартный обмен CommerceML.

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

(143) для этого есть ХП, описываем интерфейс ХП (типа добавить товар, получить заказ) сами ХП пишут и отвечают вебисты, а 1сники за вызов хп с нужными параметрами

(142) +1, все же в битриксе уже есть, может оттуда взять идею:
http://1c.1c-bitrix.ru/ecommerce/#tab-integration-link
?
Заодно и веб-программистов нагнешь, расскажешь что такое CommerceML и что реализации под битрикс уже существуют (на стороне веб-сервера в т.ч.) и было бы глупо изобретать велосипед и делать через прямые обмены, подвергая доступ к базе а так же сохранность информации в базе опасности. Т.е. лучше взять готовое отлаженное решение, нежели натыкаться не непонятные проблемы.

(140) запятые забанили? :-)

(144) кто, где и как будет выполнять проверку типов передаваемых параметров? :-)

... и значений (максимум/минимум), чтоб не повторить опыт Фобос-Грунта...

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

(0) Заказчик случаем не Попович Андрей? )

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

(151) +100500

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

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

(151)И что? В любом случае весь обмен придется переписывать.
С тем же успехом фирма может в любой момент обновить учетную систему.

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

(151)(154) +
И минусов прямого обмена дофига:
* база открыта извне
* вся ответственность ложится на программиста 1с, хотя за сайт должны отвечать т.н. веб-программисты
* доработки становятся более затратны, чем при использовании стандартных средств (CommerceML)
* программист 1с - не всегда человек, который сможет правильно записать в MySQL данные, не обязан обладать знаниями языка запросов, работу блокировок и транзакций в MySQL + ему же не просто надо будет записать, но еще и подтереть старые данные наверняка, ведь на сайте периодичность цен нафиг не нужна в большинстве случаев, а это лишние условия в запросах и т.д., т.е. далеко не фронт работ программиста 1с
* при разрывах соединения транзакция может не завершиться, придется 100 раз делать выгрузку и т.д.
если со стороны 1С че-нить кривовато:
* могут появляться несогласованные данные при каких-либо сбоях
* база может побиться
* данные могут быть некорректны, если не будут должным образом проверены при загрузке/выгрузке

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

(156) то что ты не выделил четко твою зону ответственности, и в случае форс-мажорных ситуаций ты будешь тратить свое личное время на разруливание чужих ошибок (157).

(157)
1)не факт.
2)с чего бы это?
3)Почему?
4)Ну это проблема программиста, не умеешь, не пиши.
5)При разрывах соединения транзакция обязана не завершиться. Что мешает повторить?
6)Независимо от реализации обмена, ежели будут сбои то будут и косяки.
7)Она в любом случае может побиться.
8)Они в любом случае могут быть некорректны.

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

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

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

(163) 1c-ник не обязан уметь работать с MySQL, а вот веб-студия с XML должна иметь опыт.

(164)Конечно 1с-ник не обязан работать с MySQL, но какого хрена он тогда хватается за организацию обмена с сайтом?
С чего бы это веб студия должна иметь опыт?
Просто должен быть адекватный специалист который будет представлять как это должно работать.
И этот специалист должен определить наиболее предпочтительный вариант обмена в данной ситуации, и найти адекватных исполнителей которые реализуют этот обмен с обеих сторон.

кстати, забыл проголосовать

(0) бгыыыыы

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

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


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

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

(168) чем тебе принципиально не нравится напрямую "писать" в опубликованные на сайте вебсервисы? :)

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

а как оно там размазано в табличках сайта... или вообще в тексте хранится - тебе до фиолетового барабана

(99) Почему шутка? Толковый веб прог легко поднимет OLE-демон который будет себе корректно лазить в 1С, у меня так статуса заказов работали

(169) С чего ты взял что, программеры написавшие сайт, умнее тупых одинэсников? Скорее там вообще какой-то вебмагазинный щаблон

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

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

(172) потому что теоретиков слишком дофуя а практиков нет.. или они в форумах не трындят...

опять же.. многие привыкли делать все на коленке из соплей и скрепок...

А может есть статьи где рассматриваются все плюсы и минусы XML синхронизации? Такие может есть статьи где на доступном "человечьем" языке - ругают и дескриминируют подход прямой записи в базу вебсайтай?

(175) задай простой вопрос: когда хостинг переедет с сервера вебстудии - кто дасть 100% гарантию прямого доступа в субд сайта?

(176) Вопрос хороший, но предвижу что ответ будет таков: "Если сайт куда и передет, то на собственный сервер заказчика!"

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

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

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

Почему не хотят xml-файлы - потому что MySql не умеет их кушать сам. То есть нужно писать парсер, который будет кушать файлы и загружать их в базу. В случае Web-сервера есть два варианта - или читать через php-скрипт, которому кормим этот файл, но тут мы приходим к тому, что называется Web-сервис, и как ни называй, то, что будет реализовано, оно всегда им и будет.
Второй вариант - загрузка xml в базу процессом, запускаемым через Cron и т.п. Здесь есть сложности с тем, что у большинства тарифных планов на Web-хостинг нет возможности запускать сторонние процессы, а также тем, что они очень сильно зависят от вида операционной системы на сервере (а там может быть и Фря и Винда).
Прямой доступ к MySql, на самом деле, получается не таким уж и плохим решением, если версия MySql поддерживает транзакции, а если нет, то их реализовывать придётся самому. В принципе, разницы между прямой записью и хранимой процедурой в случае MySql не так уж и много, единственное, чего можно ожидать, это проверки на защиту и целостность данных, но всё равно писаться будет построчно.

Что касается безопасности, то прямая запись, конечно, наиболее опасна для базы сайта, но в случае записи из 1С опасность исходит от действий сотрудников, а они, всё-таки, не враги. Но, гарантия доставки данных и возможность проверить их правильность в этом случае гораздо выше, чем в случае отправки xml-файла, который могут съесть с ошибками или вообще не съесть, а 1С узнает об этом намного позже.

я бы использовал:
1. механизмы внешних источников данных.
2. механизмы регистрации изменений и планы обмена.
3. прямую запись в mysql(если физически всё рядом)
и веб-сервисы, если физически это в разных сетях.

(180) да всё просто - если заказчик ответит утвердительно на вопрос: "Вы понимаете и принимаете, что все непонятки с обменом, а так же вся обязанность по его сопровождению полностью лягут на вас в случае, если вы этих хомяков послушаете", то, ну, чего ж тут зря воздухом трясти? Стриги капусту, пока клиент не остыл

По хорошему приоритеты такие:
3.
4.
2.


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

"Какой-нибудь "кулхацкер" выполнит произвольную команду на этом веб-портале, а 1С накроется".

И не слушай тех, кто говорит, что вариант прямой записи в СУБД - это нормально. Эти люди на своем фикси и фрилансерстве ничего серьезнее автоматизации ларька не видели.

(184)бред.
особо с ларьками..

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

(185) ну хз.. я вот столкнулся например с тем что разработчики веб портала (с которым я обмен настраиваю) не только не дают какой бы то ни было доступ к "внутренностям" сайта, они еще и обмены требуют нерпеменно через soap+https да еще и с предварительным ключем авторизации в заголовках пакета (спасибо разработчикам платформы, wsпрокси тут славно обоср.лось и приходится юзать мссоапклиента)

на вопрос: накой хер это все нужно? ответ простой - безопаснотсь.

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

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

кстати, дайте названия хостера где в качестве СУБД используется MSSQL да еще и свозможностью свободного внешнего доступа?

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

интересно чо будет если начальник не идиот...

(188) а.. там mysql... сори...

+(190) хотя года три назад, когда делал для своей гомнонетленке функцию загрузки заказов клиентов с сайта - столкнулся с ситуацией что первые попавшиеся хостинги (типа vh2.ru например) никакого доступа снаружи в  СУБД не предоставляли... и по заявке не включали..

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

(189) ээээ не ну а чо...

delete * from .... where 1=1

и досвидос данные сайта, не ?

вернее ка там delete from ....

Я не первый раз убеждаюсь, что миста-это сайт для толстого троллинга.
Прямая запись данных в учетную систему из любой ВНЕШНЕЙ системы по элементарным требованиям информационной безопасности, к счастью, не пройдет. Я уже про SOX не говорю.
Внутри компании - еще можно реализовывать подобные обмены. Обмен с внешними системами (повторюсь) недопустим.

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

(195) чо за грязное хранилище и "вьюхи" на простых типических веб-хостингах?

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


там блин у половины хостингов дается одна-две базы на все домены подписки + один какаунт с полными правами на эту базу..

(192) это мелко, Хоботов... сразу truncatetable

(197) бгыы да похрен.. главное что см (196)
из одного админского аккаунта там можно всечто угодно наворотить... а обычно он один и дается...

(196) ага... т.е. проблема не "ужасном прямом доступе к базе", а в элементарной безграмотности обслуги в IT?

(195) Про "грязное хранилище" не слышал. Какое имеет отношение view к теме обмена данными (прямая запись в БД mysql) не понял. Вы научитесь или давать развернытые пояснения, или бросайте ваши кости в урну. А кидать "фразы" "наподумать" выдает в вас дилетанта. Впрочем, ваша личность мне и до этого известна - вы тут в поиках еды. Не стыдно быть в 35 злым, бесперспективным, бестолковым? :)

(199) ну типа тово.. это как с полными правами тупоюзера на компе..

конечно.. можно ВСЕМ раздать пароль от рута, да чо там.. пусь все в сети работают с правами админа контроллера домена.. чо уж там...

меня что пугает в вэб-сервисах и прочих перделках-свистелках - их реализация на стороне 1С. не будет "заговолок" совпадать - хоть на колени становись...

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

(202) ыыыыыыыыыыы

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

ибо https+ключ в заголовке это для 1С SoAP клиента непосильная задача..
все.. пля.. все переписывать...

(203) не, там просто все очень просто: разработчик веб портала работает не по принципу "наотъе.ись" и соответственно за результат, в том числе и за результат обмена на стороне "портала" отвечает... и всякие непонятные личности которые чото там ваяют на бейсике переведенным промтом доверия у разработчика портала не вызывают...
по этому и поднимается соапсервис...

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

(202) Лично делал два проекта с веб-сервисами. Все работает как часы. А пугает вас неизведанное. Ну, и лень "заморачиваться?" вы учитесь, учитесь - в IT это надо всегда делать. А то через пять лет придется за кресло на фикси двумя руками держаться, понимая, что неликвиден, да на мисте свою пену эпилепсическую выплескивать. Добрее надо быть :)

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

кстати, автор, смоделируй ситуацию: 1С крутится в серверном режиме на линупсовом сервере... каким раком ты будешь прямые запросы в mysql делать?

в винде вроде для этого надо ставить специальный драйвер... а в линупсе что?

(208) Выгрузку в XML - я закладывал в объем работ, и согласен его дописывать т.к. мне известен объем задачи, и нет необходимости решать дополнительные проблемы (такие как транзакции, контроль успешности записи, контроль обрыва связи, и т.п.)
(209) Уверен на 1000% никто 1С не будет ставить на линупс :-) И слава богу, ничего не надо будет моделировать... и без этого хватает....

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

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

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

>А пугает вас неизведанное. Ну, и лень "заморачиваться?" вы учитесь, учитесь - в IT это надо всегда делать

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

(205)кстати, это ты там выше писал про xml? как ты представляешь себе ежедневное автообновление прайса и остатков на 50 т. позиций? пусть даже частичное, по изменениям.
а онлайн запросы по доступности товаров? тоже через файлики xml?

(213) а чем тебя смущают файлики xml в этой ситуации?

+(213) я вообще то ратую не за файлики xml а за soap сервисы...
оно там  в принципе конечно в какой то мере да- тоже самое xml - но не надо файликами заморачиваться по загрузке/выгрузке оных через всякие глупые фтп..

(213) Заказчик не настолько суров что бы каждый день обновлять цены в 50К позиция номенклатуры. Да и нет у него такого объема - максимум 7-8К. Будь у него такая ситуация как Вы описываете - возможно и ситуация была бы другая... и сервер изначально был бы в локалке заказчика, а глядишь и веб-студия без "закидонов".

(215)а, акела промахнулся, я по диагонали читаю

(215) ftp не обязателен, можно скормить файлик php-скрипту, как на любом файлообменнике реализовано

(216)хз, там много всего надо грузить.
вот пример инет-магазина - там у номенклатуры стопицот свойств, куча народу их дописывает, меняет, все это надо грузить на сайт, а ведь есть ещё и цены, и остатки, и заказы, и бог знает что ещё

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

(219) ну так самый правильный пример ЗА организацию вебсервисов..

есть 2 стороны: вебсайт и 1С
когда одна из сторон находится в постоянной колбасне - вебсервисы это то что позволит обеспечить работоспособность ресурса..
пример:

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

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

(209) хороший вопрос... будет трах с поискам вменяемого драйвера odbc

(220)для этого можно использовать механизм регистрации изменений 1с

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

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

(221) они вероятно так и сделали в итоге... если не идиоты... сделали пару таблиц под грязное хранилище - пишите чего хотите, сами выгребем и куда разложим... вопрос чтения решить через view

(223) я про то, что при изменении свойств сначала надо будет сделать запрос на удаление старых свойств в мускуле и потом еще добавить новые, т.е. передавать при обмене придется не только новые данные, но еще и править старые

(226) реальные пацаны в мускуле заюзают update :)

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

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

(227) вряд ли свойства лежат в 1-й строке

(229) а никто не говорил про один запрос :)

Народ, вот объясните мне как победить аргумент, который наверняка последует от заказчика: "мой кентюха юзает магазин, и заливает из 1С-ки все прямыми запросами!"? Как его (заказчика) в этом случае убедить что и он и его "кентюха" неправ.
Дело в том что мой "авторитет" выше "авторитета" спецов веб-студии (относительно шкалы авторитетов заказчика разумеется), но спецы вебстудии использовали "запрещенный прием" - сославшись на своих кентов, который "сто раз так делали"... тем самым вынудив самого заказчика связаться со своими кентами, которые подвтвердили "якобы правоту" спецов вебстудии.
У меня, как назло нет ни одного кента - которого я мог бы выставить в противомнение ;)

(231) ты спроси: " а если ваш кентюха будет с ч0рным властелином анальным сексом заниматься, вы тоже примкнете к веселому круду педерастов?"  всмысле "если кентюха лох и ему впарили заведомо ущербное решение - зачем пренимать этот идиотизм?"

(232) круду - кругу

(231) еще раз: твои аргументы:

1. наличие сторонних "драйверов" и как следствие риск отказа обмена в следствии проблем с совместимостью этих драйверов с железом/операционками

2. не известно как хостер отнесется к прямой записи в базу - есть примеры запрета на это противоестественное действо.

3. выигрышь в траффике и скорости обработки данных сомнителен, механизмы обеспечения целостности залитых данных (особенно при больших объемах) будут громоздские и дорогостоящие

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

5. любое изменение сайта потребует привлечение специалиста по 1С для переделки механизмов обмена

(232) Лох - это тот у кого впаренное решение неработает ;) А если у лоха интернет магазин функционирует, и не доставляет этому кентюхе проблем которые он мог бы озвучить - значит .. он какой-то особенный лох? Или я что-то не так понимаю в этой жизни?

(234) Попробую их опровергнуть - от лица спецов вебстидии.
1. Раз ты не можешь настроить доступ к базе - ты ламер (ведь все вокруг уже давно настроили) не можешь - мы пригласим другого спеца, который может это настроить. А раз это настроено - значит будет работать. Ведь у Вас нет фактов подтверждающих обратное.
2. Хостер это мы (веб-студия) - а в случае перезда, будете выбирать тот хостинг который дает такие права, или же будете хостится на собственном серваке.
3. Трафик в наше время стоит копейки, по сравнения со стоимостью которую мы озвучили за реализацию парсинга XML
4. Каким образом можно "коцнуть" что-то из 1С, если все запросы отлажены. И пользователи сами не имеют возможности писать запросы?
5. Пожалуй единственный аргумент - шо правда то правда, но мы не собираемся менять Вам сайт! А вы?

(236)

1. какая разница ламер лично я или нет - предоставьте odbc драйвер для линукса.

2. зачем мне ограничивать список хостеров искусственными параметрами которых можно вполне избежать

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

4. легко - давайте прямой доступ к базе своего сайта - покажу..

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

зы: задам вопрос хостерам: вы что, неспособны поднять SOAP сервис для обеспечения безопасного обмена данными с сайтом?

+(238) могу привести кучу примеров долгой и успешной работы по обмену данными между 1С и вебсайтом посредством вебсервисов...

и этих примеров всяко больше чем прямые запси в какие то таблички...

(239) Подозреваю что своим постов вызову лавину критики, но подскажите как из 1С работать с SOAP?
(Вот уж с чем не работал - так это точно... вот с этим... хотя теорию в общих четрах и знаю).

http://its.1c.ru/db/v8doc#content:708:1:IssOgl1_17.3. Работа с веб-сервисами сторонних поставщиков

пля - это была ссылка целиком :)

(242) Как раз ничего страшного - старый добрый хром умеет открывать и такое ;)
Но я настколько суров что не имею доступа на этот сайт - поэтому поищу на образе последнего ИТС. В любом случае спасибо за наводку.

(243) самый прикол в том, что если не задрачиваться с https и прочими изъе.ами типа заголовков с ключами, то работа из 1С с SOAP сервисом заключается в

1. подключени (2 строки кода)
2. юзанье функций soap и разбор входящих данных

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

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

(243) Книга знаний: v8: Использование внешних web-сервисов в 1С:Предприятие 8

21-й век на дворе, а они до сих пор напрямую в базы писАть собираются

(246)Мы же не в курсе, где у них там сайт лежит.
Может оно у них под поком, в соседней комнате или на винте :)

В новых версиях MySQL,начиная с 3.22 добавлены еще 2 таблицы- tables_priv и columns_priv,которые позволяют задать права доступа к определенной таблице в базе данных и даже к определенной колонке.

такое ощущение что никто про права не задумывается... дали доступ к базе? грохну все таблицы... а кто вам прав то даст эти таблицы грохать...

(249)Автор и просто не может сделать, а ты про права :)

+ Права, это последний этап.

ну да проще содрать деньги на реализацию XML
которая наверно уже написана) вот и пропихивает

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

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

8 лет сайты пишу..
1,5 года 1с занимаюсь
10 лет в банке проработал) а там безопасность эт превыше всего
клиент банк разрабатывал
знаю о чем говорю...

(254) это ты про что?

(254) кстати заводить ключем это прошлый век) сейчас машины кнопкой заводятся, т.е. замыканием проводов)

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

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

(219) а фоток номенклатуры (в фас, профиль), массо-габаритных характеристик и цвета нет? мелко... :-)

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

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

(259)А ты что хотел бы хранить фотки в базе?

(262) я - нет, но интернет-магазин без фоток - моветон :-)

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

Завтра! Завтра будет противостояние :)

Кстати да - если есть фотографии и описания товара, то положить их как в xml-файл, так и в базу SQL не есть правильное решение - файлы с картинками должны жить на диске в определённой директории, а вот размещение их туда какими-либо средствами, кроме Ftp или Web-сервиса - это не очень хорошее решение.

А для тех, кто вспоминает про безопасность, хочется заметить, что при прямой выгрузке из 1С в базу SQL есть возможность простой выгрузкой эту базу восстановить, если кто-то нечаянно её запортил. И, если в базе живёт только справочник товаров, то при выгрузке он будет просто обновляться.

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

Если на сайте нет никакой дополнительной информации, которой нет в 1С, то это распространённое действие мы выполняем через DELETE FROM TABLE, а после INSERT INTO TABLE то есть практически прямой записью в таблицы, а как она уже будет сделана - напрямую в MySql, через какого-то постредника, который или выполняет команду или читает файл - уже не очень-то и важно.

Если же на сайте есть какая-то информация, которой нет в 1C, то мы, в принципе, не можем формировать содержимое сайта из 1С. Тогда простой записью (то есть DELETE потом INSERT) мы работать не можем. В этом случае нужно куда-то сначала считать весь справочник, потом сравнить его с данными в 1C и отличия в данных исправить в базе сайта. То есть прямая запись в основную таблицу сайта крайне нежелательна. Но делать сравнение внутри движка сайта нежелательно, так как в этом случае будут торможения в функционировании - нужно будет выполнить сравнение, проанализировать его и результат (то есть список изменений) внести в базу, а список изменений будет хранится в памяти процесса, обрабатывающего данные (ну и не стоит забывать, что для сценария php отводится достаточно ограниченное время выполнения - так что придётся писать на чём-то другом).

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

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

(267) Очень интересно услышать симптоматику проблемы, чего такого в файлах этих, и сколько их что 1С не успевает.
С какой частотой запускается загрузка?
Что за файлы?
Из-за чего по вашему мнению создается основное замедление процесса.

(269) бгыыы

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

ну и что ты получишь?

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

от тех кто на бугатти - утверждения что "спойлер не нужен" и "спойлер - удел нищебродов"

от всяких уличныхгонщиков - утверждения что у правильной машине спойлер по умолчанию в комплекте


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

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

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

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

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

(272) В любом случае, много маленьких операций (или много маленьких xml-файлов) намного лучше, чем один раз всё и сразу.
Обновлять цены 10-30 минут - а их кто-то с такой скоростью вводить успевать будет ? Предположительно же - пришёл товар, на него определили цену и вперёд на сайт.

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

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

v8: Помогите убедить заказчика о вреде синхронизации методом прямой записи в mySQL
Тогда это уже и является вебсервисом. Зачем локально грузить много маленьких xml, если их можно послать прямым запросам по SOAP или REST.

(274) Если есть 1С специалист, он с уверенностью согласится с любым решением. Т.к. специалисту пофиг как делать... вопрос изначально задавался об идеологическом подходе. Потому как разработали такой инструмент как XML, сама фирма 1С создала целый "паравоз" с использованием этих механизмов, и тот же CommerceML да и Универсальный обмен ничем не хуже. Но все суровые вебдизайнеры и 1С-неги ратуют именно за прямую запись...
В моей голове это складывается в некую аналогию:
"Правильные (настоящие, суровые) программы нужно писать на ассемблере (а еще лучше в инструкциях процессора) - почему? Потому что не тормозит, потому что быстро работает. И все эти ООП-идеологии, .NET, java и прочее от лукавого и только замедляет исполнение программы. И если ты не умеешь на ассемблере писать то ты лошара а не программист иди и убейся об стену)"

(276) OFF. Беседовал тут недавно с одним финансовым директором (женщина предпенсионного возраста). Так она мне рассказывала что тоже программист, и что помнит как замечательно было когда она смогла автоматизировать бухучет колхоза используя перфокарты. И надо было видеть ее выражение лица полное городости и одновременно презрения к нынешним "гуру программирования" которые (по ее мнению) и слыхать не слыхивали о настоящих программистах :)

(275) это куда вы нас послали только что этой ссылкой? :-)
почему бы не написать просто (273)?

(0)Все не читал, времени нет, из личного опыта по вопросу:
для того что бы писать напрямую в базу MySql, которая находится на удаленном сервере - нужно, что бы вам предоставили доступ к серверу и уж потом к этой базе.
Для этого вам нужно будет для начала организовать программный туннель и уже через него выполнить подключение к базе MySql, ну а дальше все как обычно в sql. (если конечно MySql у них смотрит на ружу - что вобщем то полный п...ц, то все что я написал не имеет смысла).
По опыту реализации такой хрени, в моем случае камнем преткновения стал туннель, т.е. когда проект был готов и данные ходили без проблем в обе стороны, разработчик сайта одумался таки и сказал, что такая работа с базой это лишняя дыра в системе (и он прав), поэтому опять вернулись к xml.

P.S. Способы организации туннеля и подключение таким образом к MySql хорошо описаны в сети.

+(279) Минусы такой схемы, как мне кажется, еще в том, что в случае проблем с каналом (например возросла нагрузка на канал и скорость передачи резко упала) во время прямой записи  при "правильной" работе с базой сайта - он просто умрет (не тормозить будет, а просто умрет) - если заблокируется нужная таблица. Хотя тут точнее скажут спецы по MySql.

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

мало того, кому то это даже больше нравится и "удобнее"

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

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

(282) трахать мертвую обезъяну проще чем живую бабу.. обезъяна лежит себе и лежит.. не надо ее кормить, подарки дарить и прочие знаки внимания оказывать...

(282) а вообще объяснения просты:
берем пример -битрикс.. крупнейший вебразработчик в РФ - его порталы всюду, обмены со всеми 1С...  и что характерно - никаких "прямых записей в базу"

(284) А кстати, вопрос к тем кто "плавал с Битриксом".
Как там обстоят дела с загрузкой "over 9K" позиций номенклатуры, зависанием при этом сервера на 2 часа? Неужели там таки создали "сферического коня в вакууме"?

(283) а-ха-ха! хороший бизнес-кейс.
(285) Похоже. Грузить 1 позицию в 1 секунду, это надо постараться.
Скорость должна быть на порядок выше как минимум.

(286) Если используется транзакция (и одна, а не несколько), то загрузка тысячи позиций становится в разы медленнее, чем загрузка тысячу раз по одной позиции, так как кончается память и нужно внутри SQL-сервера создавать место для хранения данных транзакции.
И xml-тут виноват только тем, что некоторые "умные" люди укладывают все загружаемые объекты в один (типа в начале <прайс data="Сегодня"> потом куча элементов, а в конце </прайс>) и без подъёма всего файла в память его очень сложно прочитать.
Собственно, с прямой записью и одной транзакцией будет ничуть не лучше (выкинем только время чтения xml-файла), а висеть всё будет точно также.
Если же спросить у сервера "что у тебя есть", то есть прочитать старый прайс (а чтение может идти параллельно с работой сайта), сравнить его с новым, а затем выгрузить только изменения, то ничего не повиснет. В случае xml-большой файл с сервера в 1С и обратно маленький - тоже должно работать.

(287) Ну вот где ты раньше был ;) Хотя конечно - это только слова, и что бы мне доказать визави свою правоту используя этот аргумент - мне понадобилось бы поднять сервак и изобразить оба метода...
Что слишком дорого ... разве только где найти рабочий демо-пример на котором можно показать что скорости одинаковые.

Лично я придерживаюсь мнения что все сказки с МЕГА-тормозами при парсинге XML - это все связано с расстоянием между тем местом откуда руки растут и ж@пой у исполнителя ...

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

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

Ибо мне вообще не хочется оказаться в ситуации при которой я через время вынужден буду сказать заказчику сакраментальную фразу "А я же Вам говорил!!"

XML - это универсальное средство.
любой универсализм - это определенное "зло".
.
специфическая разработка - всегда будет быстрее универсальной. но за это надо "ПЛАТИТЬ".

Ну чем у Вас закончилось?

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

(289) готов поспорить

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

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

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

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

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

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

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

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

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

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

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

Собственно, мой внутренний религиозный протест против прямой записи в базу сайта, вызван скорее нежеланием писать инструмент который можно использовать только один раз...
(можно конечно написать такой ИНСТРУМЕНТ - который будет сам подстраиваться под структуры разных баз, а то может даже такой уже и написан)

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

Вот ....

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

(0) не читал выше

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

пожалуй так

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

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

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

а можно и тупо захардкодить. это вообще на пару дней дела. на то оно и тупо.

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

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

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

А с другой - это же все только слухи.... и другой работы порядочно.

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

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

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

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

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

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

далее вам решать конечно.

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

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

(304) Я то могу изобразить... но кто будет изображить ВебСервисы со стороные сервера

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

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