Можно ли удалять InventDim и InventSum без проводок?

[wolfstein]

Цитата:

Сообщение от petr

Кто-нибудь пробовал использовать класс InventUnusedDimCleanUp в четверке? Я имею ввиду экспортировать из 2009, импортировать в четверку и запустить?
Работает?
Были ли замечены какие-либо подводные камни?

Работает.
При переносе из 2009 в 4-ку в методе isCandidateInventDimIdTable() необходимо закомментировать строчку с упоминанием конфигурационного ключа SysDeletedObjects41, т.к. в 4-ке его нет, и тут же добавили строчку с InventSum для его исключения из проверки:

protected boolean isCandidateInventDimIdTable(SysDictTable _sysDictTable)
{
    configurationKeyId  configurationKeyId = _sysDictTable.configurationKeyId();
    tableId             tableId = _sysDictTable.id();
    ;

    // The table should only be evaluated if it has not been marked for deletion, it is
    // not a temporary table and is not InventDim nor InventDimCleanUp
    if (configurationKeyId      == configurationkeynum(SysDeletedObjects40) ||
        //configurationKeyId      == configurationkeynum(SysDeletedObjects41) ||
        _sysDictTable.isTmp()    == true                                     ||
        tableId                 == tablenum(InventDim)                      ||
        tableId                 == tablenum(InventSum)                      ||
        tableId                 == tablenum(InventDimCleanUp))
        return false;
    else
        return true;
}

О результатах работы выше писал Zabr.
Во вложении класс InventUnusedDimCleanUp для 4-ки.

[wolfstein]

Возникла необходимость очистить неиспользуемые InventDim на AX3.0, поэтому по аналогии с AX2009 сделал класс InventUnusedDimCleanUp для трешки.
Может быть кому-то будет полезен.
AX3.0SP3
Проект во вложении.

[Владимир Максимов]

Ну, и для комплекта, код для Axapta 2.5 SP3.

Правда, просто копировать было не интересно, поэтому сделал несколько модификаций

1. Единый многоуровневый ProgressBar
2. Удаление выполняется прямыми командами SQL
3. По окончании работы процедуры выводится Infolog с результатами работы (если было, что удалять)
4. Добавлена краткая справка, вызываемая по F1 при открытой форме
5. Добавлена опциональная возможность удаление во всех компаниях
6. Добавлена опциональная возможность удалить складские остатки (InventSum) по окончании удаления складских аналитик

[Zabr]

Цитата:

Сообщение от Владимир Максимов

[*]Удаление выполняется прямыми командами SQL[/LIST]

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

[Владимир Максимов]

Цитата:

Сообщение от Zabr

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

Соответствующие процедуры сделаны по образу и подобию аналогичной процедуры из Axapta 2009

    connection.ttsbegin();

    statement.executeUpdate(sqlStr);

    connection.ttscommit();

Так что, да. Соблюдается.

Хотя, по большому счету, нарушить целостность выполнения одной единственной команды Delete - это надо постараться И еще, о какой целостности идет речь, если удаляются записи, на которые нет ссылок ни в одной другой таблице?

[Pustik]

Даешь всем желающим по модифе удаления ненужных InventDim!!!!!! Ура

[Vadik]

Цитата:

Сообщение от Pustik

Даешь всем желающим по модифе удаления ненужных InventDim!!!!!! Ура

Может кто-то поделиться статистикой - какие аналитики используются и как, количество записей в InventDim до и после, общие впечатления (по возможности - объективные) ? Просто не очень понятно, что там такого можно понавычистить и что от этого улучшится
P.S. что можно поломать, случайно вычистив не то что надо, я в общих чертах представляю

[Pustik]

Цитата:

Сообщение от Vadik

Может кто-то поделиться статистикой - какие аналитики используются и как, количество записей в InventDim до и после, общие впечатления (по возможности - объективные) ? Просто не очень понятно, что там такого можно понавычистить и что от этого улучшится
P.S. что можно поломать, случайно вычистив не то что надо, я в общих чертах представляю

