Obsługa migracji widoków bazy danych w środowisku wielu deweloperów

Question

Czy istnieją ustalone praktyki dotyczące sposobu, w jaki migracja widoków bazy danych może być pomyślnie obsługiwana w środowisku wielu programistów/wielu oddziałów (VCS)?

Używamy biblioteki migracji bazy danych do wszystkich zmian schematów, ale napotkaliśmy problemy, gdy różni deweloperzy w różnych gałęziach kodu zmieniają ten sam widok, ale ich punkt początkowy był taki sam.

Każdy programista ma swoją własną kopię bazy danych, ale jako że widoki wymagają zwykle określenia całej definicji migracji, oznacza to, że gdy dojdziemy do uruchomienia migracji względem bazy danych pomostowej lub produkcyjnej, niezależnie od tego, która migracja widoku uruchom last zastępuje wszelkie zmiany wprowadzone w poprzednich widokach migracji.

Przykład:

1. Zobacz aktualnie wygląda tak: SELECT 'x'.
2. Deweloper 1 uruchamia gałąź A i dodaje nową kolumnę. Ich migracja "w górę" wygląda następująco: SELECT 'x', 'y'.
3. Deweloper 2 uruchamia gałąź B i dodaje nową kolumnę. Ich migracja "w górę" wygląda następująco: SELECT 'x', 'z'.
4. Deweloper 2 kończy swój oddział jako pierwszy i przeprowadza migrację. Widok wygląda teraz jak SELECT 'x', 'z'.
5. Deweloper 1 kończy swoją gałąź i uruchamia migracje. Widok wygląda teraz na SELECT 'x', 'y', a zmiany programisty 2 zostały utracone.

Answer 1

Jeśli pracują w różnych gałęziach kodu, powinny używać różnych baz danych; a gdy gałęzie zostaną połączone, różnice powinny zostać rozwiązane.

W związku z tym uważam, że schemat należy traktować jako jego własny "projekt". Wspomniałeś wielu programistów zmieniających wspólny WIDOK, gdy jest to nie mniej znacząca zmiana niż ktoś zmieniający sygnaturę powszechnie używanej funkcji we współdzielonej bibliotece dll.

Moja odpowiedź brzmi: (jeśli nie jest za późno na rozwój) należy połączyć standardowy kod klienta pod użytkownikiem MySQL, który nie ma uprawnień do zmiany bazy danych, niż jest to konieczne; i mieć "migracyjną" aplikację/skrypt/cokolwiek, co działa z połączeniem pod kontem użytkownika z wymaganymi uprawnieniami do zmiany tabel, widoków, procedur, itp ...

Answer 2

Dla widoków lub dowolnego obiektu bazy danych, który może być ponownie zdefiniowane w dowolnym momencie (np. funkcje), najlepszą praktyką, jaką znalazłem, jest zapisanie aktualnej definicji funkcji w jej własnym pliku, np. db/views/your_stuff.view.sql; wtedy, gdy programista chce zmienić ten widok, zmienia ten plik, a następnie dodaje migawkę, która po prostu redefiniuje widok z najnowszej wersji (nie wiem, czy jesteś w Railsach, czy nie, ale pomysł tutaj powinien być całkiem jasne):

class UpdateYourStuffView < ActiveRecord::Migration 
    def up 
    execute File.read("#{Rails.root}/db/views/your_stuff.view.sql") 
    end 

    def down 
    # You could expand this to actually track older versions, 
    # but that's generally not worth it. 
    raise ActiveRecord::IrreversibleMigration 
    end 
end 

należy pamiętać, że faktyczna plikiem widoku powinien wyglądać następująco:

CREATE OR REPLACE VIEW your_stuff AS (SELECT 'x' FROM foos); 

to rozwiązuje problemu, ponieważ pracy jest teraz:

1. Zobacz aktualnie wygląda : SELECT 'x' FROM foos.
2. Deweloper 1 uruchamia gałąź A i dodaje nową kolumnę. Modyfikują one db/views/your_stuff.view.sql, aby odzwierciedlić tę zmianę; ich migracja po prostu uruchamia nowy widok.
3. Deweloper 2 uruchamia gałąź B i dodaje nową kolumnę. Zmodyfikują ten sam plik i dodają nową migrację, tak jak powyżej.
4. Deweloper 2 kończy swój oddział jako pierwszy i przeprowadza migrację. Widok wygląda teraz tak, jak SELECT "x", "z".
5. Deweloper 1 kończy swoją filię. Jednak aby połączyć się z master, musi rozwiązać konflikt w pliku widoku. Po wykonaniu migracji i uruchomieniu widok zawiera teraz wszystkie trzy kolumny.