Dobrym sposobem śledzenia zmian schematu w wielu gałęziach projektu programistycznego jest przestrzeganie refaktoryzacja bazy danych proces. Wśród innych korzyści, ten rodzaj procesu obejmuje użycie skryptów delta i migracji w celu zastosowania zmian schematu w każdym środowisku (lub gałęzi w twoim przypadku). Konfiguracja może wyglądać mniej więcej tak:
main
src <-- ASP.NET project source
db <-- Database create scripts
delta <-- Database change scripts (SQL delta files)
branch
src
db <-- usually has the same contents as the copy in main branch
delta <-- only the changes necessary for this branch
Za każdym razem, gdy musisz zmienić schemat bazy danych dla określonej gałęzi, tworzysz skrypt delta SQL, który służy do zastosowania zmiany. Aby to ułatwić, sugerowałbym nazwanie każdego pliku skryptu, aby zawierał datę i godzinę utworzenia, aby utrzymać je w kolejności. Przykładem może być:
201102231435_addcolumn.sql
201102231447_addconstraint.sql
201103010845_anotherchange.sql
Dodaj pliki delta do kontroli źródła w gałęzi, w której należy dokonać zmiany schematu. Powinieneś skończyć z każdą gałęzią zawierającą dokładnie to, co jest konieczne do zmiany odpowiedniej bazy danych. Niektóre szczegóły mogą wymagać dostosowania do twojej sytuacji, w zależności od takich rzeczy, jak schemat rozgałęzień i czy twoja baza danych jest zachowywana podczas procesu wydawania (w przeciwieństwie do ponownego tworzenia).
Na koniec, aby spróbować uprościć te koncepcje, poleciłbym narzędzie, które pomoże zarządzać procesem. Proponuję przyjrzeć się DBDeploy / DBDeploy.NET . Z radością używam go od lat we wszystkich moich projektach.
