Гружу из екселя "классификатор"
похоже висит пока на записи документа в базу
1.5 гига памяти отъел

документ загружается раз в месяц
стоит ли делить его на части?

(0) делить обязательно - за такой документ убивать надо

в 8.1 помнится было ограничение 99999 строк. в 8.2 не уверен...

Макс. номер строки - 99999, ЕМНИП. Что символизирует.

Почему не РС ?

ну и проведение документа - годами будет длиться

[_LineNo3361] [numeric](5, 0) NOT NULL

да, не забудь его провести!

(0) Разрешаю. Потом расскажешь о том, как база раком встала.

блин, т.е. даже 100 000 не влезет

обработка - там есть долговременные операции по обработке исходных данных

т.е. загрузил, сделал сопастовление (1-2 дня) - провел по РС


ок, буду думать

Окончание нумерации строк в табличной части еще ничего не значит.В 7-ке помню после окончания нумерации ничего не мешало добавлять новую строку,просто счетчик строки не наращивается.Как в 8.2 не проверял

(10) че еще "хорошего" посоветуешь?

(6)

там за главного
_KeyField 4 байта.

(0) А можно узнать, что конкретное находится в этих 1 000 000 строках?

и почему нельзя сделать 20 доков по 50000 строк? и так уже хрен документ выверишь...

(9) Что думать? Сделай регистр сведений, тебе же сказали. Неужели ты сам не представляешь последствий такой глупости, как заполнение тч миллионом строк? Для примера закинь в бухне в ручную операцию тысяч 200000 и запиши - результат будет меньшим из зол.

(12) это не отменяет (6)

помнится кто-то проводил эксперимент

прервал загрузку строк в документ на > 3 000 000

По моему если нужен документ в 1 000 000 строк, тогда у кого то не корректно с реализацией хранения и обработкой данных.

(18) с ДНК некорректно скорее

(17) Это не возможно, т.к. максимальное количество строк табличной части в 8 ке у документов и справочников не более 99 999

(19) ммм... скажу мягче: единственный документ, где может быть "много" строк - корректировка регистров (имхо). Остальное...ммм... недостатки методики :)

(20)
ветку искать лень

не вижу техничекого ограничения внутренняя нумерация идет по _KeyField

не помню как нумеровались строчки больше 99999

а как тогда реализовать

справочник полисов мед страхования, - ФИО, дата рождения, номер, серия, дата рождения, место работы, СМО

место работы и СМО надо сопастовлять (в файле - строка, - нужна ссылка на справочник) - 100 и 10 шт, соотвественно

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

процесс вроде кончился - 2 метра в памяти, - но не отвечает теперь

(23) что тебе мешает заполнять периодический регистр сведений, объясни?

(25) перед заполнение нужна ручная обработка

аналог - штатноое расписание - никаких документов, периодичность.

(26) ну и обрабатывай каждую строку, какие проблемы?

у регистра тоже есть менеджер и обработчики.

(23) У вас миллион полисов выдают за месяц?

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

(30) не выдают - а действующих на область

(31) ты КЛДАР вручную обрабатываешь?

(33) млять, какая разница, где обрабатывать?

(32) И вы таким образом обновляете информацию?

+35 По миллиону полисов?
А почему не загружать только изменившиеся?

вопрос в том, как хранить. Хранить лимон записей в документе - тупо и неоптимально.

(0) А что, использовать справочник религия не позволяет? ))))

(37) А им думать не надо. Им грузить надо :)))

допустим чисто РС - появляются поля внафиг не нужные - место работы строкой, и СМО строкой

загрузили - поставили активность - ложь

потом обработкой выбираем не активные записи и далаем сопоставление
а если ошиблись ...  

(36) - это задача номер ДВА - для начала надо первоначальные сведения загрузить

(23) пишешь необработанные записи в один регистр, обработанные в другой. обработал все - из регистра необработанных удалил. или в процессе

(40) Во-первых, от ошибок никто не застрахован. Во-вторых, чем тебе документ в этом случае поможет? не нашел сопоставления - запись деактивировал - все. Ошибочно сопоставить ты можешь и в регистре, и в документе - это сути не изменит.

(41) Да не надо этого делать. Есть понятие активности записи.

(42) в документе я поменял и перепровел
а в регисре что бы поменять надо сначала как -то вычленить эти неправильные записи

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

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

Так и скажи, что ты не знаешь как работать с набором записей.

(47) да там и знать то нечего

(48) к чему написал?

(49) к (47) про наборы записей

+(50) там речь не про тебя, а про ТС

(50) просто так? отметиться?

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

ок
тогда как?

документ оставляем - как факт загрузки классификатора - и к нему же цепляем файл

ТЧ - сопоставление строки со ссылкой

сопоставили - "проводим" документ - грузим напрямую из файла в РС

если ошибка в сопастовлении или еще где - отмена проведения и заново

движения отображаем дин списком

ТЗ выдержит такой объем? (ну что бы визуализировать то что хотим загрузить) или лучше и не заморачиваться с визуализацией?

в движениях документа 1 000 000 - не страшно?

т.е. практически тоже самое что сейчас, но без ТЧ

