|   |   | 
| 
 | Таблица итогов в десятки раз больше таблицы движений | ☑ | ||
|---|---|---|---|---|
| 0
    
        OldCondom 31.03.21✎ 12:49 | 
        УПП. 
 Регистр накопления "Расходы при УСН". Таблица движений: dbo._AccumRg28133 5 605 052(число записей) 1 868 352(данные Кб) Таблица итогов: dbo._AccumRgT28152 164 660 849(число записей) 51 091 520(данные Кб) Я так полагаю, это не совсем нормально. Думал нулевые записи(это вроде запись, при которой все ресурсы = 0, верно?), ни одной не выдал запросом: SELECT count(*) FROM [dbo].[_AccumRgT28152] where [_Fld28147] = 0 and [_Fld28148] = 0 and [_Fld28149] = 0 Пересчет итогов увеличивает размер таблицы. Делал truncate table, потом пересчет - результат схож. Пока что еще не делал ТИИ, может быть что и изменится. Вопрос: на что обратить внимание? Откуда такое количество записей и данных? Что не так может быть с базой? Таких регистров 2. | |||
| 1
    
        OldCondom 31.03.21✎ 12:52 | 
        И кстати да, странно, что номера таблиц не совпадают, хотя может это и норма. Названия таблиц смотрел через ПолучитьСтруктуруХраненияБазыДанных().     | |||
| 2
    
        acanta 31.03.21✎ 12:54 | 
        Предположим, есть движения, которые сформировали развернутые остатки (неважно, приход или расход). Предположим что периодичность хранения итогов не месяц а день...  
 Предположим, что единственное движение было год назад... | |||
| 3
    
        H A D G E H O G s 31.03.21✎ 12:56 | 
        Или на начало тысячелетия...     | |||
| 4
    
        H A D G E H O G s 31.03.21✎ 12:57 | ||||
| 5
    
        OldCondom 31.03.21✎ 12:58 | 
        Понял, уже думаю над запросом. Обработку скачал, спасибо     | |||
| 6
    
        OldCondom 31.03.21✎ 12:58 | 
        а, ну собственно в обработке и есть запрос)     | |||
| 7
    
        vis_tmp 31.03.21✎ 12:59 | 
        (6)Что там?     | |||
| 8
    
        Вафель 31.03.21✎ 13:00 | 
        на всякий случай можно поставить начало периода рассчитанных итогов     | |||
| 9
    
        acanta 31.03.21✎ 13:03 | 
        (8) во! А можно начало периода рассчитанных итогов каждый месяц сдвигать на начало этого месяца?     | |||
| 10
    
        Ненавижу 1С гуру 31.03.21✎ 13:10 | 
        (4) немного рефакторинга:
 &НаСервере Процедура ПоказатьНаСервере() ПоказатьТаблицуНаСервере(ТаблицаМинимальныхДат,"МинимальнаяДата",Ложь); ПоказатьТаблицуНаСервере(ТаблицаМаксимальныхДат,"МаксимальнаяДата",Истина); КонецПроцедуры &НаСервере Процедура ПоказатьТаблицуНаСервере(Таблица, ИмяКолонки, ПоУбыванию) СуффиксСортировки = ?(ПоУбыванию," Убыв",""); Таблица.Очистить(); Для Каждого Метаданное Из Метаданные.РегистрыНакопления Цикл Запрос=Новый Запрос; Запрос.Текст= "ВЫБРАТЬ ПЕРВЫЕ 1 | Регистр.Период КАК Период |ИЗ | РегистрНакопления."+Метаданное.Имя+" КАК Регистр | |УПОРЯДОЧИТЬ ПО | Период"+СуффиксСортировки; Выборка=Запрос.Выполнить().Выбрать(); Если не Выборка.Следующий() Тогда Продолжить; КонецЕсли; НоваяСтрока=Таблица.Добавить(); НоваяСтрока.ИмяРегистра=Метаданное.Синоним; НоваяСтрока[ИмяКолонки]=Выборка.Период; НоваяСтрока[ИмяКолонки+"Строкой"]=Выборка.Период; КонецЦикла; Таблица.Сортировать(ИмяКолонки+СуффиксСортировки); КонецПроцедуры | |||
| 11
    
        Kassern 31.03.21✎ 13:21 | 
        (10) тогда уж:
 Если Выборка.Следующий() Тогда НоваяСтрока=Таблица.Добавить(); НоваяСтрока.ИмяРегистра=Метаданное.Синоним; НоваяСтрока[ИмяКолонки]=Выборка.Период; НоваяСтрока[ИмяКолонки+"Строкой"]=Выборка.Период; КонецЕсли; | |||
| 12
    
        Галахад гуру 31.03.21✎ 13:27 | 
        Хм. А к зачем тут рефакторинг? Обработка разовая. Кода на один экран.     | |||
| 13
    
        mistеr 31.03.21✎ 13:34 | 
        (2) >Предположим что периодичность хранения итогов не месяц а день
 А что, так можно? :) | |||
