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

Тема в разделе "Lotus - Программирование", создана пользователем LIGHT, 19 дек 2007.

  1. LIGHT

    LIGHT Гость

    Коллеги!

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

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

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

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


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

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

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

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

    Вопросы:

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

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

    morpheus скриптописец

    Регистрация:
    7 авг 2006
    Сообщения:
    3.927
    Симпатии:
    0
    Для: LIGHT
    а я бы после выбора документа из пиклиста, поднимал бы из архива старые договора ( они ведь получаються теперь рабочие ) и вносил их в новую базу и тока после этого прикреплял бы им новых ребёнков.
    Плюс в том что не надо делать всяческие дубляжи
     
  3. 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:
     
  4. morpheus

    morpheus скриптописец

    Регистрация:
    7 авг 2006
    Сообщения:
    3.927
    Симпатии:
    0
    Чтото получаеться что родитель и наследник в разных базах ... нехорошо. надо бы в одну
     
  5. Constantin A Chervonenko

    Constantin A Chervonenko Well-Known Member

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

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

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

    K-Fire Гость

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

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

    Akupaka А че я?.. О.о

    Регистрация:
    4 окт 2007
    Сообщения:
    3.373
    Симпатии:
    2
    когда-то боролся я с проблемой превышения БД размера на диске... есть такая лажа...
    так вот БД весила 64... ГБ :)
    был это СЭД, разгрузили мы его таким способом:
    в старых, не используемых делах, вложения были сгружены на диск отдельно, в сетевую шару...
    не самый лучший вариант, но БД разгружалась "на ура"...
    так что, индексы не всегда виноваты :)
     
  8. K-Fire

    K-Fire Гость

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

    Akupaka А че я?.. О.о

    Регистрация:
    4 окт 2007
    Сообщения:
    3.373
    Симпатии:
    2
    вложения падали на сетевой ресурс, и ссылка соотв. генерилась...
     
  10. LIGHT

    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 Гектара это предел?
     
  11. Sandr

    Sandr Гость

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

    LIGHT Гость

    NTFS - 4TB
     
  13. morpheus

    morpheus скриптописец

    Регистрация:
    7 авг 2006
    Сообщения:
    3.927
    Симпатии:
    0
    <!--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]
    ню-ню ...
     
  14. LIGHT

    LIGHT Гость

    Ограничения NTFS
    http://ru.wikipedia.org/wiki/NTFS

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

    morpheus скриптописец

    Регистрация:
    7 авг 2006
    Сообщения:
    3.927
    Симпатии:
    0
    Вы меня не так поняли, я вовсе не отрицаю этого ограичения ( кстати доверять Вики на 100% тоже изя )

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

    Sandr Гость

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

Поделиться этой страницей