Я, так понимаю, это камень в мой огород.
Ну, во-первых, я просто шутил, смайлики об этом очень открыто говорят .
Если серьезно, то чистка лишних InventDim имеет имеет смысл для экономии места.
В InventDim, в будущем не нужные записи появляются если :
1) В черновике (Закупка, Заказ, Журнал, Заявки на покупку и т.д.) пользователь изначально задал не правильную аналитику. А потом ответственное лицо аналитику поменяло как надо и разнесло.
2) Проводка, связанная с Производственным заказом без партии, по мере оприходования разобьется на несколько по партиям. И если заказ одноразовый, то комбинация без партии уже не нужна.
3) В Спецификациях вообще привязок к проводкам нет. Т.е. забил пользователь сначала одно, потом поменял на другое, потом на третье. А это уже 3 комбинации.(и это не только в спецификациях). Очень похоже на первый случай, но все таки там документы готовые к разноски, а это просто справочник.
Я думаю случаев еще много. Пользователи, естественно не знают, про InventDim, и на комбинации аналитик им наплевать.Могут шуровать как хотят. В итоге добавят еще пару не нужных комбинаций.
Статистику сказать не могу. Мы этого не делали. Но думаю, что при больших разнообразиях и вариантов комбинаций аналитик, согласно настройкам системы, лишние аналитики будут периодически появляться. почему бы их и не почистить.

[Zabr]

Цитата:

Сообщение от Vadik

Может кто-то поделиться статистикой - какие аналитики используются и как, количество записей в InventDim до и после, общие впечатления (по возможности - объективные) ? Просто не очень понятно, что там такого можно понавычистить и что от этого улучшится
P.S. что можно поломать, случайно вычистив не то что надо, я в общих чертах представляю

Удалилось >20%.
Строки заказа на покупку создаются, потом удаляются - а записи в InventDim остаются.
Текущий размер таблицы InventDim >11 млн.записей.

[Владимир Максимов]

Удалилось примерно 10% от общего количества записей. Как в InventDim, так и в InventSum. От общего объема базы данных это составило примерно 0,1% (по объему InventSum / InventDim = 3 / 1) Строго говоря, "копейки", которые вряд ли вообще заметно повлияют на что-либо. Так что, удаление скорее "для порядка", чем из практической необходимости.

Из стандартных аналитик у нас используется только Склад и ГТД. Плюс добавлены еще 2 собственные аналитики.

[Ace of Database]

Тоже возникла заинтересованность в удалении лишних InventDim.
Написал SQL - запрос, который может быть актуален для Аксапты, в которой ведутся продажи, закупки, складские журналы, журналы прибытия и отгрузки.
По моей базе из 6 млн аналитик неиспользуемых получается 50% - 3 млн.
Аналитика может присутствовать в строке заказа, но осутствовать в складских проводках и в InventSum, так как в результате работы резервирования аналитика в проводках меняется, а строках заказа нет.
Данный запрос я на боевой базе пока не запускал. Еще бы туда по идее надо добавить транспортировки палет и прочие журналы, в которых используется складская аналитика. И еще бы можно было добавить проверку на аналитику "Куда" в строках складского журнала, но я пока решил не проверять это, так как сохранение строк журналов переноса для нас неактуально
Проверка на использование аналитики в строках документов нужна для того, чтобы строки из аксаптовских форм не исчезли после удаления аналитики.

delete from INVENTDIM where 
not exists
(select RECID from InventSum where InventSum.DATAAREAID = InventDim.DATAAREAID and
InventSum.INVENTDIMID = InventDim.INVENTDIMID)
and not exists
(select RECID from InventTrans where InventTrans.DATAAREAID = InventDim.DATAAREAID and
InventTrans.INVENTDIMID = InventDim.INVENTDIMID)
and not exists
(select RECID from SalesLine where SalesLine.DATAAREAID = InventDim.DATAAREAID and
SalesLine.INVENTDIMID = InventDim.INVENTDIMID)
and not exists
(select RECID from PurchLine where PurchLine.DATAAREAID = InventDim.DATAAREAID and
PurchLine.INVENTDIMID = InventDim.INVENTDIMID)
and not exists
(select RECID from InventJournalTrans where InventJournalTrans.DATAAREAID = InventDim.DATAAREAID and
InventJournalTrans.INVENTDIMID = InventDim.INVENTDIMID
)
and not exists
(select RECID from WMSOrderTrans where WMSOrderTrans.DATAAREAID = InventDim.DATAAREAID and
WMSOrderTrans.INVENTDIMID = InventDim.INVENTDIMID)
and not exists
(select RECID from WMSJournalTrans where WMSJournalTrans.DATAAREAID = InventDim.DATAAREAID and
WMSJournalTrans.INVENTDIMID = InventDim.INVENTDIMID)

[Logger]

А сильно помогли эти 20 % ?

[Zabr]

Цитата:

Сообщение от Logger

А сильно помогли эти 20 % ?

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

[Logger]

Цитата:

Сообщение от Zabr

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

Склад в InventDim - это вообще подстава. Не надо было им смешивать высокоселективные аналитики (партия, серийник, ГТД) и низкоселективные.

Денормализацию не пробовали ?

[Wamr]

