ИМХО это порождает много ошибок изза необходимости перепроводить базу, для большой базы перепроводить угрожает большим риском и долго! Ведь запрос SQL может вывести нужные итоги за считанные секунды и по партиям и по себестоимости?

Предложения? Все считать от начала времен?

да я думаю на SQL сервере это разумнее того что мы видим, такие расчеты как в 1С делают для ОЛАП, для больших хранилищ, а для оперативного учета надо SQL по всей базе, ИМХО.

Я правда тестов не проводил, но если я неправ поправьте!

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

А какая связь между временным расчетом и последовательностью с "SQL может вывести нужные итоги за считанные секунды". Чего-то я не догоняю :(

(0) Запрос в SQL который за считанные секунды выдаст любые нужные итоги - в студию :)))

Я сам непонимаю до конца зачем нужно делать временный расчет, но в партиях я хорошо разобрался и думаю, что себестоимость при списании лучше брать запросом SQL по всем документам с начала работы, или я неправ?

2 6 Я к сожалению только заинтересовался проблемой, провожу теоретические изыскания.
2 5 Ты можешь сущность временного расчета прояснить подробней?

Аттестацию проходил? Дядьку с бородой порадовал?

(6) SELECT * FROM SC186

Женщина, ты за кого?
Мот автору написать свою систему, а мы как дураки будем хранить итоги и смотреть на ТА при проведении?

У меня аттестации в реалити, пробовал исправить последовательности на очень больших базах дистребюторских.

(7) Перерасчет итогов делается для повышения производительности. Для повышения этой самой производительности 1С пошла по пути сознательной денормализации БД. Не забывай, что 1С работает не только в режиме SQL, но еще и в DBF режиме,в котором такие "лихие и производительные" запросы не проходят. Для этого, кстати, и придумали дурацкий язык запросов 1С.
>> думаю, что себестоимость при списании лучше брать запросом SQL по всем документам с начала работы, или я неправ
В случае с 1С - неправ. Правда, стоит отметить, что использующийся механизм повышения производительности получения остатков и оборотов не единственно возможный и чреват как раз теми нерпиятностями о которых ты пишешь.

(10) И какие итоги/обороты выводит приведенный тобой запрос (к таблице справочника)?

(11) Вадим, я не очень поняла что вы тут обсуждаете, если чесно. Бошка уже совсем не варит. Попросили запрос SQL. Я написала. Execution time: 0:00:00, 553 rows

Значит надо использовать 1с++ и прямые запросы? Меня ДБФ проблемы на дистребютогской базе в 3Гб не волнуют!

2 15 Спасибо за идеальный пример! Я об этом и говорил. А с проведениями документов я дела иметь не хочу, пользователь должен сразу видеть, что нехватает ТМЦ а не после проведения!!!

>> Значит надо использовать 1с++ и прямые запросы
*В некоторых случаях* прямые запросы деятвительно значительно повышают производительность системы. Но не являются панацеей. Об альтернативном решении повышения производительности, лишенном недостатков присущих 1С, можно посмотреть напр. здесь: http://www.rsdn.ru/article/db/RDBMS.xml

2(17) Видеть когда должен? А если он не один и кто-то раньше кнопку нажал? А если исправили задним числом приход?
При работе не задним числом расчет итогов не нужен вообще... что пугает-то?
Можно еще и регистры поубирать и шерстить документы

1С++
Текст="select
|Номенклатура.descr as Наименование,
|$Номенклатура.БазоваяЕдиницаИзмерения as [ЕдиницаИзмерения $Перечисление.ЕдиницыИзмерения],
|$Номенклатура.Производитель as [Поставщик $Справочник.Производители]
|from $Справочник.Номенклатура as Номенклатура
|";
ДБ= СоздатьОбъект("ODBCDatabase");
ДБ.Присоеденить1С();
Запрос=СоздатьОбъект("ODBCRecordset");
Запрос.УстБД(ДБ);
Запрос.УстРазмерМножестваСтрок(10);
Если Запрос.Открыть(Текст)=0 Тогда
  ТекОшибка=Запрос.ПолучитьОписаниеОшибки();
  Если ПустоеЗначение(ТекОшибка)=0 Тогда
    Сообщить("Ошибка: "+ТекОшибка,"!!!");
    Возврат;
  КонецЕсли;
КонецЕсли;
ТЗ=СоздатьОбъект("ТаблицаЗначений");
Запрос.ПолучитьРезультатыВ_ТЗ(ТЗ,1);
Запрос.Закрыть();
ДБ="";
ТЗ.ВыбратьСтроку();
---
Время выполнения интересует?

(19)>> При работе не задним числом расчет итогов не нужен вообще
>> Можно еще и регистры поубирать и шерстить документы
Не все так просто, особенно когда нужна аналитика.

