Предполжим, что нам необходимо хранить во внешнем файле, например, таблицу значений. Какой формат предпочтительней - текстовый (все делается командами ЗначениеВФайл,ЗначениеИзФайла) или ДБФ? Как они соотносятся по скорости и надежности?

Скорее - здесь работает внутренняя предубеждённость. Я предпочитаю dbf

Мы используем расширение DAT

Для тз лучше ЗначениеВФайл()

(1) Т.е. нет объективных критериев для выбора?
(2) Я тоже. Все равно он по сути текстовый.

(0) Попробуй свернуть (ЗначениеВФайл()) таблицу из 15 колонок и 10000 строк. Увидишь, как там со скоростью. Насчет надежности плохо в обоих вариантах. Отсутствует контроль ссылочной целостности.

(3) Почему?

(6) Быстрее ...

(5) В ДБФ лучше? Какая ссылочность? Вопрос о ТЗ.

(7) Тестил на больших объемах?
(5) Насчет надежности - есть что-то лучше этих вариантов?

(9) Что я больной?

(10) А откуда знаешь?

(11) Чтоб выгрузить тз в ДБФ нужно процедуру строк на 50 написать, а в ТХТ - это одной строкой делается ...
Разве не очевидно, что одну строку написать будет быстрее ...

вы что обкурились все? все прогрессивное человечество давно уже хранит все нужные данные в BLOB-полях СУБД Oracle

(13)+ в формате xml

(12) Это однозначно. Я думал - ты говоришь о том, что быстрее работает.

(14) И чем это лучше?

(16) это круто, модно и современно!

(17) По репликам в других ветках я сделал вывод, что этот формат медленней обоих вышеназванных.

(18) Причем медленней он в обоих наших пониманиях ...

(18,19) это не формат медленый, это компы у вас медленные

(20) Забавно...
(Олл) Т.е. по поводу сравнения скорости и надежности явных преимуществ у какого-то из этих методов видимо нет.

почемуто мне кажется, что Рупор здесь не врет

(22) А когда это Рупор врал?

(22) Если речь только о простоте реализации способа, то я и сам знаю, что не врет. Одним оператором все делается...

а если серьезно, то заковыка кроется во фразе из (9) [Тестил на больших объемах?].
Вот с объемами никто и не разобрался. Ясен перец, что из-за 10 строчковой ТЗ нефиг заморачиваться. А вот если речь идет хотя бы о нескольких тысячах, то я бы вообще поостерегся такое хранить во внешних файлах...

(25) Вот это уже интереснее.

тестил... проблем нет...

хотя понятие больших объем субъективно

Положить её на SQL, только не ввиде ЗначениеСтрВнутр("ТЗ от 1С"), а в нормальном виде, в полях нормальной таблицы...

(23) Идентификатор справочника-владельца. Как узнать? :)~

(27) Какого порядка объемы?
(29) не вариант. Хотелось бы что-то универсальное.

(31) А в чем ты понимаешь универсальность хранения ТЗ?

(32) В данном контексте - не зависящее от СКЛ. Мало у кого из моих клиентов он стоит.

(30) Ишь ты ...
Ну, ладно ..., сознаюсь ...
Врал! ...

(25) Конечно, вариант - хранить инфу в справочнике в составе конфы. Но хотелось бы, чтоб обработка, кот использует эти данные ставилась сбоку от конфы, не требовала вносить изменение в структуру конфы. Тоже из соображений универсальности. Поэтому хотелось если нет проблем с надежностью использовать внешний файл.

Такие "сам себе создаю проблемы" от неверного проектирования...

(36) То есть? В чем ты усмотрел неправильное проектирование? Пока вопрос о том - как надежно и удобно хранить инфу.

(37) для обмена данными юзаю ТЗ или СЗ, состоящий из ТЗ, однако на объеме около 2М (размер результирующего файла) 1С вешается (экспериментально проверял) и уже нифига не выгружает, т.е. если данных много - разбивать на части. посчитал это для себя удобнее, в т.ч. из-за небольшого объема необходимого кода и готовых инструментов для работы с ТЗ во встроенном языке, хотя наверное грамотнее обмениваться данными в dbf(?).
что касается хранения (не просто для обмена данными) - однозначно выбрать сложно, опиши что хранить будем и как это должно использоваться.

(38) Да. Речь об обмене. Т.е. ты делал через ТХТ, и большой объем не прокатывал?

