Кто что думает про обмен в сабжевых форматах.
Что лучше?

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

(111) Там идет отдельный блок по клиентской базе , в общем теле файла

(110) > (88)

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

CSV тот же эксель только работать с ним удобнее
Когда нужна скорость лучше DBF

голосовалка абстрактная, все зависит от конкретной ситуации. В принципе даже обмен между 2мя 1с-ными базами и 1с и какой-то другой программой - это вообще 2 разных разговора. И автор забыл вариант OLE.
Но вообще лично у меня большинство обменов в xml

Не видел я ещё ни одного нормального обмена через ДБФ. Последним смотрел выгрузку от Альфа-Авто из 7ки в 8ку, руки отрывать надо за такое!

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

(118) Небоь, франчи писали....

(116) csv и txt - одно и тоже. Разница лишь в том, что какая-то стороння программа (ексель) открывает файл с расширением csv по двойному клику в проводнике, а с расширением txt через файл-открыть
:)

(121)это не разница ... экулировать эксель на расширение тхт как два пальца в туалете обгадить

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

(121) разница в том, что в csv - опеределен разделитель.
в тексте - может быть и без разделителя (регулярная структура), может быть с разделителями - получаем csv, можем в качестве разделителя применить "<>" с именем поля - получаем "почти" xml.

(120) Есс-но :)

(123) Угу , в TXT , геморрой растет согласно квадрату усложнения структуры данных

(125) Ну так что ж ты хочешь... они по определению - "такие"...
(126) каждому овощу - свое время.

Итого зависит от специфики задачи.
Если поддерживается регистрация изменений - XML
Если нужна компактность и скорость - txt
Если идет синхронизация баз без регистрации изменений (например номенклатуры в несвязанных базах или классификаторы) - ДБФ или SqlLite

(124) разделитель то может и определен, но я еще ни разу не встречал csv, который полностью соотвествует RFC

более практичный

Интересно как любители DBF и TXT передадуть какую-нибуть мелочь типа изображения....
Ведомы ли любителям TXT и DBF высокоуровневые методы работы с XML данными, ну например такие банальные весчи как сериализация?

Итого -> учим XML!

(131)Мне не ведомы. Увы.
Да и на кой ляд картинки передавать?
Картитнки пусть дети рисуют на асфальте мелом )

(131)Только не надо рассказывать про картинки товаров, контрагентов и прочее. Сам знаю)

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

(131) точно так же, как и в xml.

(131) В DBF можно через MEMO что угодно перекинуть

(137) Тс-с-с-с....

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

(131)
Ндя...
wiki:XML
>>XML — Текстовый формат, предназначенный для хранения структурированных данных

(140) чего ндя?

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

"Все талантливые люди талантливы по своему. Но почему-то все тупые тупят одинаково..."©

XML...

вопрос достаточно неоднозначный. ХМЛ позволяет представлять данные в объектной модели, что в свою очередь несет определенные накладные расходы на описание объектов. Исходя из этого ХМЛ целесообразно применять в сравнительно небольших объемах переносимых данных. С большими объемами данных становится вопрос в выборе парсера. На текущий момент самые очевидные, это DOM и SAX. В первом случае все данные файла грузятся в память и там парсируются во втором случае файл читается последовательно. В память загружается только структура. Если сравнивать размеры выходного файла, то XML самый большой. Но существует формат PacketXML, что позволяет уменьшить объемы.

Что применять? Ответить на этот вопрос можно только в рамках конкретной задачи.

(141)
ТЕКСТОВЫЙ формат

(142) элементарно это как?

OLE, OLE, OLE ...

(145) и чо?

(147) касательно снеговика оле идет в сад

(146) Например четвертая нормальная форма

(150) ты его убил!

(150) круть! И таким  образом интересно будет выглядеть перегрузка видов так с 30 документов. Целая клевая БД на 4 НФ(которая кстати и тормозить при зазборе нехило будет, в плане производительности красивые НФ непрактичны, не?)

1. OLE, OLE, OLE ..
2. Но по привычке текс
3. дбф давно пробовал все класс но возня с интексами парит
4. А воще хмл это стантарт!

Я кстати не отрицаю преимуществ XML для определенных задач , и достаточно широко его использую . Точно так же для определенных задач , а именно обмена между реляционными базами DBF хорош . А 1С худо бедно работает на реляционной модели.
(152) Как раз не , и в плане производительности кроют XML , как тузик грелку

(152)
v8: Получение данных из большой таблицы ~6.2 млн. записей
Чел типа решил без нормализации обойтись и что из этого получилось :)

(155) а я и не говорил что нормализация не нужна.  В приведенной Вами ветке мелькало также и волшебное слово "денормализация". Кстати, какие одноэсные конфы соответствуют требованиям 4 НФ, не подскажете?

(156) А причем тут конфы ?

(157) производительность. Мы же на форму 1с-негов, поэтому про 1сные конфы и вопрос. Ты утверждаешь что БД на ДБФ да еще в 4НФ будет шустрее чем один хмл. Вот в это мне как то крайне слабо верится.

(158) Вера , понятие не имеющие никакого отношения к объективной реальности.
Естественно реляционная модель будет на порядки быстрее , что то не встречал ни одной серьезной учетной системы которая в качестве ОСНОВНОГО хранилища данных использовала бы XML .

Вообще то план счетов это , практически стандартная  4NF ,подчиненный справочник 2NF, документ с табличной частью BCNF , люьбй регистр учета это использование нормальных форм в том или ином виде .

(159) А никто и не говорит про основное хранилище учетной системы. Мы ща про обмен. И я утверждаю что 4 НФ встает раком даже на СУБД, в условиях файловой системы - она будет вставать раком вдвойне. И из-за этого в реале 3 НФ - это максимум.