2(21) "При работе не задним числом расчет итогов не нужен вообще" - согласен?
"Можно еще и регистры поубирать и шерстить документы" - нельзя получить аналитику из документов? Можно жить прекрасно и без регистров... это просто средство такое от головняка

(22) а). Если речь идет о производительности, то, в общем случае, не согласен.
б). Можно, но не быстро.
Ты в ссылочку-то из (18) загляни. Мне было интересно.

(20) Не, матушка, если уж приводить время исполнения - то приведи время формирования (без итогов) отчета ,ну, к примеру, по маржинальной прибыли (по оплате, т.е. оплаченной отгрузке) в разрезе товарных групп (см. Номенклатура) и менеджеров по закупкам (признак партии номенклатуры) с принятием в учетной политике списания по ФИФО и наличии факта возвратов товара.

(0) немного тупиковый вариант, хотя и имеющий право на жизнь. Просто представим, что торгуем одной единицей товара в течении 5 лет по 10000 раз в день, и для того, чтобы получить остаток на сегодня - будем пересчитывать 365*5*10000 строк в таблице, теперь представим, что у нас 10000 товаров - вопщем попка приходит со временем, однако при этом можно применить для хранения итогов не отдельную таблицу, а вьюху, в которой будут остатки на сегодня на начало дня, и использовать ее для "оперативного" проведения, но это головняк большой и та же попка, что и временный расчет, только в профиль, хотя теоретически должно побыстрее работать.
(21) все, что попадает в измерение регистров, на 99% взято из документа или реквизитов его реквизитов, такчто для меня с недавних времен стали не понятны оборотные регистры в склных базах.

(24) Это довольно сложный запрос. Проще в хранимую процедурку его, чем мучаться с 1С++. Можно я не буду его писать? :-)

(25)
>> все, что попадает в измерение регистров, на 99% взято из документа
Совершенно не обязательно.
Там может быть, к примеру, профит :)
Да и по любому, все одно в отчетах быстрее обратиться к готовой сумме за период, чем выбирать ее запросом.

(27) Вопрос в том, как ее, эту готовую цифру, хранить. Как это делает 1С или...?

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

(26) Можно :)
Но думаю, что при большем документообороте даже при весьма грамотно построенном запросе/ХП вычисление данных циферок сильно проиграет готовым итогам. А на самом деле я привел пример достаточно просто вычисляемой по итогам задачи при соответствующем их строении. Бывают и заметно более сложные задачи.
К чему это я? А, к тому, что итоги - рулез :)

(26)>> Это довольно сложный запрос. Проще в хранимую процедурку его
Вопрос не в том, куда его/их засунуть, и не в том, писать ли его/их сразу на T-SQL или с помощью 1С++, а в том, сколько такой вопрос будет выполняться на довольно приличных объемах информации.

2(30) Вот, единомышленник... хорошо, что 1С-совцы их хранят (хотя бы есть альтернатива какая-то)
ЗЫ. Ссылку прочитал поперек, интересно

(28) в оборотных регистрах 1С хранит вполне нормально :)
(29) в каком таком измерении? в ресурсе ясное дело.
И себестоимость при отгрузке вполне нормально определяется. Конечно, не совсем моментально (для сильно больших баз есть 1С++ & Co); конечно, с некоторыми допущениями/отклонениями (отфактуровки и т.п). Но 99% точность, думаю, обеспечивается.

(30) Вы эта... про итоги в шапке? Наслышана.

(31) Уверяю, что быстрее, чем запрос средствами 1С.
Кроме того, можно будет потом сразу таблицу с сервера пропихнуть в Excel. Уже выигрышь в выгрузке в Excel.

Я так понимаю суть предыдущих 34 постов - "С какой стороны разбива...", пардон, "хранить или не хранить промежуточные итоги". А никак не "как считать себестоимость".
Есть сторонники и того, и того. Промежуточные итоги - это даже не изобретение 1С. С информационных системах их успешно использует, например, SCALA. С другой стороны есть системы, их не использующие.
По моему скромному мнению промежуточные итоги есть гуд. Основываюсь на матюках товарищей, работающих с системами их не использующими. Которые работают с приличными объемами, ессно.
При относительно незначительном увеличении объема данных промежуточные итоги прозволяют получить очень хорошую производительность. И даже если это SQL - в этом случае запрос просто еще быстрее отработает.
Частный случай промежуточных итогов - итоги на ТА. Хранение итогов в ГОТОВОМ виде есть очень гуд. Никакой SQL-запрос по всему набору данных с группировкой и суммированием не будет быстрее того же SQL-запроса, выгребающего при помощи условия готовый набор данных.
Все остальное обсуждение, IMHO, несколько о других, хоть и лежащих рядом, вопросах.

