Добрый день.
Возник вопрос, какой формат обмена данными лучше использовать для связи 1С8 c другим приложением. Интересует мнение участников форума с аргументацией.

Я отдаю предпочтение xml.

у xml однозначно возможностей больше...

ХМЛ конечно лучше, но ДБФ всё же попроще в реализации...

xml - универсально, удобно, мощно.

DBF быстрей для маленьких задач, XML более функционален что-ли

(0) Хороший вопрос. Я давно пытаюсь вычснить что лучше. Наверное для каждой ситуации своё решение - или dbf или xml

XML

(2) Если не сложно, опишите, какие возможности есть в xml, каких нет в dbf.

(8) совершенно разные весчи

(9) Вещи то разные, а задачи решают одинаковые

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

(10) здрасте... даже в 1с это неверно...
бред

(11) Еще объем важен - XML место жрет много...

(13) объем сильно не важен так как все будет куртится на одной машине.

(12) ну да, одинаковые задачи решают...по-разному..что не так? может действительно не понимаю?

(14) крутится

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

Обычно "другое приложение" крутится под какой либо СУБД . Если есть возможность прямого доступа (по сетке видно) то ADO рулит.

(17) Да хоть текст с разделителями...

(18) Боюсь прямой доступ не предоставят.

(20) А вот боятся не надо. А перспективы "гонять текстового посредника и копаться в нем" ..... была тута ветка с Гестори. :)

(21) Просто обмен должен быть в обоих направлениях. И сторонний разработчик не предоставит доступ на запись.

(22) Ну если они могут XML и нет желания возиться с множеством таблиц - нехай будет XML...

(21) Если можно ссылку на эту ветку.

(22) Ну тогда со сторонним разработчиком колдуйте над XML.

(23) Пока не известно что им легче. Предстоит обсуждение.

(26) Ну тогда от нас чего надо? С ними сначала обсасывать надо...

А еще такой вопрос. В каком формате легче реализовать синхронизацию и возможность разрешения коллизий?

(28) Причем тут формат? Это проблемы программиста.

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

(29)Просто я так предполагаю мы можем попросить их реализовывать обмен в том формате в котором делает это 1С при помощи xml, используя планы обмена, и как или я не прав.

(31) ИМХО В чистом виде сериализация вряд ли получится... Дело в том что 1С региализует реквизиты не примитивных типов в виде ссылок из внутр. ID объектов. Т.е. примерный вид XML сериализации документа:

>Дата -> 00010101
>Номер -> 000001
>Контрагент -> dfdf-edsdf-435s

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

Вторая сторона в таком виде врядли предоставить эти данные сможет... А идея связать с планами обмена - хорошая.

(+32) Т.е. ЗаписатьXML(Документ.Ссылка) в чистом виде не прокатит.

(33) Ну это понятно.
А прокатит ли такой аргумент: при увеличении числа таблиц и взаимосвязи между ними xml будет проще преобразовать?

делал на xml, а че, бывает dbf? че за способ обмена такой? восьмерка сериализирует объекты в xml, так что однозначно...

ВК-бухгалтер рулит!

(34) ИМХО в принципе - да. Тебе из XML никуда лезть не надо. В dbf придется всё разворачивать в один плоский файл или "метаться" по нескольким файлам.

РЕАЛЬНЫЙ минус xml - меееедленная работа

(38) зависит от парсера + неизбежная плата...

(18) +1

(39) Парсер SAX.

Смотря для чего. При достаточно больших объемах поиски всякие по XML тормозят, зото:
1) возможны вложенные таблицы
2) нету тупой заморочки с длинной имени
3) xml весит меньше (это мое субъективное мнение основанное на опыте создания ПО МОЕМУ МНЕНИЮ аналогичных файлов выгрузок)
4) xml можно просмотреть НА ЛЮБОЙ машине при помощи майкрософт интернет испортила, а для ДБФ нужно программульку иметь (эксель не роляет - он только первые 1024 записи грузит)
5) XML-ки легче масштабировать - дополнительные поля вносишь именно там, где они нужны

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

(42) >>xml можно просмотреть НА ЛЮБОЙ машине при помощи майкрософт интернет испортила

угу... Особенно если он метров 50...

>>нету тупой заморочки с длинной имени

Вот проблема - переименовать.

(43) 50 метровую ДБФку тоже на медленной машине читать запаришься
заморочька есть - имя не может быть длиннее 8 символов, переименовывать не всегда удобно. Чо, например, делать, если в имени файла должен содержаться идентификатор, по которому некая программа должна сообразить, надо загружать ффайл или нет, не открывая его, или еще чего сообразить по имени надо?

+(44) первый и пятый пункты из (42) ДэБэЭФу все равно крыть нечем, а в свете пятого пункта еще и четвертый становится легко доказуемым

