Миграция на свежую базу, надо замутить умную вещь!

[LIGHT]

Коллеги!

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

Расскажу сначала о базе данных.
Есть документ типа - Договор, к этому договору в виде ребенка цепляется куча других документов, спецификации, дополнительные соглашения и так далее, при этому к самим спецификациям может также цеплятся какая ни будь хрень типа протокола разногласий и так далее. Все указаные документы строятся по 1 форме - Document

Схематично это выглядит так:

Договор
- Доп. соглашение 1
- Доп. соглашение 2
- Доп. соглашение 3
-- Протокол разноглачий
- Спецификация
- Спецификация
-- Протокол разногласий
--- Окончательная верия протокола разногласий


Задача следующая:

Начиная работать в новой чистой базе, требуется как-то сохранить структуру таким образом:
Когда юзер создает новый документ - давать ему пиклист выбора главного документа из законсервированой базы данных, ну а дальше начинается мулька - работает скрипт и создает ссылки на документ и его деток с указание названий нокумента все это помещает в какое ни будь поле (назавем его [old]) создаваемого документа в новой базе.

Должно получиться примерно так:

[желтый листочик] Договор
[желтый листочик] - Доп. соглашение 1
[желтый листочик] - Доп. соглашение 2
[желтый листочик] - Доп. соглашение 3
[желтый листочик] -- Протокол разноглачий
[желтый листочик] - Спецификация
[желтый листочик] - Спецификация
[желтый листочик] -- Протокол разногласий
[желтый листочик] --- Окончательная верия протокола разногласий

Вопросы:

Собственно реторический - как бы этот финт ушами разрулить по умному?

Может кто-то делал подобное, возможно, есть др. вариант, давайте обсутим :blink:

 

[morpheus]

Для: LIGHT
а я бы после выбора документа из пиклиста, поднимал бы из архива старые договора ( они ведь получаються теперь рабочие ) и вносил их в новую базу и тока после этого прикреплял бы им новых ребёнков.
Плюс в том что не надо делать всяческие дубляжи

 

[LIGHT]

<!--QuoteBegin-Morpheus+19:12:2007, 15:16 -->
<span class="vbquote">(Morpheus @ 19:12:2007, 15:16 )</span><!--QuoteEBegin-->а я бы после выбора документа из пиклиста, поднимал бы из архива старые договора ( они ведь получаються теперь рабочие ) и вносил их в новую базу и тока после этого прикреплял бы им новых ребёнков.

Плюс в том что не надо делать всяческие дубляжи

[snapback]90592" rel="nofollow" target="_blank[/snapback]​

[/quote]
Вот была такая мысль, только к тому же и придем, цель то простая. Разгрузить базу!
Создавать новых документов нет смысла, они и так есть в старой базе, достаточно просто ссылочек на них из главного документа в новой базе.

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

Другой варинт - кнопка на создание документа - [взять из архива] которая создаст в новой базе копию старого документа + в документе все ссылочки на его деток, а уже дальше пусть юзеры цепляют к нему новые доки.

В общем задача....

И идеи то то есть, выбрать бы лучшую ))) мельчайшая ошибка в идеологии может доставить множество не удобств моим "любимым" пользователям :blink:

 

[morpheus]

Чтото получаеться что родитель и наследник в разных базах ... нехорошо. надо бы в одну

 

[Constantin A Chervonenko]

А к стати...
Как вообще нарисовать иерархию, когда часть её док-тов - в другой базе? IMHO - никак (такой свойство view: каждая строка - только то, что есть в одном док-те данной базы)

Вариантик: в новой базе заместитель старого док-та с 1-2мя полями (для колонок вьюхи) и ссылкой на архив. Форма заместителя - специальная, автоматом открывающая старый док-т

Т.о. количество док-тов с новой базе не уменьшится, но объем...

 

[K-Fire]