Да мало нынче народ книжек умных читает...
А вообще то я знаю запросы на SQL на некоторых БД которые по 5-часов считаются:)
Кроме этого почему то все о блокировках забывают.
А партионка здесь вообще не катит. Поиском почитать как на www.sql.ru народ расчитывает по FIFO и т.п. - чисто курсорами.
Подобные архитектурные реализации обсуждать без привязки к конкретной БД очень долго можно.
Ладно нету времени, мне еще пару отчетов дописать нужно.

(35) Уверяю, что запрос ТЕМИ ЖЕ СРЕДСТВАМИ с использованием итогов будет и проще на порядок и быстрее.
А еще уверяю, что при _правильном_ построении регистров большая часть ГРАМОТНЫХ выборок средствами не так уж катострофически сильно проигрывает прямому обращению к БД. Хотя, конечно, проигрывает.

ГРАМОТНЫХ выборок средствами ---> ГРАМОТНЫХ выборок средствами 1C

(37)>> Да мало нынче народ книжек умных читает
Муму, ты хорош, как всегда. Пришел, наговорил... А теперь все остальные стоят во всем этом...:)

Да просто дежавю. На www.sql.ru там столько копий поломали уже.
Давайте я лучше сразу сделаю вывод - без привязки к конкретной БД(структура,данные,специфика запросов и т.п.) обсуждать это просто бесмысленно.
Для некоторых БД структура хранения данных регистров в 1С(ну DateTimeIDDOC и т.п. не в счет) является оптимальной с точки зрения простота -производительность.
Если конечно совсем оптималные алгоритмы рассматривать то тут нужно вводить множество уловно-оперативных данных и условно-архивных. Расчитывать статистику обращений, делить по дискам , по вьюхам и т.п. учитывать блокировочные механизмы и т.д и т.п.

(41)>> без привязки к конкретной БД... обсуждать это просто бесмысленно
Не могу согласиться. Речь идет о проектном решении. Не побоюсь назвать его одним из высокоуровневых патернов проектирования. И о повторном использовании данного или иных проектных решений. Их преимуществах и недостатках. Во всяком случае я обсуждаю именно это.

То 42.Несомненно такие исследования есть , этакие томики где рассматриваются различные БД и различные алгоритмы. В пределах данной ветки с ее ограничениями еще раз повторюсь без привязки к БД бесмысленно. Ну очень много писать пришлось бы,да и никто не стал бы этого делать.

Поэтому давайте без извращений... будем использовать то, что в 1С заложено
Ну не может выгрузка итогов на ТА быть медленнее каких-либо расчетов

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

(45)>> даже в sql запрос с использованием хранения промежуточных итогов будет работать быстрее нежели запрос по всей базе с расчетом итогов
А где я утверждал обратное? Речь шла о том, что 1С применила решение, в котором в жертву производительности принесена нормализация БД. Это может приводить (и часто приводит) к тому, что если расчитывать итоги по документам или пользоваться сохраненными в специальных таблицах, то получается разный результат. Со всеми вытекающими. Чтобы избежать рассогласования данных приходится пересчитывать итого и вновь их сохранять. Поэтому я и писал, что *мне* такое решение не очень нравится.
Кроме того, я говорил, что существуют другие решения, повышающие производительность системы.

То 46.
В большинстве случаев в денормализации ничего страшного нет если все остальное ноармально реализовано.
В 1С есть явные прорблемы с обработкой трнзакций. В результате целостность данных и соответсвенно соглаованность иногда нарушаются.

(47)>> В большинстве случаев в денормализации ничего страшного нет если все остальное ноармально реализовано
А это когда точно знаем чем платим и за что. Я много раз слышал о том, что "здесь мы денормализуем, зато производительность у нас возрастет..." *Как правило*, мнение о повышении производительности при денормализации структуры в OLTP-системах *чаще всего* оказывалось мифом.
>> В 1С есть явные прорблемы с обработкой трнзакций
Ты все время говоришь о низкоуровневых проблемах, а я о высокоровневых решениях:).

(21) Грамотно построенные оборотные регистры позволяют строить отчеты в скл версии 1С ШТАТНЫМИ средствами с колоссальной скоростью!

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

Ветка ни о чем. Нужны ли промежуточные итоги?
Конечно, нужны (когда дают прирост производительности).
В 1С реализованы, в целом, грамотно.
Автору сабжа посоветовал бы получше разобраться во внутренних механизмах 1С. А то "смешались в кучу кони, люди". И не считать словосочетание "SQL-запрос" заклинанием абсолютного быстродействия.
ЗЫ. Вот что лично меня до сих пор очень сильно раздражает в 1С - так это глупое разделение регистров на оборотные и остатков. Не так уж сложно было бы предусмотреть опциональную настройку типов итогов на уровне ресурса регистра (без итогов, обороты, остатки, и то и другое). Всего-то и было бы не одна таблица итогов на регистр, а две.