Обмен в формате XML, DBF, TXT? #579177

Кто что думает про обмен в сабжевых форматах. Что лучше? Когда работал с торговым борудование - все кассы лупили в ТХТ формат все выгрузки загрузки - всегда легко было проанализировать файл выгрузки. Понять в чем беда.  С ХМЛ уже так не прокатит - но там более удобная програмная навигация. ДБФ - это Таблицы - тоже без пролем - но свои камни. Кто что предпочитает - оценивая с высоты приобретенного опыта? Плюсы и минусы данных форматов.

Кто что думает про обмен в сабжевых форматах. Что лучше? Когда работал с торговым борудование - все кассы лупили в ТХТ формат все выгрузки загрузки - всегда легко было проанализировать файл выгрузки. Понять в чем беда.  С ХМЛ уже так не прокатит - но там более удобная програмная навигация. ДБФ - это Таблицы - тоже без пролем - но свои камни. Кто что предпочитает - оценивая с высоты приобретенного опыта? Плюсы и минусы данных форматов.

Кто что думает про обмен в сабжевых форматах. Что лучше? Когда работал с торговым борудование - все кассы лупили в ТХТ формат все выгрузки загрузки - всегда легко было проанализировать файл выгрузки. Понять в чем беда.  С ХМЛ уже так не прокатит - но там более удобная програмная навигация. ДБФ - это Таблицы - тоже без пролем - но свои камни. Кто что предпочитает - оценивая с высоты приобретенного опыта? Плюсы и минусы данных форматов.

У самого опыта в вопросах обмена нет большого - но все что делал - делал через тхт. Работает хорошо и стабильно. Файлы сам могу почитать - проверить. Обмен сотрудниками поднял щас между 77 и 81. Выгрузка загрузка проводок из БП в УПП для сводного анализа. Репорты о работе роботов по архивированию.

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

Абстрактно говорить неверно. Всё зависит от конкретной задачи.

Надеюсь тему закроют. А то сейчас как проснутся...

Задача №1 - Перенести справочники Задача №2 - Перенести документы Задача №3 - Перенести данные из регистров.

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

XML попросту не умею пользоваться)

хмл удобнее если объемы данных большие ... и надо передавать связанные таблицы ... например документы

"хмл удобнее если объемы данных большие" О_о...

Как раз сейчас занимаюсь подобной проблемой - переношу справочники из 7.7 в 8.2. Выбрал формат DBF. TXT - простой и быстрый, но плохочитабельный, если требуется переносить много реквизитов. Кроме того, в программировании он более сложный - требуется отлавливать разделители реквизитов и выгрызать сами реквизиты. Формат XML - самый универсальный, там можно что угодно передать. Но я для своих задач выбрал все же DBF: более наглядно, чем XML (при зрительном просмотре).

мотивируй?

Я вот хочу выучить хмл - он универсальный, и везде его продвигают. Но тхт милее...

А почему тхт милее? Там же дополнительно с разделителями надо возиться. А ДБФ - это готовая таблица значений)

наверное уже привычка

Вот от txt мне уже только от воспоминаний страшно становится. Как в наименованиях оказывались точка с запятой и как я их потом целыми днями вылавливал. бррр ни за что не вернусь в txt

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

Для обмена большого объема информацией,то DBF... Если маленького, то XML или TXT :)

Попробуй через XML передать ~1Гб информации :) Тебя удивит ;)

А почему нельзя 50 справочников передать? Делаешь колнку с именем справочника, так и различаешь их при загрузке - по имени колонки.

Без разницы. Но у XML есть плюс - можно составить схему и проверить (validation) по схеме до загрузки. А так - хоть через табличку в SQL :)

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

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

самый быстрый

на маленьком объёме довольно быстр

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

Вы чо? тхт самый компактный и быстрый. А вот от скунка я не ожидал

а посчитать не пробовал ... передай 1 документ с заполнеными 100 строками табличной части и 10 реквизитами в шапке ... через тхт, дбф и хмл

При обмене между базами предпочитаю напрямую подключаться куда надо по ole и писать куда чего надо...

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

хмл идёт в размере 1 к 10 от исходных данных...

чего? ...

удивлён?

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

ты не поверишь... Я считал...

не поверю ...

твоё право.

Ну вообщето от конкретных данных зависит , в целом XML покомпактней DBF-а

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

вот кусок хмл-а: <Doc Name="Реализация" ДатаДок="20070103" НомерДок="210"> <Ref Name="ВремяДок">11:09:28</Ref> <Ref Name="Контрагент">51</Ref> <Ref Name="РНН">            </Ref> <Ref Name="СуммаВсего">0</Ref> </Doc> тот же кусок в тхт: Реализация;20070103;210;11:09:28;51;;0

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

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