а слабо джобик в аксе написать, который пробежит по всем табличкам, где есть данные и поля с ссылкой на InventDim и сгенерит по ним такой скрипт?

[Владимир Максимов]

Цитата:

Сообщение от Wamr

а слабо джобик в аксе написать, который пробежит по всем табличкам, где есть данные и поля с ссылкой на InventDim и сгенерит по ним такой скрипт?

Так написано уже И даже не джобик а полноценный класс. Мой проект на предыдущей закладке. Там для 2.5 вообще-то, но отличия от исходного скрипта незначительные. В основном по правам доступа.

[KiselevSA]

Я бы поостерегся удалять таким образом: достаточно в справочнике номенклатур внести одну услугу и InventSum уже не будет работать.

[Владимир Максимов]

Ace of Database

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

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

Как следствие, в приведенном SQL-запросе exists(... from InventSum ...) - лишний. Если складской аналитики нет больше нигде, кроме как в складских остатках, то такую аналитику тоже надо удалить!

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

[БАХ43]

Тоже недавно понадобилось почистить неиспользуемые InventDim. Использовал класс InventUnusedDimCleanUp. Все прекрасно, за час-два осталось 7 млн записей из 16 млн. НО!!! После этого залез в таблицу и невооруженным глазом заметил несколько явно неиспользуемых аналитик. В методе deleteUsedIdsFromCleanUpTable поставил заплаточку:

while( listEnumerator.moveNext() )
    {
// ->
        select firstonly inventDimCleanUp
            where        inventDimCleanUp.InventDimId    == "УЗАН000434";

        if (!inventDimCleanUp && tableId)
        {
            warning(strfmt("Аналитика = %1 найдена в таблице %2 (%3) (%4)", inventDimCleanUp.InventDimId, tableid2pname(tableId), tableid2name(tableId), fieldId2name(tableId, fieldId)));
        }
// <-
        tableAndField = listEnumerator.current();
        tableId = conpeek(tableAndField, 1);
        fieldId = conpeek(tableAndField, 2);

по которой определил, что искомая аналитика удаляется при анализе таблицы WMSOrder. В этой таблице такой аналитики не оказалось ни в InventDimId, ни в toInventDimId. Задумался о легитимности метода deleteInventDimCleanUp.
Поставил еще одну заплаточку:

        tableAndField = listEnumerator.current();
        tableId = conpeek(tableAndField, 1);
        fieldId = conpeek(tableAndField, 2);
// ->        
        dictTable = new DictTable(tableId);
        common = dictTable.makeRecord();

        info(strfmt("%1 (%2) Id = %3", tableid2pname(tableId), tableid2name(tableId), tableId));

        select count(RecId) from inventDimCleanUp
            exists join common
                where inventDimCleanUp.InventDimId == common.(fieldId);
        warning(strfmt("Найдено %1 записей", inventDimCleanUp.RecId));
        
        select count(RecId) from inventDimCleanUp;
        recToDel = inventDimCleanUp.RecId;
// <-
        // Update progress bar
        progress.incCount();
        progress.setText( tableid2pname(tableId) );

        // The InventDim is being used, remove it from the list of unused InventDims
        this.deleteInventDimCleanUp(connection, tableId, fieldId);
        deleted ++;
//->        
        select count(RecId) from inventDimCleanUp;
        recToDel -= inventDimCleanUp.RecId;
        warning(strfmt("Удалено %1 записей", recToDel));
// <-

В итоге получил такой инфолог:

Складской заказ (WMSOrder) Id = 666
Найдено 37141 записей
Удалено 102098 записей
Складской заказ (WMSOrder) Id = 666
Найдено 23159 записей
Удалено 23161 записей
Проводки заказа запасов (WMSOrderTrans) Id = 716
Найдено 9 записей
Удалено 9 записей
Проводки заказа запасов (WMSOrderTrans) Id = 716
Найдено 856640 записей
Удалено 858638 записей

То есть оказалось, что запрос в X++

select count(RecId) from inventDimCleanUp
            exists join common
                where inventDimCleanUp.InventDimId == common.(fieldId);

и запрос, формируемый для SQL в методе deleteInventDimCleanUp

DELETE FROM INVENTDIMCLEANUP WHERE EXISTS (SELECT 'x' FROM WMSORDER T WHERE (INVENTDIMCLEANUP.INVENTDIMID = T.INVENTDIMID))

обрабатывают разное количество записей.
Кто подскажет, в чем может быть дело. Или плюнуть на высокую производительность запроса SQL и удалять записи через delete_from из X++ ???

[Владимир Максимов]

Вы DataAreaId учитываете?