Vitalii Tsybulnyk / Виталий Цыбульник

On Software Development / О софтверной разработке

About the author

    Vitalii Tsybulnyk
Vitalii Tsybulnyk is a Software Engineering Manager at Mictosoft Azure.
E-mail me Send mail

Activity

Recent comments

Disclaimer

The opinions expressed herein are my own personal opinions and do not represent my employer's view in anyway.

© Copyright 2008-2018

Рефакторим базу данных

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

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

Однако, прогресс не стоит на месте, мыслители и идеологи рефакторинга и гибких методолий конечно же не мирятся с таким упущением. Наглядное тому подтверждение - некоторые книги и статьи Мартина Фаулера и его соратников. Одна из первых таких публикаций - это статья Фаулера 'Evolutionary Database Design', которая собственно и натолкнула меня на написание данного поста.

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

1. База данных исполюзуется в одном приложении или системе, это не интегрированная база данных для многих систем.
2. База данных не должна работать бесперебойно 24/7

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

1. DBA и девелоперы должны очень тесно сотрудничать, т.к. рефакторинг базы данных с большой вероятностью влечёт изменения кода. Устраните все физические, психологические и бюрократические препятствия на пути их сотрудничества. Лично я всегда предпочитал DBA и девелопера в одном лице, котя конечно же это далеко не всегда целесообразно и возможно.

2. У каждого участника процесса есть своя копия базы данных для експериментов по нахождения оптимального рефакторинга.

3. Тестовая база данных - это не просто схема, она также содержит тестовые данные, близкие к реальным. Рефакторинг базы данных - это не только изменение схемы, он зачастую требует миграции и т.п. работы с данными. Чем больше данных содержит ваша тестовая база данных, тем более гладко пройдёт рефакторинг на продакшн базе.

4. Все изменения в базе данных по ходу работы над проектом - это рефакторинги, поэтому применяйте к ним те же шаги и правила, что применяете к обычному рефакторингу (см. Martin Fowler 'Refactoring: Improving the Design of Existing Code')

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

6. Сообщайте о изменнениях в базе всем разработчикам, лучше через автоматическую отправку е-мейла.

7. Выделяйте в своей системе явно выраженный слой доступа к данным, это позволит свести к минимуму последствия рефакторинга базы для остального кода (воспльзуйтесь одним из паттернов, описанных Фаулером в 'Patterns of Enterprise Application Architecture').

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


Posted by Vitalii Tsybulnyk on Tuesday, August 11, 2009 4:25 AM
Permalink | Comments (0) | Post RSSRSS comment feed

Add comment




  Country flag

b i u quote
Loading