(44) >>Чо, например, делать, если в имени файла должен содержаться идентификатор, по которому некая программа должна сообразить, надо загружать ффайл или нет, не открывая его, или еще чего сообразить по имени надо

Не смешите меня... Всё анализируется и работает... Чего делаю не так?

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

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

(45) пункт 5 - это вообще жесть.

>>XML-ки легче масштабировать - дополнительные поля вносишь именно там, где они нужны

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

(49) как думаешь, какой код будет проще поддерживать да и писать:
1) код, обрабатывающий несколько разных файлов
2) код, обрабатывающий один файл

Тут лежит парсер XML который работает с большой скоростью и не тормозит на больших выгрузках (т.к. не ест память).
http://x-romix.narod.ru/

У XML преимущества:
- Длинные/русские имена реквизитов
- Можно выгружать реквизиты неограниченной длины
- Удобно выгружать вложенные структуры данных (например, табличные части документов, многоур. справочники).

(50) Это свойство п. 1. против которого (абстрактно) ничего не имею.

(52) а как там с XPath запросами? Они возможны? В полном объеме или с ограничениями?

(54) А из 1C8 возможны запросы XPath?

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

Вот у меня еще начальник утверждает что dbf более читаем чем xml следовательно легче отлаживать, хотя я с ним не согласен. Как вам такой аргумент?

(57) в корне неправильное мнение

Вообщем я подвел некоторый итог. Может ли кто-нибудь высказаться по некоторым пунктам или добавить что то свое?
XML
1. Универсальность/функциональность.
2. Нет ограничений на длину файлов
3. Длинные/русские имена реквизитов
4. Использование SAX модели следовательно последовательный доступ к документу
5. Возможность преобразования документа с помощью XSLT
6. Поддержка типизации 1C
7. Расширяемость структуры
8. Возможны вложенные таблицы
(удобно для выгрузки табличных частей документов и справочников)
9. Тормозит поиск и вообще на парсере SAX медленная работа.
10. Возможность интеграции с другими системами, т.к. этот формат более популярен.
11.  Возможность использования планов обмена
12. Возможность просмотра на любой машине
13 . Меньший размер файла.
14 . Обрабатываем 1 файл.
15. Возможность выгрузки реквизитов неограниченной длины

DBf
1. Быстрота разработки малых задач в 1С/
2. Ограничение на длину имени файла 8 символов.
3. Английские/короткие имена реквизитов
4. Неважен регистр написания реквизитов.
5. Для просмотра необходима специальная программа

Прямой доступ через ADO

1.Быстрый доступ к другой СУБД.
2.Быстрый доступ из другого приложения к базе 1С8?

хорошо работает с большими данными.

> Быстрота разработки малых задач в 1С/
можно к обоим отнести - малые задачи, они на то и малые

для малых объемов информации dbf, а для больших xml.

(55) При переносе данных между БД это никогда не бывает нужно. Поиск можно производить в самой БД, а XML читать или записывать строго последовательно.

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

.

размеры файлов иногда конечно..впечатляют)

Dbf проще и быстрее напорядок!!! При переносе данных между между 1С-ками неважно какими... Только DBF.
Текст - не катит... нет четкого представления.
xml - не катит... много времени на разработку.
Если нужно быстро - только DBF.

Если вопрос о качестве и возможностях, то однозначно XML!
(66) Я думаю что, не намного больше времени уйдет чем на DBF..

xml - за универсальность .

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

Думаю за сим приговор DBF вынесен.

(65) А ты зипуй, зипуй...

А что, уже нормальный парсер сделали?
Помнится когда xml в моде был - сделал файл большой. Файл получился, а загрузить его - фигушки... Пришлось памяти дотыкать...
Хотя сейчас конечно, с Вистой и офисом 2007 - памяти валом.

Но все равно дбф. Дурные привычки видимо...

(71)Парсер нуно брать от "солнцевских"

(66)В там очень криво зделано обращение к ДБФ, текст рулит, жта круто!

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

Вам не кажется что выбирать надо исходя и конкретной ситуации?

Например чем вам простой текст с разделителями не нравится, естетственно с доступом через ВК для скорости.

лучше пользоваться тем форматом, что понимает твоя "другая программа".

а можно еще раз за XML ?
))

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

2. Нет ограничений на длину файлов
гм... а когда-нибудь проюовали открыть и просмотреть 100-мегабайтный .XML-файл?
ага... проблемка... хотя в теории, при последовательном чтении - огранияений мало..

3. Длинные/русские имена реквизитов
гм.. зависит от парсера как я понимаю.. хотя в 1С вроде какое-то пододие юникода пользуется? (поправьте?) тогда все ок..

4. Использование SAX модели следовательно последовательный доступ к документу
... что мало отличаетсч от работы с dbf...
5. Возможность преобразования документа с помощью XSLT
cм 2.
6. Поддержка типизации 1C
только если вы её вводите/поддерживаете руками. тоже самое что и c dbf.
только если вы не имеете в виду ваш пункт 8.

