Wiele myślałem i czytałem na ten temat. Jest to szeroki temat kontroli konfiguracji i strategii zarządzania zmianami. CMMI ma domenę w tym temacie. Nawet w firmach, które mają akredytację CMMI 3-5, czasami nie kontrolują wersji swoich baz danych.
Na to pytanie należy odpowiedzieć, mając na uwadze następujące ograniczenia .
- Masz opiekuna i każdy DDL jest wykonywany przez tego opiekuna.
- Inne osoby mają możliwość wykonywania instrukcji DDL.
- Musisz tylko zarejestrować, jakie zmiany zostały wprowadzone, ale nie musisz porównywać ogromnych różnic.
- Projektowanie bazy danych odbywa się za pomocą zewnętrznego narzędzia, a następnie jest publikowane w bazie danych. Tym zewnętrznym narzędziem mogą być nawet skrypty DDL pod kontrolą źródła. Ale kluczową kwestią jest kontrola źródła, a następnie publikowanie w bazie danych.
- Nie musisz znać natychmiastowych zmian, ale od czasu do czasu: tj. Co godzinę, codziennie.
- Masz zdefiniowaną strukturę serwera: Rozwój, Test, Produkcja. I dobra strategia testowania.
odpowiedź 1
- jeśli 1, 4,6 jest prawdą, możesz użyć zewnętrznego źródła kontroli. Na przykład
- Embercadero ma narzędzie do zarządzania zmianą bazy danych ( http://www.embarcadero.com/products/db-change-manager-xe ). Który ma zdolność do inżynierii wstecznej bazy danych (Oracle) i oddania jej pod kontrolę źródła. Następnie dowolna liczba programistów, dba może osiągnąć ten schemat i wprowadzić w nim zmiany.
- Oracle SQL Designer jest podobny do tego podejścia.
- Oddawanie skryptów tabel do kontroli źródła (svn, mercurial itp.) I utrzymywanie ich również w tym samym porządku.
- http://www.liquibase.org jest zautomatyzowanym podejściem powyżej.
- Napisałem generator kodu, który wygenerował instrukcje DAL (Data Access Layer), DDL (Create Table). Przekazujemy im kontrolę źródła i tam utrzymujemy. Myślę, że dedykowane rozwiązanie, takie jak likibaza, może działać lepiej.
To podejście działa dobrze, jeśli masz 6. Umieszczasz instrukcje DDL, które są także kodem, w kontroli źródła i utrzymujesz je. Nikt nie zmieni serwerów testowych i produkcyjnych bez należytego rozważenia.
Wady polegają na wprowadzeniu jakichkolwiek zmian w serwerach produkcyjnych lub testowych z dowolnego powodu, szybkiej korekcie błędów, zmianie klucza podstawowego itp. Trzeba te zmiany wprowadzić także na serwerze programistycznym. Ponieważ tak naprawdę serwer programistyczny jest waszą PRAWDĄ. Nie na odwrót.
Jest to podejście bardzo zorientowane na programistów. Ale kiedy tworzysz nowy moduł, działa całkiem dobrze.
Odpowiedź 2
- jeśli 1 i 6 są prawdziwe:
Podobne podejście do odpowiedzi 1 to utrzymanie serwera programistycznego. Każdy używa go zmienia to. Niż czas na aktualizację. Korzystasz z narzędzia do porównywania baz danych. Pobierz je jako skrypty, poddaj je kontroli źródła.
- Red Gate Schema Compare supports Oracle
- Embercadero has similar tool
- https://github.com/carbonfive/db-migration
- http://www.sumsoftsolutions.com/svco/ (I have not used this product but I believe it belongs to this category.)
- Rails Active Migration (http://www.oracle.com/technetwork/articles/kern-rails-migrations-100756.html)
Różnica między odpowiedzią 1 a odpowiedzią 2 polega na tym, że w odpowiedzi 1 gromadzisz instrukcje DDL dla całej bazy danych i je przechowujesz. W odpowiedzi 2 musisz zapisać każdą wersję zmiany.
- Początek
- V1
- V2
- V3
- ...
Jeśli umieścisz kolumnę w tabeli, a później zdecydujesz się ją usunąć. Skrypty pokażą to w odpowiedzi 2, natomiast w odpowiedzi 1 zobaczysz tylko ostatnią wersję. I musisz porównać V2 i V1, aby zobaczyć różnice. Osobiście bardziej lubię odpowiedź 1, ponieważ mogę łatwo porównać Start i V3, V1 i V3. W odpowiedzi 2 muszę szukać wszystkich zmian. Również w odpowiedzi 2 skrypt w kontroli źródła jest z reguły wielkim, złożonym skryptem. Trudno znaleźć informacje.
Odpowiedź 3
Jeśli 3 jest prawdą. Zauważ, że w tej sytuacji nie masz ograniczenia 6, to znaczy: nie masz serwerów programistycznych, testowych i produktowych. Tylko serwer produkcyjny. Za pomocą wyzwalaczy DDL można rejestrować dokonane zmiany. Jest to najczęściej stosowane w celu zniechęcenia ludzi do nadużywania dotacji DDL. Jeśli wystąpi jakikolwiek problem, możesz znaleźć odpowiedzialnego. Aby to zadziałało, każda osoba powinna połączyć się ze swoim kontem użytkownika, a konto aplikacji nie powinno mieć żadnych dotacji DDL. Ponieważ każdy programista zna konto aplikacji i może z niego korzystać.
Odpowiedź 4
Jeśli masz 3 i 5. Zauważ, że w tej sytuacji nie masz ograniczenia 6, to znaczy: nie masz serwerów programistycznych, testowych i produktowych. Tylko serwer produkcyjny. Zamiast wyzwalacza do zapisywania zmian. Korzystasz z zewnętrznego narzędzia znajdowania zmian i przechowujesz skrypty DDL w kontroli źródła.
Jeśli narzędzie to ma możliwość rejestrowania, kto dokonał zmian, przydałoby się. Zauważ, że w tym rozwiązaniu tracisz dodatkowe DDL, które są wykonywane w odstępach czasu.