(27) Скунк, какие у тебя объемы прокатывали? Ориентировочно?

(39) файл более 2 метров - уже было критично, плюс были траблы с распаковкой таких файлов обратно в объект ТЗ, если на компе было до 256М памяти (в процессе памяти съедалось до 70 метров, причина мне неясна). для себя выяснил, что передача 300-500 средних доков (мне сложно назвать другие параметры, понимаю, что абстрактное значение пишу) еще работает, больше - нет.

(41) Спасибо, понял. Ценная информация. Т.е. Если хранить накапливающуюся инфу (например, соответствия доков двух баз), то - не вариант.

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

(42) А что мешает самому попробовать?

(43) Понял. Но по идее ДБФ должно пркатить?
(44) Ничто не мешает. На то и форум, чтобы можно было быстрее получить инфу, даже если можно проверить самому.

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

(46) Нет. Речь о том, что стандартные выгрузки находят соответствующие объекты по кодам и номерам доков, что не очень надежно. Вопрос об отслеживании измененности доков я здесь не затрагивал.

А че, XML не учитывается?
Что касается TXT vs DBF, то если много строк, лучше юзать TXT, т.к. под строки в DBF занимается поле фиксированного размера.

В случае выгрузки в ТЗ можно пройтись по колонкам и ЗначениеВСтроку использовать для значения ячеек, а не для всей таблицы, если лень кодер писать.
А ваще значениеВСтроку лучше тока для строк юзать, чтобы переводы строк правильно замочить.

(48) Про ХМЛ немого было в этой ветке. Вроде как медленно работает на больших объемах. А по ТХТ - видишь инсайдер проверял - не прокатывает для больших объемов.

(47) ну пускай по ИДД ищут, я к тому, что зачем это хранить, почему не передавать почаще - не будет с объемами проблемы?
(49) переведи первое предложение, нифига не понял, зачем это.
кстати мы о ЗначениеВФайл() вообще-то

(50) а все-таки, какие объемы будут?

(50) Пока интерес в основном теоретический. Делал выгрузки, заточенные под конкретного клиента. Хотелось сделать что-то более универсальное. Написал вот обработки синхронизации справочников контров и номенклатуры (два варианта - через справочник соответствий и через файл ТХТ). Теперь думаю - как это развивать. Объемы будут зависеть от конкретных баз у клиентов. Но хочется, чтоб работоспособность обработок от этого не страдала.

(53)-> (52)

(53) а... ну тогда ТЗ подойдет не всегда, а сколько будет открыватся большой файл типа "текст" (ну не ТЗ во внутр. формате, а просто текст, с разделителями например) - я не проверял.

(55) Это понятно. Но все рано ТХТ получается не подойдет для накапливаемых данных (неважно - будет это ТЗ или что-то еще)

(56) Юзайт запись текста от v7plus.dll там траблов и ограничений нет

(56) ну да, в общем смысле наверное так.

Хотя для больших данных XML занимает больше места, но в сжатом виде почти то же самое (по объему).
Единственно, для больших данных лучше юзать не парсер от мелкософта, а парсер от мисты или от 1С8 (последовательный разбор, а не разбор в дерево).

(57) А подробнее? Я думал v7plus.dl - компонента для ХМЛ выгрузок.

(59) Не хочу завязываться с ХМЛем. Или ты хочешь сказать, что v7plus.dl позволяет работать с ТХТ и снимает ограничения на него? (не понял)

Вот цитаты из переписки по поводу ежедневного обмена:
Формат файла обмена - txt. Размер ~6Mb
Справочники, Документы, все при помощи ЗначениеВФайл()
Загрузка, в разделеном режиме, идет 5 часов, в монопольном 40 минут.

Админ:
Что странно...память есть нещадно... Во время загрузки.
190 мб...200... Из 256... Винда вообще не рыпается...

Добавили ОЗУ, монопольный режим:

Админ:
За 4 минуты...
Размер ОП - 512
Рзмер файла подкачки 1.5 Гб...использовалось 600 мб
Вобщем вывод простой... Заказываем память...
---------

Хотя там основная нагрузка была при записи, но все же на больших объемах,
да на слабых машиках, ИМХО предпочтительнее использовать дбф.
Тут нужно понять, что дешевле время прога или память.:)

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

(62-63) Все-таки написать 50 строк кода не такая большая проблема. Если это позволит использовать большие объемы без сбоев ИМХО это предпочтительней.

(64)
Это не сбои, все же работает, это - ТОРМОЗА.
:)