(54) такой объем не выдержит юзер, даже если выдержит ТЗ
вместо отмены проведения - можно просто напрямую с записями регистра работать. или тебе нравится делать охренительно большие операции с базой? тогда запасай бизнес-гель...

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

(56) что значит напрямую с записями РС?

1. Запретить операцию проведения документа - только запись, ибо в данном случае проведение не требуется логически.
2. Что за сопоставление?

(59) блин, ты я вижу часто грузил номрники ОМС
сопоставление строковых переменных ссылочным из нашей базу нужно передд загрузкой

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

Смысла в документе нет. Кроме того, что можно сделать документ не проведенным и отменить движения регистров.
ТЗ выдержит.))

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

(61) смысл как раз есть - объект для отбора "набора записей" РС - загрузка классификатора как бы каждый месяц и хотелось бы видеть факт присутсвия классификатора актуального

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

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

если набирать или править вручную по 1 с на строку то 1 000 000 / 3600 / 24 = 11,5 суток понадобится. Ишак, который начнет это делать сдохнет раньше чем закончит.

+(62)
У тебя есть исходный файл с данными. Пишешь обработчик, который его парсит. В регистре рисуешь измерения по образу и подобию ФизикСсылка, ФизикСтрока, СМОСсылка, СМОСтрока и т.д.
Если ФизикСсылка при обработке строки файла не Пустая(), значит делаешь запись активной (или ставишь любой другой признак того, что данная запись корректна).

+(67) Поскольку на физика в случае замены или утери полиса будет приходиться уже не одна запись, то регистр нужен периодический, периодичности в 1 день хватит за глаза.

(0) Если этот документ ничего не двигает то почему нет .

+(68) Я имел дело кстати с ОМС. И эта хня реализована в ЗУПе. Не знаю, правда, довели 1С до ума эту подсистему, я ее допиливал сам. И именно на регистрах. Никаких документов.

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

+(70) у меня объемы были поменьше, 600-750 тысяч.

+(71) Почитал. И ваш  пост тоже

"Что думать? Сделай регистр сведений, тебе же сказали. Неужели ты сам не представляешь последствий такой глупости, как заполнение тч миллионом строк? Для примера закинь в бухне в ручную операцию тысяч 200000 и запиши - результат будет меньшим из зол. "  

Ну т.е. вы ставите в один ряд бух. операцию с ее хвостом записи в N число таблиц тоталов и корреспонденций и просто запись двух таблиц документа :)

+(73) Скорее всего чисто ограничение длины поля как в (6)

И примешивать методологическую составляющую тут не нужно. Просто "документ с миллионом" это одно , а "он у меня еще проводится и двигает х...у тучу еще чего то " это другое.

(73) Пример для получения представления о скорости прямой записи в БД. Ты хочешь возразить? Это раз. Ограничение на количество строк в табличной части тебя не волнует? Это два. "Просто "документ с миллионом" это одно , а "он у меня еще проводится и двигает х...у тучу еще чего то " это другое." - я как-то до этого не додумался..

Короче, вся суть в том, что для реализации данной задачи использовать документ с МНОГОСТРОЧНОЙ тч - нецелесообразно. Здесь уместно использовать только справочники и регистры - все. Все остальное будет неоптимальным.

Лет 10 назад участвовал в проекте на 7.7 для телефонной компании (когда на Украине ввели тарификацию городских разговоров). Их оборудование выдавало Эксель-файлы с информацией обо всех звонках за месяц. Нужно было загрузить их в 1С, привязать к абонентам и протарифицировать с учетом вида абонента (физ.лицо/юр.лицо) и льгот (спаренный телефон, инвалид, и т.п.).
В качестве реализации рассматривали и тестировали 3 варианта.
1) Вариант загрузить в 1 документ все звонки по 1 номеру за месяц (как это делали в предыдущем проекте по междугородним звонкам) отпал сразу - слишком много документов, и слишком много ссылок на них (1sjournal, 1scrcdoc, dhYYY, dtYYY).
2) Вариант загрузить в 1 документ все звонки за один день по всем номерам тоже отпал - как раз из-за ограничения на количество строк (9999).
3) Остановились на варианте загрузки в 1 документ всех звонков за один день по "номерной группе" - диапазону номеров с ХХХ-ХХ-00 по ХХХ-ХХ-99.

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

При реализации на 8.2 рассматривали бы вариант 2, хотя отборы по РС могли бы перевесить.

(78) да в любом случае дробить нужно. В твоем случае можно было-бы дробить по часам, например 1 документ = 1час, или по городам, или по первым 3м цифрам.

и искать проще и дополнительная аналитика.

для документов необходимо старатся поддерживать проведение в режиме "сейчас", психика человека реальность воспринимает примерно 5-10сек, значит любой документ дожен проводится не более этого времени. иначе для пользователя начало проведения лежит в "прошлом" и он это воспринимает как "очень долго", реально документов более 1000 строк не должно быть (хотя конечно есть исключения, например "комплектация")

(79) там городов нет - собраны все городские и междугородние звонки абонентов маленькой телефонной компании (порядка 10.000 номеров).
дробить по дням и первым 5 цифрам оказалось самым эффективным (и искать проще потом) - минимум служебных ссылок на документы, база росла менее критично.