| 14
    
        arsik гуру 31.03.21✎ 14:04 | 
        А в чем критичны очень в будущее или в прошлое смещение дат?
 Если в прошлое, то там по минимуму, ну будет хранится итог по одному движению дохрелиард раз. Ну допустим 1980 год, 490 месяцев. Если в будущее, то итоги то актуальны на текущий месяц, они в будущее не рассчитываются же. | |||
| 15
    
        H A D G E H O G s 31.03.21✎ 14:10 | 
        (14) 490 вставочек остатков при проведении документа, если попадешь на тот срез измерений.     | |||
| 16
    
        H A D G E H O G s 31.03.21✎ 14:11 | 
        (14) Но обычно там нулевая дата, когда движения делаются не по дате документа, а по датеотгрузки к примеру, а док загружен вводом остатков каким нибудь или реквизит самописный.
 Я давно предлагал ввести генерацию ошибки на уровне платформы, но nobody_carer | |||
| 17
    
        ЧессМастер 31.03.21✎ 14:29 | 
        (0) А движения закрываются ?
 Нет висящих остатков или движения только в плюс или минус ?? | |||
| 18
    
        Вафель 31.03.21✎ 14:30 | 
        (17) даже если бы не закрывались, то остатков не может быть существенно больше движений     | |||
| 19
    
        NorthWind 31.03.21✎ 14:41 | 
        (18) почему? Как я понимаю, одно незакрытое в ноль движение порождает по записи в каждый период, т.е. из одной записи движений может получиться столько записей итогов, сколько было периодов. Т.е. довольно много. Нет?     | |||
| 20
    
        OldCondom 31.03.21✎ 14:49 | 
        (17)В тот то и дело, что нет. Висит одна запись от 2017 года. Но 150млн строк этого конечно не хватит. 
 Я видимо чего-то не понимаю. Если бы когда-то в лохматом году сделалась запись(+ или -) и больше по этой аналитике ничего, так я бы увидел это элементарно в запросе "выбрать * из РН.Товары.Остатки". Но там одна строка. (18) Вот именно. И с этого факта я недоумеваю. Читаю уже ИТС и до сих пор не доходит, что пошло не так. | |||
| 21
    
        H A D G E H O G s 31.03.21✎ 14:51 | 
        (20) Разделение итогов включено?     | |||
| 22
    
        Ненавижу 1С гуру 31.03.21✎ 14:51 | 
        (12) спортивный интерес     | |||
| 23
    
        Ненавижу 1С гуру 31.03.21✎ 14:52 | 
        (11) это уже вкусовщина, мне больше нравится 
 Если не Выборка.Следующий() Тогда Продолжить; КонецЕсли; | |||
| 24
    
        OldCondom 31.03.21✎ 14:56 | 
        (21) да     | |||
| 25
    
        OldCondom 31.03.21✎ 15:02 | 
        разделение отключил, идет реструктуризация. Посмотрим, что будет.     | |||
| 26
    
        OldCondom 31.03.21✎ 15:22 | 
        хех. Отключил разделение. 
 Итог: 5млн записей, 1.6Гб вес. Неплохо. | |||
| 27
    
        Очевидно 31.03.21✎ 15:57 | 
        (26) на самом деле "отключать" разделение - не обязательно.
 Если верить ИТС : https://its.1c.ru/db/metod8dev/content/1393/hdoc Нужно пересчитать итоги, и они должны сами свернуться... | |||
| 28
    
        OldCondom 31.03.21✎ 16:13 | 
        (27) да, читал эту статью сегодня. 
 Но по факту, когда сделал полный пересчет только по этому регистру, он увеличился еще на 20-30 гигов(точно не помню). Затем сделал truncate table и еще раз пересчет - вернулся в первоначальные 50Гб | |||
| 29
    
        Злопчинский 31.03.21✎ 16:15 | 
        ну, значит, не закрыт. запихнули че-нить вместо реквизита в измерение и всё... кури бамбук     | |||
| 30
    
        OldCondom 31.03.21✎ 16:18 | 
        (29) возможно надо было начать с ТИИ, логическая целостность и битые ссылки, а потом пересчет. Может дело было в этом и правда.     | |||
| 31
    
        ЧессМастер 31.03.21✎ 17:52 | 
        (18) >остатков не может быть существенно больше движений
 Почему не может ? Если ты сделаешь документ на сто тысяч строк с датой 01.01.2000 и без движений до текущей даты то у тебя движений будет сто тысяч строк а остатков сто тысяч на каждый период. Таблица итогов для регистра накопления хранит остатки в разрезе всех измерений с периодичностью месяц, на начало месяца. В результате у тебя в этой таблице будет по сто тысяч записей на каждый месяц. Проектирование регистра как с движениями только в одну сторону (только приход без расхода и наоборот) как и пропуск закрытия остатков по некоторым измерениям на экзамене является грубой ошибкой. | |||
| 32
    
        Aleksey 31.03.21✎ 17:59 | 
| Форум | Правила | Описание | Объявления | Секции | Поиск | Книга знаний | Вики-миста |