(65) у инсайдера не работало (41)
(51) (пропустил этот пост) по ИДД и ищу. Речь об справочнике (или ТЗ) соответствия ИДД в двух базах.

(66) а зачем такой справочник? ИДД же перегружаться будут, т.е. объект созданный в 1-й базе перегрузиться во 2-ю с тем же ИДД, и наоборот, а уникальность я отслеживаю по комбинации ID и код базы, т.е. ИДД состоит из этих двух параметров - все просто вообщем-то.
(65) вот именно, что не работало, на 256М ОЗУ просто вылетала 1С с ошибкой.

(67) Поясни пожалуйста, как ты записываешь ИДД в базу приемник и где при этом хранится код базы.

(68) код базы в константе, тип - справочник с ними, справочник для того, чтобы еще хранить параметры подключения к инет (диалап), параметры почтовых учетных записей и т.п., ИДД пишется при записи объекта однократно и далее не изменяется.
при изменении объекта изменяется его флаг отправки, флаги такие: "отправлять","не отправлять","отправлено, ждем подтверждения" (ну это число ессно), дополнительно хранится номер пакета (чтобы потом при подтверждении флаги поснимать). документы имеют признак, точнее включаются в списки необходимых к отправке, неоходимых к получению и игнорируемых. для тех, которые мы только получаем - автоматом запрещается редактирование, если входит в оба списка сразу или в список отправляемых - значит редактируется, если в список игнорируемых (т.е. не мигрирующих) - флаги и пр. реквизиты не выставляются вовсе.
примерно так.

(69) А разве есть возможность присваивать ИД по своему усмотрению (речь о 7 или 8)? А что делать, если соответствующие объекты создаются параллельно в обоих базах (ведь у них ИД уже сформированы)?

(70) есть ID (он в dbf), есть IDD (конкатенация код базы+ID), IDD не повторятся, т.к. в них фигурирует место создания.
речь о 7.7

(71) А ИДД нигде физически не хранится  (в ДБФ)? ИДД не повторяется - это понятно. Но в базе приемнике ты записываешь ИД в ДБФ при создании элемента? Тогда ИД в приемнике может стать не уникальным?

(72) хранится, это реквизит спр. или общий рекв. док-тов.
никак не может повториться, если для первой базы ИД "1"+9 символов ID, а для второй - "2"+..., т.е. никак они не повторятся.

(73) В смысле, ты создал свой реквизит для хранения ИДД?
Ты записываешь ИД непосредственно в соответствующее поле ДБФ? А как же длина? Если у тебя ИД определенной длины, и в базе 1 он сформирован автоматически, то как добавить к длине ИД еще символ, чтобы отслеживать базы (1 или 2)?

(73) Сейчас убегаю. Если не сильно надоел своими вопросами, хочу потом поднять ветку еще.

(74) ну я же написал, что IDD - это реквизит документа и/или справочника, соотв. 1С его хранит в своих dbf (если это база dbf), длина ID для объекта 1С определенного вида - 9 символов, значит в моем IDD - 10 (1 символ - код базы), за формирование ID отвечае сама 1С, а я лишь беру его и добавляю код базы.
например так:

ИД=СокрЛП(Константа.БД.Код)+MDW.ValueToDBString(ТекущийДокумент());

где MDW - это:

MDW=CreateObject("MetaDataWork");

(объект из 1cpp.dll)

можно из без ВК:

Функция глПолучитьИД(Объект) экспорт
   Перем Стр;
   
   СЗ=СоздатьОбъект("СписокЗначений");
   СЗ.ДобавитьЗначение("",Объект);
   СЗ.ПолучитьЗначение(1,Стр);
         
   Возврат _idtostr(Стр);
КонецФункции


(75) заходи, пообщаемся :)

XML-хороший переносимый формат.
http://x-romix.narod.ru

(0) Чувак, ты реально ленишься! Что мешает тебе написать
Стр=...;
Текст.ДобавитьСтроку(Стр);

или сделать так же с v7.textfie?

На крайняк
Текст.ДобавитьСтроку(Сп.ВСтрокуСРазделителями());

PS Правда я тоже иногда делаю через ТЗ в силу природной лени, но хотя бы отдаю в этом себе отчет =)

А еще можно разбить текстовик на файлы по 1000 строк, например и хранить в каталоге. :)

(70) У 8-ки каждая ссылка - уникальный GUID. :)

Пошли все на хуй

