Kontrola wersji dla bazy danych

Chyba każdy zespół programistów stosuje CVS lub SVN dla kodu aplikacji. Co z kodem w bazie danych? Oprócz schematu mogą w niej być stored procedures. Zresztą nawet sam schemat powinien chyba być zabezpieczony?

Oczywiście, jest backup bazy, ale to chyba nie jest poważne rozwiązanie? (przywracanie backupu bazy może długo trwać)

Niby można napisać jakiś skrypt eksportujący schemat i procedury, żeby potem dołączyć plik do backupu. Ale czy nie ma rozwiązania naprawdę systematycznego, porządnego, zbliżonego do CVS?

2 lata, 4 miesiące temu | edytowane przez: michu 3536215

Odpowiedz na pytanie

1

Odpowiedzi: 7

  • 2 lata, 4 miesiące temu
    autor: michu

    3

    Krótka odpowiedź: Wersjonujesz schemat bazy danych w postaci skryptów, nie samą bazę danych. Zmiany na bazie odzwierciedlasz w postaci kolejnych skryptów przyrostowych - które nie tylko modyfikują strukturę, ale też zawierają niezbędne transformacje / migracje danych, jeżeli są one potrzebne.

    Długa odpowiedź: Poczytaj rewelacyjną serię artykułów K. Scotta Allena na ten temat:

  • 2 lata, 4 miesiące temu
    autor: bigzbig

    2

    Z wersjonowaniem bazy danych a raczej jej schematu faktycznie jest problem. Osobiście nie słyszałem o dedykowanym do tego celu narzędziu. Zwykle wersjonuje się pliki sql z definicjami tabel oraz z alterami zmieniającymi schemat poszczególnych relacji. Podobnie z procedurami. Idea jest taka aby każdy z programistów utworzył sobie podstawowy schemat bazy i na bieżąco go aktualizował.

    Problemów jest kilka:

    Pierwszy pojawia się kiedy programistę zawodzi pamięć i nie wie, który alter wykonał, a którego jeszcze nie. Można co prawda sprawdzić w repo datę wykonania altera, ale jest to dodatkowy kłopot. Prawdę mówiąc to już sprawdzanie po każdym svn update czy pojawiły się jakieś altery, a także ich wykonywanie jest upierdliwe.

    Inną kwestią jest konieczność uzupełniania lub modyfikowania na skutek zmian w schemacie bazy danych. Pół biedy kiedy da się stworzyć skrypt robiący to z automatu, ale nie zawsze tak jest. Do tego są jeszcze skrypty dodające do BD dane testowe, które też przydałoby się nie rzadko zmodyfikować.

    Kolejnym problemem jest bądź co bądź zdarzająca się sytuacja kiedy dwóch programistów równocześnie modyfikuje schemat bazy danych. Oba się wykonają kiedy są uruchomione jako pierwsze i żaden z nich nie zadziała poprawnie kiedy zostanie odpalony jako drugi. Co wtedy? Cuż w takiej sytuacji w praktyce ten kto commitował jako ostatni ma teraz dodatkową robotę do wykonania.

    Moja wypowiedź powinna być raczej pytaniem bo nie znalazłem satysfakcjonujących rozwiązań powyższych zagadnień. Nie chcę jednak tworzyć podobnego do obecnego pytania dlatego też jeśli ktoś z was wypracował jakieś metody radzenia sobie z powyższymi sytuacjami to chętnie poczytam.

  • 2 lata, 4 miesiące temu
    autor: Kozack

    2

    Ostatnio znalazłem takie narzędzie:

    http://www.liquibase.org/

    "LiquiBase is an open source (LGPL), database-independent library for tracking, managing and applying database changes. It is built on a simple premise: All database changes are stored in a human readable yet trackable form and checked into source control."

    A tutaj mamy wszystko ładnie wytłumaczone:

    http://www.liquibase.org/quickstart

  • 2 lata, 4 miesiące temu
    autor: pietros

    1

    Wprawdzie aplikacja jest jeszcze w fazie tworzenia, ale jest warta zauważenia: http://www.red-gate.com/products/SQLSourceControl/index.htm. Mozna zapisać się na listę osób informowanych o postępie prac i dostępnych wersjach beta.

  • 2 lata, 3 miesiące temu
    autor: wariat

    1

    Troszeczkę obok tematu choć nie do końca. Baza danych (silnik bazy de facto) bazie nierówny. I nie zawsze musi być to ten sam silnik w wersji produkcyjnej i developerskiej i wtedy dochodzimy do SQLite. W przypadku projektów w ROR czy Django na pewno, a i w wielu innych wypadkach zapewne też istnieje możliwość podpięcia SQlite zamiast poważnego silnika, wtedy fizycznie baza jest w pliku, a ten plik może sobie leżeć w katalogu z projektem ergo w katalogu który jest kopiowany do repozytorium.

    Co oczywiście nie zmienia faktu, że obok powinien leżeć skrypt pozwalający utworzyć jedną komendą pustą bazę oraz zestaw skryptów przeznaczonych do migrowania pomiędzy kolejnymi wersjami bazy.

  • 2 lata, 4 miesiące temu
    autor: pawelkor

    0

    1. Baza zawiera dane. Dane należy szanować. Nie używamy współużytkowanego serwera bazy danych do pracy z kodem, który wciąż ulega modyfikacjom. Przyjęcie takiej zasady pozwala często pracować z małą, testową bazą, szybko odtwarzaną ze skryptów. Skrypty powinny zawierać odtwarzanie zarówno schematu, jak i danych potrzebnych programistom.
    2. Jedno autorytatywne źródło schematu. Najlepiej właśnie w CVS czy SVN. Nie może dojść do sytuacji, kiedy zastanawiamy się "z czyjego komputera kopiujemy schemat do testowania/wdrożenia".
      Każdy programista musi mieć możliwość wykonanania bez chwili zastanowienia sekwencji: ściąganie z CVS, kompilacja, uruchomienie skryptu konfigurującego bazę. Więcej - powinien być w stanie bez zastanowienia wykonać tę sekwencję dla dowolnie wskazanej wersji, uzyskując zgodną wersję aplikacji i bazy.
    3. Warto rozważyć wprowadzanie modyfikacji w bazie wyłącznie przy pomocy skryptów modyfikujących, a nie przez zmiany skryptów bazy 1.0. Więcej o tym:
      http://www.codinghorror.com/blog/archives/001050.html

  • 2 lata, 4 miesiące temu
    autor: shreeve

    0

    Spotkałem się z taką "kontrolą wersji bazy", że do każdej akcji na bazie pisany był plik SQL o odpowiedniej nazwie, data i godzina, i wrzucany był na SVN. W połączeniu z komentarzami pozwalało to w dowolnym momencie przywrócić dokładnie taką strukturę bazy danych, jaką potrzebowaliśmy - jedyny minus, że trzeba było te wszystkie skrypty po kolei uruchamiać.

Zaloguj się, aby dodać swoją odpowiedź