Размер базы

[Sergo]

Привет всем!
Здесь - http://axapta.mazzy.ru/lib/dbgrowthsolution/ прочитал про очистку базы -
полезная информация, только непонятно про таблицу InventSettlement - сейчас у нас в ней 109 млн. записей, в статье написано про штатные средства группировки.
Вопрос в следующем - какие?

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

[glibs]

Насколько я знаю, МБС об этом сейчас думает.

Интересно, чем вам такая информация поможет?

[Sergo]

2 glibs
это ответ на второй вопрос, а что можете сказать про первый?

[KiselevSA]

Ответ на первый вопрос: "Управление запасами / Периодические операции / Очистка / Очистка складских сопоставлений" (объединение нескольких операций по одной проводке в одну, удаление отмененных сопоставлений)

[Sergo]

спасибо

[gl00mie]

Цитата:

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

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

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

[mazzy]

Цитата:

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

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

Это неправильное мнение.
Правильное мнение - сегментировать базу средствами СУБД - хранить старые данные не более медленных и дешевых носителях.
Ну и конечно же писать код и отчеты так, чтобы минимизировать число запросов "от начала времен"

[Logger]

Цитата:

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

Это неправильное мнение.
Правильное мнение - сегментировать базу средствами СУБД - хранить старые данные не более медленных и дешевых носителях.
Ну и конечно же писать код и отчеты так, чтобы минимизировать число запросов "от начала времен"

А что можно сделать с запросами, которые вызывают фуллскан всей таблицы ? Совсем от них избавиться невозможно. Всего не предусмотришь...

[MironovI]

Обычно к моменту, когда возникает необходимость обрезать базу, сама система настолько морально устаревает, что происходит новое внедрение с вводом остатков и проч

[KiselevSA]

Цитата:

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

А что можно сделать с запросами, которые вызывают фуллскан всей таблицы ? Совсем от них избавиться невозможно. Всего не предусмотришь...

Запросы, вызывающие fullscan по всей таблице за огромное время, необходимо переносить в аналитические системы OLAP

[belugin]

>>>А что можно сделать с запросами, которые вызывают фуллскан всей таблицы >>>Совсем от них избавиться невозможно. Всего не предусмотришь...

Если можно удалить из базы данные раньше определенной даты , почему нельзя построить индекс по полю этой самой даты?

[Recoilme]

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

[Sergo]

Хотелось бы увидеть...

[Recoilme]

Цитата:

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

Хотелось бы увидеть...

Увы...