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]

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]

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/

5 thoughts on “Ewolucyjne podejście do schematu baz danych

  1. Bartek Szafko ? Ewolucyjne podejście do schematu baz danych…

    Dziękujemy za publikację – Trackback z dotnetomaniak.pl…

  2. wolan says:

    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.

  3. 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

  4. Robz says:

    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.

  5. nice to hear from you!

    great job on RH and great tutorial on your blog

Leave a Reply

Your email address will not be published. Required fields are marked *