(76) Если я правильно понял, ты добавил собственный реквизит ИДД (в файле 1св7.дд я его не нашел, нашел только ИД длиной 9символов) и написал механизм его заполнения (скорее всего ПриЗаписи, если ввод нового). Но это существенные доработки конфы, которые при обновлении базы придестя поднимать вручную. При первом своем опыте выгрузки я делал такое, даже не используя ИД (просто уникальный реквизит, кот формировал сам). Но ради чего это все? Если мы используем справочник соответствий, то даже если хранить его в составе базы, это не влияет на поднятие конфы. А если во внешнем файле, то доработка конфы не требуется вообще. Кроме того, я так понимаю, что при синхронизации через одинаковые ИД в базе-приемнике надо запретить создание элементов. Они должны только приходить из базы-источника. Это достаточно серьезное ограничение. Вопрос - в чем серьезное преимущество синхронизации через ИДД? Я пока вижу только недостатки.Недавно мы обсуждали это: ID в справочнике Контрагентов Но я так и не понял - ради чего такие ухищрения. Хотя, может, я просто неправильно понял твое объяснение?
(80) Можно. Но не хочется плодить сучности.

(76) Админ не прав... и 1С-ник тоже, текстовик ненада весь грузить...

(84) -> (62)

(83) существенная доработка - да, впрочем можно с помощью сторонних утилит (или свою сбацать "на коленке") и прописать в стандартные процедуры нужные куски. как я уже написал, повторений буть не может и запрещать редактирование не нужно, разве что если речь о одинаковых по сути элементах, но созданных в разных базахи имеющих разные ИДД - тогда да, нужны какие-то правила, например кроме поиска по ИДД еще и поиск по совпадению каких-то параметров и т.п. в моем случае создание элементов справочников было возможно в опрежеленной зоне ответственности (в определенной базе определенным людям) и это ограничение было не только из-за структуры переноса. справочник соответствий - это лишняя таблица, причем по объему (теоретически) будет равна сумме количеств записей во всех спр., док-тах и т.п. - это некислый объем может выйти, все равно соответствия как-то должны проставляться - как представляешь себе этот механизм? (я не говорю, что так нельзя, но выбрал другой вариант, критика принимается)

может еще кто-нить выскажется?

(84) А как, если не весь?
(86) О том и речь, что надо как-то не позволять создавать одинаковые элементы в двух базах, а это существенное ограничение. Справочники соответствий по объему будут равны самим справочникам, соответствия для кот устанавливают. Соответствия для доков по объему - сумма всех доков базы. Обычную работу базы это тормозить не будет , т.к. они используются только в момент выгрузки и не участвуют во всем остальном. Скорость работы - как при обычном НайтиПоРеквезиту.

(86) "как представляешь себе этот механизм?" Кинь мне письмо. Я тебе свои обработки вышлю. Буду рад критике.

(87) если в дополнение к ИДД искать по комбинации (например артикула и наименования или еще как) - то можно и вовсе без справочника соответствий
(88) обработки независимы от конфы?

(89) Это используется у меня в обрабоках. Но полагаться только на это нельзя - не надежно.
Два варианта - один независим, другой зависим.

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

+90 В смысле, в дополнение к ИДД артикул и наименование не нужны, а если только их юзать - ненадежно.

(91) Вышлю оба. Они весят мало. С зависимым от конфы высылаю мд, со справочниками соответствий. Их просто надо скопировать в базу-приемник.

+93 мд тоже веит пустяк.

(93) хорошо, трафик не проблема в принципе, ничего, если сегодня не успею? :)

+95 письмо уже послал, должно уже прийти

(95) Ничего. Просто интересно твое мнение. Щас отправлю.

Отправил.

Обработки запускаются в базе-приемнике, путь указывается к базе-источнику.

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

(100) Не видел. Если у меня тоже заумный - ткни носом. :)
Ладно, я пошел спать. Все равно тебе нужно время - глянуть.

Блин. Кажется, не дошли (вернулись). Щас еще раз попробую

(102) должно дойти...

(101) у него коммерческий, я его тоже не видел :)

(103) Проверь. А то после первой отправки мне вернулось:
A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:

(105) есть два, разного размера

+106 все, там мд-шник еще, понятно

(106) да. это не зависимый от конфы  и зависимый.

Ладно. Я пошел спать. Пока.:)
Как посмотришь - скажи что-нибудь.

(109) договорились :)

(110) Ну как? Еще не смотрел?