7. Расширяемость структуры
да. см 1.
8. Возможны вложенные таблицы
(удобно для выгрузки табличных частей документов и справочников)

9. Тормозит поиск и вообще на парсере SAX медленная работа.

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

11.  Возможность использования планов обмена
... гм?!
12. Возможность просмотра на любой машине
... гм? см 2
13 . Меньший размер файла.
неа... далеко не всегда.. имхо...
одна поддержка тегов стоит очень многого..

14 . Обрабатываем 1 файл.
... как заблагорассудится... но из-за поддержки вложенных структур - можно и в 1 файл. но см 2... объем файла и проблемы с этим связанныее.
15. Возможность выгрузки реквизитов неограниченной длины
гм.... скорее да чем нет...

но в общем случае - xml выигрывает... да.. хотя-бы только из-за вложенных структур.

Эк, как народ прибило на такое гуано, как xml. В теории, конечно, все круто.
(69) Ну не надо себя считать, во всем гением. Ролью по оглашению приговора по поводу dbf тебя никто, я думаю, не осчастливит.

Я за XML.
Структурирован, валидация, удобен в использовании

Гы, гени(тали)й1С опять выродил в (69) очередней перл... Учиться в институте надо было...
------------
(0) Что лучше - молоток, кувалда или киянка? Так и тут - для каждой задачи есть оптимальный инструмент. И есть техника

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

(71) Сделали, см. 51. В 8-ке нечто похожее встроено, и над большими файлами не тормозит.

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

(84) О!
http://x-romix.narod.ru/OpenXML.rar
Книга знаний: Чтение и запись текстовых файлов XML средствами 1С:Предприятие 7.7
Где же ты раньше был...

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

dbf - стандарт хранения.
xml - стандарт обмена
По этому при прочих равных для обмена рулит xml, однако в каждом конкретном случае нужно смотреть и думать, универсальных рецептов не бывает.

Если обмен с DOS приложениями - то DBF родной формат для DOS.
Если обмен Windows приложениями - то XML стандрат де факто.

(0) XML, ибо универсально.

Но...  Все зависит от программ, с которыми нужно обмениваться. Даже в наш современный век, когда космические корабли бороздят просторы вселенной, встречаются такие уродские проги, которым не то, что XML, DBF проблематично "скормить". :)

зависит от мышления, кто любит порядок dbf, а если процедуру в две строки тогда xml

Ветку в базу знаний.

универсальнее

плюсы XML: универсальность и многофункиональность
плюсы DBF: проще в реализации, нагляднее результат обмена

До вчерашнего дня работал с DBF, теперь только с XML

xml однозначно удобнее. В связке с XSLT рулит однозначно. У меня на этом обмен построен. Очень удобно писать и читать. Насчет сериализации = договорись со разработчиками что бы они в своих таблицах добавили поле Ид1С куда и будешь писать внутренне представление элементов. Сразу решиться множество проблем.

за xml денег возьмут больше, я так понимаю, они будут выгрузку писать? А ты загрузку за свой оклад?

Если на одном компе и другая система сидит на скуле то однозначно ADO.
Сам так интеграцию наваял. Чтоб не было заморочек с правами, создай промежуточную базу на скуле для обмена.

Можете  не  верить , Но , скорее , к счастью  dbf  , будет  жить  и  работать на  благое  дело . Так что я отдам  голос  за  DBF ! ( 1.)

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

и ДБФ и ХМЛ хороши.

100

для простых задач ДБФ лучше

Экая живучая ветка!
С 22 марта 2007 года!!!

(102) Просто много чудиков тусит среди нас ))

(0) В принципе есть 2 стороны "медали":
1. DBF меньше тратит памяти и его разбор осуществляется быстрее на машинном уровне. Но он не поддерживает модель памяти "дерево": документ с табличной частью. Поэтому в этом месте будет либо перерасход дискового пространства либо небольшой геморроец со связанными таблицами....
2. XML поддерживает деревья. Поэтому без труда можно размещать сложные разнородные структуры в одном документе. Однако XML-парсер работает медленно (по сравнению с DBF).

ИМХО, если объемы небольшие будут получаться, то XML лучше (в Вашем случае).
Я, например, делал перенос учетных данных за год с использованием DBF (XML работал в несколько раз медленнее)

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

Если у приемника основная информация хранится в dbf, то конечно dbf.

Быстрота разработок... Примеров выгрузки данных в ХМЛ в стандартной конфе больше (в дбф - ни нашел ни одной).

если переносить простую структуру данных, то DBF. Однако если есть ссылки на другие объектные структуры - то однозначно xml.
Сам пользуюсь разными форматами. DBF ~ 10%, xml - остальное.

P.S. В 7-ке была интересная функция сохранения данных в файл (в 8-ке не искал), было удобно сохранять таблицы значений и необъектные данные в файл, часто ее юзал, очень удобно было.