Архивация Данных

[art06]

Добрый день.

Суть задачи - уменьшить размер базы за счет переноса данных из 4 таблиц (32,339,5802,17) из рабочей базы в "Архивную", и изменить нумерацию в поле Entry No.

Есть база данных на Торговой Точке. Таблице32 (339,5802,17) начинает нумерацию операций (поле Entry No.) с 50 000 000. Рассчитано что на этот магазин достаточно 9 999 999 записей (по крайней мере на ближайшие несколько лет). Есть база Центарльного Офиса куда попадают все операции с Торговой точки.
Предполагаем что мы подошли к операции под номером 59 999 999. Больше нет возможности использовать номера (60 000 000 и т.д. так как этот диапазон предназначен для другой Торговой Точки). По задаче мне необходимо:

1. весь прошлый год (2006,2007,2008 на ТТ и в ЦО одновременно ) перебросить в "архивные базы" (это примерно 7 млн. записей)
2. произвести перенумерацию оставшихся записей (те записи которые шли под номером 57 000 001 перенумеровать в 50 000 000)

Возможно у кого - то были подобные задачи ? Возможно есть какие - то наработки ?

[Romul]

Цитата:

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

Суть задачи - уменьшить размер базы за счет переноса данных из 4 таблиц (32,339,5802,17) из рабочей базы в "Архивную", и изменить нумерацию в поле Entry No.

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

[RedFox]

Цитата:

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

Суть задачи - уменьшить размер базы за счет переноса данных из 4 таблиц (32,339,5802,17) из рабочей базы в "Архивную", и изменить нумерацию в поле Entry No.

Поссмотри как в 3.60 - 3.70 сделана компрессия. Они вроде почти не сбоила при сжатии (по ЛОТ и серийникам немного повозились.). По аналогии можно сделать 5802, 17, 12401, измерения. Правда стандартно будет долго работать.

Цитата:

Есть база данных на Торговой Точке. Таблице32 (339,5802,17) начинает нумерацию операций (поле Entry No.) с 50 000 000. Рассчитано что на этот магазин достаточно 9 999 999 записей (по крайней мере на ближайшие несколько лет). Есть база Центарльного Офиса куда попадают все операции с Торговой точки.
Предполагаем что мы подошли к операции под номером 59 999 999. Больше нет возможности использовать номера (60 000 000 и т.д. так как этот диапазон предназначен для другой Торговой Точки). По задаче мне необходимо:

1. весь прошлый год (2006,2007,2008 на ТТ и в ЦО одновременно ) перебросить в "архивные базы" (это примерно 7 млн. записей)
2. произвести перенумерацию оставшихся записей (те записи которые шли под номером 57 000 001 перенумеровать в 50 000 000)

Готового у меня нет, но идея простая. Остановить перенос (и элементы генерации данных для переноса), создать дополнительные таблицы, где кроме Entry No. например добавить "итерация Но." и сделать перенос (а может и сначала компрессию), а остальное перенумеровать.
Уточнение - через НАВ будет долго и нужно смотреть все связи по 32, например связка с 339.

P.S. Для себя бы я сделал как сделана компрессия 3.60 - 3.70 (ЗА 4-ку не помню), но в дополнительную таблицу.

[jopagames2]

Цитата:

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

Добрый день.

Суть задачи - уменьшить размер базы за счет переноса данных из 4 таблиц (32,339,5802,17) из рабочей базы в "Архивную", и изменить нумерацию в поле Entry No.

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

Добрый день.

У вас, я так понял, не одна Торговая Точка, а несколько.
Т.е. сначала надо всё аккуратно перенумеровать сначала по 7 млн.опер в каждой ТТ, а потом всё еще раз правильно перенумеровать в Центральном офисе 7+7+? = минимум 14 млн. операций?
И всё это надо же несколько раз запускать и перепроверять что там куда перенумеровалось

Проще завести новую базу - честно. (мы именно так себе делали "обрезание")
Только лучше переносить не по счётчику операций, а по дате. (с 01.01.2010, например)

Для начала повыкидывать всяких Дядей Васей, которые пять лет назад что-то покупали один раз со всеми их операциями\действиями\контактами и прочим мусором.

А перенести в новую базу ТОЛЬКО список клиентов\поставщиков с ненулевыми балансами -- раз.
(Ну, естественно, оставив в новой базе "активно покупающих" клиентов с нулевым балансом )
Все Фин.операции и Клиент.операции до 01.01.10 всё тупо "заархивировать" в одну операцию, а остальное переносить.
Ну, не совсем в одну, конечно Понятно, что кроме "Фин Счет Но." нужно смотреть на всякие там "Источник Но." и разбивать такие операции отдельно, если нужно.

Потом перенести товарную базу -- два.
Опять же повыкидывать товары, которые уже долгое время не привозились\продавались.

Ну, и остальное ФинКнига, ТоварКнига и пр. тут уж надо ручками дописать перенос - никуда не от этого не деться. Тоже до 01.01 всё пытаться "сливать в одну"

Зато! Зато уменьшение базы составит 70-80% (проверено)
У нас из 8 Гб (native) осталось меньше гига. Всё летает просто.

В "архив", естественно никто так никогда и не заглянул, хотя поначалу возмущались: "Как это можно старых клиентов удалять?"

А оказалось, что можно и нужно

[art06]

Спасибо за все ответы и советы.
Еще один маленький вопрос - а, если переделать во всех необходимых таблицах поле Entry No. с Integer на BigInteger ? (для того чтобы избежать окончания выделенного диапазона для Торговых точек)

[Romul]

Цитата:

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

Спасибо за все ответы и советы.
Еще один маленький вопрос - а, если переделать во всех необходимых таблицах поле Entry No. с Integer на BigInteger ? (для того чтобы избежать окончания выделенного диапазона для Торговых точек)

1. Ручной мердж объектов в случае появления новой функциональности на этих таблицах в очередном релизе...
2. Нерабочие флоуфилды, завязанные с данным Entry No. в измененных таблицах...
3. .....................

Дождитесь уж, пока МС это сам сделает версии эдак в 2022-й, 2078-й...

[rmv]

Зачем же bigint? Неужели все 4 294 967 296 операций между точками поделили?
Полагаю самое время начать раздавать отрицательные диапазоны.
Хотя на мой взгляд вариант от jopagames2 на перспективу самый правильный.

[iva_idv]

Цитата:

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

Зачем же bigint? Неужели все 4 294 967 296 операций между точками поделили?
Полагаю самое время начать раздавать отрицательные диапазоны.
Хотя на мой взгляд вариант от jopagames2 на перспективу самый правильный.

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