Архитектурный вопрос - где и как хранить мои данные

[vitasw]

Если 1 проводка=1 документ сделка. То никак.
А если в одном документе много проводок, так определяйте курс за пределами цикла. Или запросом все вытаскивайте зараз.

[Максипес]

Если 1 проводка=1 документ сделка. То никак.

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

[Kironten]

Если 1 проводка=1 документ сделка. То никак.

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

Ну если не документ, и хочется отметки, можно поюзать активность записей.

[Максипес]

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

или допустим разбить это мероприятие (проведение сделок) на два этапа.

1. рассчитать день.
2. сформировать документ по итогам дня.
2. провести этот документ.

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

тоже интересует вопрос насколько это стандартное решение. хочется сразу освоить правильные способы работы с 1с.

[vitasw]

но образуется лишняя группа данных

Об чем речь?

[Максипес]

но образуется лишняя группа данных

Об чем речь?

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

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

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

[Максипес]

Люди добрые, еще вопрос.. как мне из обработчика

Код Выделить Развернуть

Процедура ОбработкаПроведения(Отказ, Режим)
    // здесь нужны данные
КонецПроцедуры
как правильней получать данные из периодических регистров сведений.. запросом или методами? Приложение управляемое.

[vitasw]

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

То что вы хотите оптимизировать - это похвально. Нужно только правильно оптимизировать.
Смотрим только на 1С. Вы откуда-то перегружаете "мильёны" документов, которые не осуществляют движений. (!!!Но они есть в базе). На основании этих мильёнов вы планируете создавать какой-то итоговый документ, который и будет осуществлять движения по регистрам. Если речь идет о том что каждое движение соответствует исходному документу из "мильёны" - то сами понимаете, никакой оптимизации нет. Если движения - это итоговые данные, то с точки движения регистров - да, оптимизация будет. Остается вопрос, что делать с начальными "мильёнами" и зачем они нужны вообще в базе? Служить основанием для движений - так расчет можно и на лету произвести и создавать в момент загрузки сразу итоговый документ без загрузки начальных "мильёнов". В этом случае получите компактную файловую базу. В противном случае эти ваши "мильёны" потребуют перевода на клиент-серверный вариант в уже очень скором времени. 

[Максипес]

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

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

[vitasw]

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