|
![]() |
#1 |
Участник
|
Добрый день.
Суть задачи - уменьшить размер базы за счет переноса данных из 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) Возможно у кого - то были подобные задачи ? Возможно есть какие - то наработки ? |
|
![]() |
#2 |
Участник
|
Цитата:
По крайней мере, мне это видится так. Возможно, что-то не понял... |
|
![]() |
#3 |
Участник
|
Цитата:
Цитата:
Есть база данных на Торговой Точке. Таблице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) Уточнение - через НАВ будет долго и нужно смотреть все связи по 32, например связка с 339. P.S. Для себя бы я сделал как сделана компрессия 3.60 - 3.70 (ЗА 4-ку не помню), но в дополнительную таблицу. |
|
![]() |
#4 |
Участник
|
Цитата:
У вас, я так понял, не одна Торговая Точка, а несколько. Т.е. сначала надо всё аккуратно перенумеровать сначала по 7 млн.опер в каждой ТТ, а потом всё еще раз правильно перенумеровать в Центральном офисе 7+7+? = минимум 14 млн. операций? И всё это надо же несколько раз запускать и перепроверять что там куда перенумеровалось Проще завести новую базу - честно. (мы именно так себе делали "обрезание") Только лучше переносить не по счётчику операций, а по дате. (с 01.01.2010, например) Для начала повыкидывать всяких Дядей Васей, которые пять лет назад что-то покупали один раз со всеми их операциями\действиями\контактами и прочим мусором. А перенести в новую базу ТОЛЬКО список клиентов\поставщиков с ненулевыми балансами -- раз. (Ну, естественно, оставив в новой базе "активно покупающих" клиентов с нулевым балансом ) Все Фин.операции и Клиент.операции до 01.01.10 всё тупо "заархивировать" в одну операцию, а остальное переносить. Ну, не совсем в одну, конечно ![]() Потом перенести товарную базу -- два. Опять же повыкидывать товары, которые уже долгое время не привозились\продавались. Ну, и остальное ФинКнига, ТоварКнига и пр. тут уж надо ручками дописать перенос - никуда не от этого не деться. Тоже до 01.01 всё пытаться "сливать в одну" Зато! Зато уменьшение базы составит 70-80% (проверено) У нас из 8 Гб (native) осталось меньше гига. Всё летает просто. В "архив", естественно никто так никогда и не заглянул, хотя поначалу возмущались: "Как это можно старых клиентов удалять?" А оказалось, что можно и нужно ![]() |
|
![]() |
#5 |
Участник
|
Спасибо за все ответы и советы.
Еще один маленький вопрос - а, если переделать во всех необходимых таблицах поле Entry No. с Integer на BigInteger ? (для того чтобы избежать окончания выделенного диапазона для Торговых точек) |
|
![]() |
#6 |
Участник
|
Цитата:
2. Нерабочие флоуфилды, завязанные с данным Entry No. в измененных таблицах... 3. ..................... Дождитесь уж, пока МС это сам сделает версии эдак в 2022-й, 2078-й... ![]() |
|
![]() |
#7 |
Участник
|
Зачем же bigint? Неужели все 4 294 967 296 операций между точками поделили?
Полагаю самое время начать раздавать отрицательные диапазоны. Хотя на мой взгляд вариант от jopagames2 на перспективу самый правильный. |
|
![]() |
#8 |
Участник
|
Подскажите, пробовал ли кто использовать в качестве номеров операций отрицательные значения? Есть ли в этом случае подводные камни?
|
|