ИМХО, архив надо сделать, и продолжать работать со старой базой. В архив сбросить подшивки которые уже врядли будут изменяться, т.е. давно подписанные договора, и работы по которым давно закончились. Всё конечно зависит от специфики вашего бизнеса, но подозреваю что неактивных подшивок вполне может быть 50-80%.

А к стати...
Как вообще нарисовать иерархию, когда часть её док-тов - в другой базе? IMHO - никак (такой свойство view: каждая строка - только то, что есть в одном док-те данной базы)

Вариантик: в новой базе заместитель старого док-та с 1-2мя полями (для колонок вьюхи) и ссылкой на архив. Форма заместителя - специальная, автоматом открывающая старый док-т

Т.о. количество док-тов с новой базе не уменьшится, но объем...

Вот только возможно, что сами документы в базе занимают процентов 10, а всё остальное место - индексы вьюх. Тогда такой способ непрокатит

 

[Akupaka]

Вот только возможно, что сами документы в базе занимают процентов 10, а всё остальное место - индексы вьюх. Тогда такой способ непрокатит

когда-то боролся я с проблемой превышения БД размера на диске... есть такая лажа...
так вот БД весила 64... ГБ
был это СЭД, разгрузили мы его таким способом:
в старых, не используемых делах, вложения были сгружены на диск отдельно, в сетевую шару...
не самый лучший вариант, но БД разгружалась "на ура"...
так что, индексы не всегда виноваты

 

[K-Fire]

И как вы решали проблему когда пользователю надо было документ вложения найти?

 

[Akupaka]

И как вы решали проблему когда пользователю надо было документ вложения найти?

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

 

[LIGHT]

<!--QuoteBegin-Akupaka+20:12:2007, 12:13 -->
<span class="vbquote">(Akupaka @ 20:12:2007, 12:13 )</span><!--QuoteEBegin-->когда-то боролся я с проблемой превышения БД размера на диске... есть такая лажа...
так вот БД весила 64... ГБ smile.gif

[snapback]90718" rel="nofollow" target="_blank[/snapback]​

[/quote]
Хм... вы хотите сказать размер БД в 64 Гектара это предел?

 

[Sandr]

Хм... вы хотите сказать размер БД в 64 Гектара это предел?

да ...для 32-х разрядной системы...и не только базы.. а и любого другого файла...

 

[LIGHT]

NTFS - 4TB

 

[morpheus]

<!--QuoteBegin-LIGHT+25:12:2007, 15:06 -->
<span class="vbquote">(LIGHT @ 25:12:2007, 15:06 )</span><!--QuoteEBegin-->NTFS - 4TB

[snapback]91276" rel="nofollow" target="_blank[/snapback]​

[/quote]
ню-ню ...

 

[LIGHT]

Ограничения NTFS

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

Максимальный размер логического диска NTFS составляет примерно 18 446 744 Тбайт, что, очевидно, достаточно для всех современных приложений, а также приложений, которые появятся в ближайшем будущем. Максимальный размер ФАЙЛА еще больше, так что это ограничение также несущественно.

Количество файлов, хранящихся в одном каталоге NTFS, ничем не ограничено, так что здесь тоже есть преимущество перед FAT.

Ссылка скрыта от гостей

Да и чем вы объясните мне что на оракле под NTFS на win32 (Server 2003) лежит пару базенок размером по 4(упомянуто мной) - 7 - 9 - 11ТБ Отдельными файлами

 

[morpheus]

Вы меня не так поняли, я вовсе не отрицаю этого ограичения ( кстати доверять Вики на 100% тоже изя )

яп просто к тому - ЧТО!!!! ЧТО можно хранить такого в базе что бы она была 4 ТБ. Чуствуеться кривость архитектуры. На крайняк перевести хранения вложеий на винты как таковые

 

[Sandr]

О чем вы спорите? NTFS может и поддерживает 4 ТБ, а вот проц 32-х разрядный - нет....