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

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

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

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

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

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

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

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

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

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

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

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

(9)мотивируй?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

(30)чего? ...

(31) удивлён?

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

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

(34)не поверю ...

(35) твоё право.

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

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

не поверить ... твое право

(38) вот кусок хмл-а:

<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

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

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

(40) Опередил :)

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

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

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

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

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

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

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

(49) Давай, отожги!

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

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

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

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

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

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

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

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

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

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

(58)+ кароче, вот http://zalil.ru/32028315

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

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

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

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

будет csv

(66)замени

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

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

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

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

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

<Справочник: Сотрудники>
<Реквизиты:ИД;Код;ЭтоГруппа;Наименование;ДатаРождения>
23560-099990-58466-56565;10;0;Сидоров;01.10.1980
...
<ТабличнаяЧасть: ТабличнаяЧасть1>
<Реквизиты:р1;р2>
...
<КонецТабличнойЧасти>
<КонецСправочника>
<Справочник: Сотрудники>
...
<Конец>



DBF только для узкого круга задачь

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

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

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

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

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

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

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

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

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

К моему посту (74)

TXT 1 файл 5.5 мбт общее время выгрузки 179 сек
XML 1 файл    12 мбт  общее время выгрузки 124 сек
DBF 11 файлов 35 мбт  общее время выгрузки 119 сек

Время запроса к базе данных  везде одинаковое , 105 секунд

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

(73)у тебя это хмл ...

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

(18) У меня есть тема годичной давности v8: Чем работать с большими xml так что поверь, сынок, мало уже что нибудь такое меня удивит

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

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

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

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

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

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

каждый метод имеет как плюсы так и минусы.

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

Опрос в (0) без конкретной задачи - просто вброс

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

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

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

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

А XML можно как то индексировать ?

(99) А зачем индексация при обмене?

(97) в xml колонки эмулируются, в тексте - подразумеваются.
Я так понимаю, что слово нормализация вам не знакомо...

+(83) Размер архива кстати у всех форматов практически одинаковый , около 900 кбт

Все побежал, и я побежал...(с)

(101) Нормализация это не модно :)) , зачем , можно сотню тэгов прописать :)

(100)
Если брать более широко - не только обмен,
когда требуется не только последовательное считывание.

Помнится скл лайт для таких задач продвигали

(102) у тебя текстовик явно денормализованный.

(101) Сколько у тебя табличек в обмене? И кто-то тут говорил про удобочитаемость...

(99) да 9/10 не имеет никакого представления об индексах...
вон, только вчера тема была...

(106) Чуть чуть нормализованный , и не у меня :), строго в соответсвии с требованиями партнера :)

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

(109) "чуть-чуть беременных" не бывает...

(108)
Не могу найти - ссылка есть ?

(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?

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