Опередил :)

Веб-сервисы )))

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

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

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

только в пример сделай для передачи реализации в кторой прошло 100 единиц товара ...

>>> в целом XML покомпактней DBF-а О_о... ХМЛ по определению не может быть компактным.

о!  фсем чмоке в этам чати...

Давай, отожги!

не, я тут читателем... :) обещает быть очень позновательным.

"хмл для гламурных кисунов"))

Может. Если саксимальная длина поля, скажем, 200, а средняя заполняемость - 10, то дбф будет расходовать (в пределе, без учета заголовка) 200*n, а  xml n*(2*длинаИмениТега+5+10). Вообще, спор бессмысленен. Любым форматом можно передать любые данные. и объем - не самое важное.

...для гламурных скунсов...

Использование современных алгоритмов сжатие нивелирует разницу в размерах , особенно если safety используется . В TXT самому придется подобие тегов реализовывать Если DBF задан максимальная величина ячейки скажем в 200 символов , то не важно сколько символов туда заносится 10 ,30 или 199 , пишется и передается все равно 200

xml жрет всю доступную память dbf валятся индексы txt выбор мастеров

Ты прямо сжатый xml обрабатываешь? :-)

По старой привычке, еще с 7.7 пользуюсь чаще для простых переносов DBF.

А для сложных XML

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

+ кароче, вот

Если системно, то я за современный секс!

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

ну а теперь тхт для того-же самого

замени все теги на ";" и будет тебе тхт

будет csv

замени

лениво. Но, поверь, тхт будет меньше

По ходу я писал онлайн синхронизацию между двумя разными базами (некий аналог КД) на хмл. Так что немного представляю, что говорю.

Когда переносится нормализованная база из десятка связанных таблиц не проканает такая замена , информацию о структуре надо хранить то же . Скорее всего даже и при таких услових TXT будет немного меньше XML , толко затрахаешся с ним работать

И меньше будет намного, и работать не сложнее (если не хранить все в одном файле), и быстрее. Но менее универсально. Тем более, если база нормализованная.

Что то в этом роде делал. Вполне себе работало без проблем. (Выгрузка была не из 1С, загружалось в 1С). Работало. Попадающиеся разделители и символы перевода строки экранировал. DBF только для узкого круга задачь

У меня одна из версий дистр отчетности может выгружаться в трех форматах , сейчас выгружу посмотрю , 11 связанных таблиц с высокоим уровнем нормализации , присем сначала был TXT , и пришлось реализовывать в нем , потом партнеры добавили XML , а потом DBF , так как предпочитаю DBF , реализовал у себя все форматы последовательно

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

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

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

Если проект горит то бери то, что лучше знаешь. Если будешь, разбиратся, самообучатся, вникать то XML, или DBF. XML перспективней.

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

"Все равно"- это значит по понедельникам, средам и пятницам ТХТ, по вторникам и четвергам XML, в субботу DBF, а в воскресенье разбираться в этом зоопарке.

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

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

К моему посту TXT 1 файл 5.5 мбт общее время выгрузки 179 сек XML 1 файл    12 мбт  общее время выгрузки 124 сек DBF 11 файлов 35 мбт  общее время выгрузки 119 сек Время запроса к базе данных  везде одинаковое , 105 секунд

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

у тебя это хмл ...

ИМХО , при переносе сложных реляционных данных DBF самый быстрый , самый простой в реализации , и самый большой по объему XML самый средний :) , самый универсальный TXT самый компактный , самый медленный , самый геморройный в реализации

У меня есть тема годичной давности так что поверь, сынок, мало уже что нибудь такое меня удивит

ТХТ и ДБФ - это старо и неактуально. Для любителей ДБФ вопрос: сколько колонок у вас в будет в файле, если надо передать начисление зряплаты, вместе с сотрудниками, адресами и пр.?

Ровно столько же.

Используй атрибуты. Будет немного меньше размер и быстрее

Хотя и похоже, но это не так. Здесь нет дублирования названий атрибутов в каждой записи.

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

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

каждый метод имеет как плюсы так и минусы. Для переноса простых данных - лучше тхт нет ничего. Если при загрузке идет загрузка не потоком, а с поиском по файлу с данными - то берем дбф с индексами. Ну а для универсальных переносов или сложных по структуре - лучше xml Опрос в без конкретной задачи - просто вброс

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

как всегда самый умный ответ ...

Чего столько-же Василий Иванович? В ХМЛ не будет этих колонок, в ТХТ то-же может не быть!

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