базы-монстры

[Sabina]

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

Интересно был ли кто свидетелем, когда и такой ситуации удавалось хоть как-то поправить положение? Имеется в виду конечно не взять и нормализовать ее всю за раз, а какие-нибудь пусть даже очень медленные и постепенные меры. Или может вообще только соблюдение каких-то принципов при добавлении нового к db schema...

[Dmitry67]

Я знаю базу где дизайн был заложен в 93 году и она работает до сих пор
Хорошо работает кстати
Была сделана на Btrieve, где sp нет
Потом перенесена на MS SQL

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

Толстый сервер рулит !

[Win32nipuh]

Наверняка тут есть такие

Я такой
Но вопрос, согласитесь, поставлен очень не конкретно.

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

В одном из случаев, собенно взял за душу комментарий в процедуре, что редкость: "I dont know what is this...." и далее несколько апдэйтов

[Lazy44]

We have it here. Since 1996 and Oracle7
Change of tables design is not feasable. Too much code written

[Sabina]

Change of tables design is not feasable. Too much code written

Так и думала, но решила спросить на всякий случай

[Sabina]

В одном из случаев, собенно взял за душу комментарий в процедуре, что редкость: "I dont know what is this...." и далее несколько апдэйтов

[zVlad]

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

Интересно был ли кто свидетелем, когда и такой ситуации удавалось хоть как-то поправить положение? Имеется в виду конечно не взять и нормализовать ее всю за раз, а какие-нибудь пусть даже очень медленные и постепенные меры. Или может вообще только соблюдение каких-то принципов при добавлении нового к db schema...

Наша база данных (DB2, mainframe) состоит из более 1000 таблиц, общий размер подходит к 500 Gb, растет не резво, поскольку и так не маленькая уже.
Структура оставляет желать лучшего, но касаться ее не позволено, посколько есть внешний разработчик и он готовит новые версии. Что до меня ДБАя, то больших проблем с изменением структуры и адекватной правкой кода я не вижу, так как весь код статический (в терминах DB2), а это значит я могу в любое время запросить каталог DB2 и узнать в каких программах используется интересующая меня таблица, и более того могу получить код SQL операторов без необходимости обращения к исходному тексту.
Ситуация схожая с той что описал Дима67, но я сомневаюсь что в его случае можно получить такую же информацию от MS SQL непосредственно, думаю что там надо лезть в исходники ХП, или я не прав?

[Dmitry67]

xp в MS SQL используются крайне редко
В основном пишут sp, то есть на TSQL
При этом MS SQL ведет список зависимостей процедур от обхектов в sysdependencies

[lzp]

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

Интересно был ли кто свидетелем, когда и такой ситуации удавалось хоть как-то поправить положение?

Дело - висяк. Свидетелей нет. А если кто скажет, что что-то видел или хотя-бы слышал - врет.

[Helmsman]

У нас похожая ситуация, но пока удается выжить...

[-JS-]

Было дело....
Для начала попытались понять есть ли правила общения клиентов с сервером.
Например, все идет через SP или наоборот только AD HOC или как бог на душу положит....
Потом выявляли наиболее критические(тормозные-негибкие) участки БД.
Ловили клиентов работающих с ними и их интерфейсы.
Меняли мета-данные с сохранением существующих интерфейсов,
где view вместо таблиц, где триггеры для сихронизации с новыми таблицами...
В какой-то момент времени практически все данные хранились в двух местах: "по старому" и "по новому"...
Одновременно правили клиентский код - если был доступен.

В результате 90% структуры БД было переделано на новый, и конечно, правильный лад. 10% пришлось оставить в силу недоступности/невозможности исправить клиентов.

[Случай]

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

Я в такой компании работаю. Увеличение объема услуг упало за последний год - 30%, раньше уваивалось.
Архитектура унаследована от мэйфрэйма.
2-х годичный набор данных ныне 140GB.
Для закачки данных из архивов установили новый сервер, но так как MPE работает по своим внутренним законам, а POC (подтверждение концепции) наш архитектор не делал -сам мол сможет, то 6 месяцев уже воз почти без движения.
Правда есть и объективные трудности - отсутствие ссылочной целостности и повторное использование главного ключа - HP былстрая вещь но только на 2-х Гига.

Нынче изучаю две вендоровских апликации - 270 хорошо спроектированных таблиц и более 1000 ну очень ужсных. Причем обе на Оракле, и вторая вешает RAC при 20 коннектах.
Но ничего не сделаешь.
Бизнес: Надо!
Мы: Есть!