хранение архивных данных в другой БД - рационально?

Рассматривается вопрос о том что бы хранить архив (т.е. все что старше года) в отдельной бд. т.е. в определенный момент сбрасывать старые записи в "архивную БД".
Из плюсов - ускорение работы
возможность поместить эту БД на "медленный диск"
, отпадает необходимость бекапить эти данные и т.д.
Из минусов - усложнение выборки при необходимости обратится к архиву,
тем более за период в который попадают и "архив" и "актуальная БД".
м.б. что то еще о чем не знаю.

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


З.Ы. MS SQL 2005
Спасибо.

> ускорение работы

да? за счет чего это?

> возможность поместить эту БД на "медленный диск"

несущественно

> отпадает необходимость бекапить эти данные и т.д.

а вот это - да

> Из минусов - усложнение выборки при необходимости обратится к архиву,
тем более за период в который попадают и "архив" и "актуальная БД".
м.б. что то еще о чем не знаю.

для этого есть секционированные представления
но вот на 2000 что-то уж больно сложно их вводить в существующие решения

Crimean

> для этого есть секционированные представления но вот на 2000 что-то уж больно сложно их вводить в существующие решения

Можно чуть подробней в какую сторону копать?

Существует ли механизм присоединения к таблице "снизу" таблицы из др. БД
так что бы данные из нее запрашибались только при необходимости?
Возмож но ли это реализовать с минимальной переделкой кода?

читать BOL : Using Partitioned Views

read the BOL... it's even in Russian for 2005

Crimean

читать BOL : Using Partitioned Views

OFFTOP : Дедушка бабушку опередил: Внучку гвоздями к забору прибил!
:)

> OFFTOP

та я тут как раз голову ломаю, как секционировать таблицу, в которой ОЧЕНЬ востребованы как раз IDENTITY и TIMESTAMP поля...
посему форум рою весьма активно и не только этот
но... пока стоимость решения запредельная :(
сэмулировать это, безусловно, можно - через N+1 таблицу при N секциях. в "+1" таблице как раз IDENTITY + TIMESTAMP поля, остальное - дело триггеров. но... триггер получается ТОЛЬКО курсорным что на INSERT, что на UPDATE, что слишком дорого: работа с таблицей на вставку идет пачками...
в итоге время работы базовых вещей просто утраивается, что неприемлемо

да, переход на 2005 не предлагать - бесполезно пока

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

2 Crimean

Нашли какое-то приемлемое решение? У нас та же проблема, как ни крути все получается недешево...

> Нашли какое-то приемлемое решение?

да. все же именно секционированные представления
альтернатив особо нет
все технические проблемы решаемы

Если нетрудно, можно чуть подробнее? Как обошли identity?