(160) "Это у вас с руками что-то"©

(160)
Сначала ты утверждал что в DBF картинки нельзя перенести - очень даже можно
Потом ты утверждал что нельзя перенести произвольное количество картинок привязанных к объекту - легко
Утверждай дальше :))
XML медленнее хотя бы потому что его необходимо парсить , при его обработке выше накладные расходы , если требуется нелинейная обработка его эффективность вообще снижается

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

за XML. движемся с прогрессом.

(162) если "легко" это плодить новые таблицы на каждую необязательную сущьность - тогда да.

(164) Почитай про нормальные формы . Достаточно одной дополнительной таблицы , для хранения всех необязательных сущностей

(165) которая будет вставать раком еще быстрее чем более она будет универсальна.

Не будет

Есть такая штука как индекс GUID

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

(161) ну так какие конфы используют 4 НФ?

За XML

(169) Ну напрактике у TXT наверное может , и именно за счет стандартизции , а также из за возможности работать через стандартные библы , которые могуть быть весьма эффективны .
Но DBF-у по скорости XML точно сольет
На линейной выборке проигрыш будет менее значительным.
(170) Любая конфа использующая план счетов

(169) дуррак ты! Вон, вован чётко знает - если букафки "txt", то текст, а если "xml", то XML... :-) Его не обманешь!

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

(173) Это фигня , он точно знает что нормализованная реляционная база , с построенными индексами , встанет раком по скорости обработки ,по сравнению со структурированным текстом

(173) Эт фигня, вот скунки, похоже, считает, что если с тегами, то это сразу XML ....

(175) Ну, писали же учет на справочниках...
(175) Номер главы - это тег? тег! Отступ (красная строка) - тег - тег!!!!
Ай да Пушкин, ай да сукин сын - на XMLе стихи писал!!!

(174) Ну я типа написал "на практике" , в теории по скорости что TXT что XML суть одна , но например парсить TXT при загрузке придется средствами 1С , а это медленнее чем с использованием спец библиотек . Да и эффективность кода будет далеко не идеальной , я например не специалзируюсь в написании парсеров :)

(178) а разбирать дбф следствами 1С еще веселее, не правда ли?

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

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

(179) А ты, наверное, уверен, что XBase -- это единственный способ "разбора" DBF средствами 1С? ;-)

(179) а зачем dbf "разбирать"????? Да еще "средствами 1с"????

(181) а какие есть еще?

(182) чувак, ты самы умный - успокойся уже...

(179) Наверное не слышал про XBase
(180) В целом согласен , но например обмен на "сторону" , под каждый текстовик ВК не напишешь

(185) Ну дык никто не отрицает, что универсальность -- это преимущество. Но это отдельное преимущество и с эффективностью оно, как правило, обратно коррелирует.

(183)
от ADO, FoxPro ... до текстового редактора

(184)ну еще есть ado ... а на майка внимания не обращай ...

кстати насчет мемо полей - их то как -то Х-Base не поддерживает, не? Так что пролетает X-Base c рисунками? И че ето про такую мелочь только я упомянул?.
(187) если речь пошла про сторониие компоненты, то не проще ли уже напрямую к базе источнику дергаться?

на пустом месте такой спор развели.

Если небольшой объем данных, то средствами 1с наше все

Если большой объем данных, то тут уже ДБФ, ибо текст кривенько как-то пишется - по крайней мере в 7ке.

Ну если сложную структуру, да и универсальную, то проще

нО в некоторых случаях только ОЛЕ спасет

(192) смею предположить что с распределенными БД вы никогда не работали...

(189) Расширитель в виде ВК , доступен с 2006 года , если есть необходимость картики гонять.

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

(197) не встает. У меня это амно в распределенной БД гонялось.

(198) А размер картинок какой ? Сколько картинок ? Какой размер файла с картинками и без картинок ?

2*100

3000 картинок предположим по 1 мп , это примерно 600 мбт .
Впехивать это в файл (не важно в XML через base64 или в MEMO )просто изврат , имхо , необходимо пересылать билиотеку картинок в папке с файлами , а в структурированных данных хранить только ссылки

Не стоит это делать в ТХТ, остальное в зависимости от задачи.

(201) смешнее другое.
Что в тексте, что в иксэмэле картинка будет в виде бэйз64.
Почему "в иксэмэле" "она пройдет спокойно", а в тексте - "всё встанет"? :-) волшебная сила угловых скобочек?

(203) У нас в распределенке , просто папочка с картинками через FTP синхронизируется , как то не додумались 15 000 картинок в файлы обмена запихивать

гы... у меня программные модули хранятся в базе данных :)

(205) Имеет смысл  в ряде случаев , у меня то же :)

А вот как интересно как Vovan1975 в распределенке с переносом картинок прямо в XML файле решает вопрос синхронизации справочников , например номенклатуры с картинкам тысяч на дсять позиций . Постоянно эти картинки гоняет в переферийную базу ? Или только на новые ? Или отслеживает статус модифицированности элемента ? Элемент может быть модифицирован например по ценам , а картинка старая , отдельный статус на картинку имеет ?
Чето как то сложно все получается .
Без подкола , просто интересно , я в свое время извращатся не стал , и храню только ссылку на внешнюю картинку , синхронизация базы отдельно , картинки отдельно , обмен независимо друг от друга идет

Лучше  использовать однофалвые локальные базы,что бы было проще передавать.Так или иаче даные структурировани и  XML при этом сильно избыточен ине оптимален, т.к. к базе можно индексы прикрутить для оптимального поиска

ю

(207) Я не вован, но если конфига настраивается на обмен, то картинка выноситься в отдельный, как правило подчиненный, справочник. Далее отслеживается модифицированность обоих справочников по отдельности

(210) Ivan Bezdomnyi?

Универсальный.