Как выполнять дефрагментирование RecID

[DPO]

Цитата:

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

То, что у вас проводки ГК идут наравне с проводками по номенклатуре заставляет серьезно заподозрить недостатки в дизайне решения и/или настройках.

Да, предлагаю на этом не зацикливаться. Но если не трудно, объясните или ткните в доку, интересно чем плохо такое соотношение записей в этих таблицах.

Цитата:

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

Я помню идею заталкивать отдельные таблицы в виртуальные компании. Я над ней не думал из-за того, что это путь в тупик. Но если вы скоро спрыгнете на САП, то стоит и ее рассмотреть (ломать — так ломать). Но это если ваш функционал может адекватно работать с виртуальными компаниями.

У нас отключены компании (-INTERNAL=NODATAAREAID). Так сложилось еще до меня, из-за производительности. Я тоже не рассматривал этот вариант потому как производительность у нас не на высоте. Но все равно спасибо, подумаю в эту сторону.

[glibs]

Цитата:

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

...
чем плохо такое соотношение записей в этих таблицах.
...

Дело вкуса. Мне лично это не нравится из-за того, что увеличивает размер базы, что в свою очередь сказывается на снижении производительности и в увеличении продолжительности процедур по ее обслуживанию. В случае с 3.0 еще и ускоряет исчерпание RecId. На мой взгляд эти проблемы нужно понимать еще на этапе проектирования решения, чтобы не возникало таких ситуаций как у вас сейчас.

[Vadik]

DPO, простите, все же можете показать Ваши top 20 таблиц по количеству записей (из праздного любопытства пока спрашиваю)

Цитата:

Хотелось бы услышать ваше мнение о реализации потабличного RecId с помощью дефрагментации

Ну, теоретически может сработать, если делать аккуратно. Просто придется где-то в Вашем алгоритме жестко прописать все ссылки на дефрагментируемую таблицу (стандартному алгоритму этим заморачиваться не надо так как он тупо всех наследников от RecId во всех таблицах обрабатывает). Но предельно аккуратно - одну ссылку не зарегистрировали и привет целостность. Что-то похожее делали когда надо было отдельно обрабатывать ссылки между компаниями (из "реальной" в виртуальную)

[Vadik]

Я на выходных еще немного подумал и вот что получается
- Вам придется реорганизовывать ("укладывать параллельно") все таблицы, потому что иначе нельзя (ну, небезопасно по крайней мере) сдвигать "назад" счетчик в SystemSequences, чтобы потом не нарваться на неуникальность сгенерированного RecId
- Это означает что придется где-то прописать все связи по RecId
- Алгоритм ацки усложнится по сравнению со стандартным, который заточен на то, что значения RecId в пределах компании все же уникальны
Т.е. в общем случае решение довольно сложное и не очень живучее получается. С другой стороны, если у Вас только небольшая часть функционала используется, то можно попробовать

[db]

Обещанный пример "самодельных" RecId для 3.0
В вложении проект с парой классов и джобом

джоб также повторю здесь

static void recIdExtraTest(Args _args)
{
    mSequence_RecIdExtra    seq = new mSequence_RecIdExtra();
    RecIdExtraTest          recIdExtraTest;
    int                     i;
    ;
    // эта строка запрещает для таблицы раздачу стандартных RecId
    // должна быть выполнена до начала пользования новым нумератором
    // например можно поместить в appl.startupPost()
    new SystemSequence().suspendRecIds(tablenum(RecIdExtraTest));
    
    
    for (i = 1; i <= 1000; i++)
    {
        // Раздача самодельных RecId
        recIdExtraTest.(fieldnum(Common, RecId)) = seq.value();
        recIdExtraTest.insert();
    }
}

Если перекрывать insert() и писать код по присвоению RecId в нем, то имеет смысл сделать singleton для mSequence_RecIdExtra поместив его в GlobalCache или непосредственно в Applicаtion

Присвоение RecId только вручную. Возможности глобально сказать что для таких то таблиц брать RecId из нового нумератора нельзя (даже перекрыв insert() могут остаться вызовы doInsert() и вставка через RecordInsertList). Родной режим потабличного RecId в трешке хоть и есть, но неработоспособен (поищите на форуме)

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

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

В вашем случает наверняка имеет смысл сделать это для SalesParm*/PurchParm* таблиц

[Logger]

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

[kostass]

Еще вопрос
По моему, после проведения операций Проверка кодов записей, запрос к systemsequence уже не покажет реальной картины?