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

[glibs]

Скорость, с которой вы заполняете БД, впечатляет. С учетом того, что вы даже склад не закрываете (а то бы у вас InventSettlement был бы в числе больших таблиц). То, что у вас проводки ГК идут наравне с проводками по номенклатуре заставляет серьезно заподозрить недостатки в дизайне решения и/или настройках. Но здесь развивать эту тему с учетом ваших планов не целесообразно.

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

[DPO]

Цитата:

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

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

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

Цитата:

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

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

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

[glibs]

Цитата:

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

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

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

[Vadik]

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

Цитата:

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

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

[Vadik]

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