Ewolucyjne podejście do schematu baz danych
Ten post chciałem napisać od czasu, gdy sprzedałem zawarty w nim pomysł Michałowi na jednym ze spotkań PG.NET w końcu się udało 
Jeśli myślisz, że raz stworzysz schemat bazy danych dla swojej aplikacji i już nigdy go nie będziesz zmieniać to jesteś w błędzie. W czasie produkcji może się okazać, że coś zostało pominięte, coś można rozwiazać lepiej, jest błąd albo po prostu trzeba dodać nową funkcjonalność wymagającą zmian w schemacie.
Wprowadzanie takich zmian może być kłopotliwe, każda wprowadzona modyfikacja może powodować, że starsza wersja aplikacji nie będzie działać w oczekiwany sposób. Najlepszy rozwiązaniem jest wprowadzanie wersjonowania schematu bazy danych. W każdym pliku sa przyrostowe skrypty sql, tak żeby w dowolnym momencie można było, zaktualizować schemat z dowolnej historycznej wersji do najbardziej aktualnej albo stworzyć od początku.![CropperCapture[1]](http://bartekszafko.pl/wp-content/uploads/2010/01/CropperCapture1.png "CropperCapture[1]")
Taki plik .sql może zawierać tworzenie nowych i usuwanie istniejących tabel, kolumn, procedur czy cokolwiek innego co można wykonać w bazie.
Trzeba oczywiście również się zatroszczyć o to, aby zapisywać aktualną wersję, można to zrobić bardzo szybko poprzez extended property na bazie lub preferowane przeze mnie rozwiązanie, czyli osobna tabela z pełnymi informacjami kto i kiedy wykonał skrypt.![CropperCapture[3]](http://bartekszafko.pl/wp-content/uploads/2010/01/CropperCapture3.png "CropperCapture[3]")
Takie podejście pozwala również zatroszczyć się o spójność bazy pomiędzy wieloma maszynami developerskimi.
W przypadku np NHibernate tworzenie plików można zautomatyzować za pomocą np.: SchemaUpdate. Tak ja jestem z tych paranoidalnych i nie lubie żeby na środowisku produkcyjnym SchemaUpdate z NHibernate grzebał w bazie.
Warto również w aplikacji zaszyć numer wersji schematu z którym współpracuje, ma to sens zarówno dla aplikacji desktopowych jak i webowych.
W naszych aplikacja z reguły korzystamy napisanego przez nas mechanizmu( nie cierpię na syndrom Not Invented Here;P ), ale okazuje się że jest coś gotowego z dużą ilością fajnych funkcjonalności: Roundhouse .
Smacznego!
UPDATE: na blogu Roba (autora RoundHouse są fajne tutoriale): http://ferventcoder.com/
wolan
11 Jan 10 at 19:13
Do tego o czym piszesz używałem kiedyś DbDeploy.NET (http://www.dbdeploy.net). Na wspomnianej stronie znajduje się lista narzędzi wspomagających migracje. Swego czasu testowałem kilka z nich, ale właśnie DbDeploy.NET przypadł mi najbardziej do gustu.
Bartłomiej Szafko
11 Jan 10 at 22:15
dbdeploy wygląda całkiem ok, muszę przyznać że nie słyszałem o nim do tej pory.
jest jeszcze tarantino.
ale wybór i tak zależy od osobistych preferencji i specyfiki projektu
Robz
19 Jan 10 at 15:14
RH (RoundhousE) is based on some of the ideas behind Tarantino, but it passed Tarantino’s feature set at revision 27. It would have been part of Tarantino but the owner’s were slow at accepting patches and we had different ideas for where to take the product. Thanks for the link love.
I used http://translate.google.com to read this article and it does an okay job at translating.
Bartłomiej Szafko
19 Jan 10 at 22:15
nice to hear from you!
great job on RH and great tutorial on your blog