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

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

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

(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 на раз два реализуется вебпрогерами. они просто не хотят делать свою часть работы и пытаются скинуть на тебя