Tak wielu ludzi próbuje robić tego typu rzeczy (schematy różnic). Moja opinia to
- Kod źródłowy trafia do narzędzia kontroli wersji (Subversion, CSV, GIT, Perforce...). Traktuj to tak, jakby to był kod Java lub C, tak naprawdę nie jest inaczej. Powinieneś mieć proces instalacji, który to sprawdzi i zastosuje do bazy danych.
- DDL TO KOD ŹRÓDŁOWY. Trafia również do narzędzia kontroli wersji.
- Dane to szara strefa — tabele przeglądowe powinny znajdować się w narzędziu do kontroli wersji. Dane generowane przez aplikację z pewnością nie powinny.
Sposób, w jaki robię to w dzisiejszych czasach, to tworzenie skryptów migracji podobnych do migracji Ruby on Rails. Umieść DDL w skryptach i uruchom je, aby przenieść bazę danych między wersjami. Grupuj zmiany dla wydania w pojedynczy plik lub zestaw plików. Następnie masz skrypt, który przenosi Twoją aplikację z wersji x do wersji y.
Jedną z rzeczy, których nigdy już nie robię (i robiłem to, dopóki nie nauczyłem się lepiej) jest używanie dowolnych narzędzi GUI do tworzenia obiektów bazy danych w moim środowisku programistycznym. Pisz skrypty DDL od pierwszego dnia - i tak będziesz ich potrzebować, aby promować kod do testów, produkcji itp. Widziałem tak wielu ludzi, którzy używają GUI do tworzenia wszystkich obiektów i przychodzą w momencie wydania, jest scrabble do wykonania skrypty do prawidłowego tworzenia/migrowania schematu, które często nie są testowane i kończą się niepowodzeniem!
Każdy będzie miał własne preferencje, jak to zrobić, ale przez lata widziałem, jak wiele z nich robiono źle, co ukształtowało moje opinie powyżej.
