Najlepsze metody przechowywania wersji schematu bazy danych w programie SQL Server?

Question

Mam aplikację, która zostanie wdrożona na komputerach produkcyjnych z programem SQL Server. Chcę móc przechowywać i pobrać wersję schematu w mojej bazie danych. Jestem zainteresowany najlepszych praktyk, aby móc osiągnąć ten cel, o następujących głównych celów:

1. w stanie przechowywać i łatwo pobrać numer wersji bazy danych.
2. Ukryte lub trudniejsze do znalezienia i manipulowania przez klientów.
3. Może być edytowany/zmieniany po utworzeniu nowej wersji.
4. Tworzenie kopii zapasowej DB lub blokowanie DB zachowuje wersję # dla analizy sądowej.

Chciałbym mieć sposób na zapisanie "wersji" w metadanych lub nie na zwykłej tabeli, do której można uzyskać dostęp/ustawić za pomocą składowanej procedury systemowej.

Wszelkie pomysły lub najlepsze praktyki?

EDYCJA: Jedną z opcji, którą znalazłem, która może być obiecująca, jest użycie rozszerzonych właściwości programu SQL Server, umieszczenie wartości klucza | przypisanej do bazy danych za pomocą "Schema_Version" i numeru wersji. Nie jest zaszyfrowany (ale wartość może być) i nie jest ukryty, ale przynajmniej został usunięty z rzeczywistej struktury DB, którą przeglądają niektórzy z naszych użytkowników i pracowników terenowych (ku mojej frustracji!))

Answer 1

Jestem menedżerem produktu do kontroli źródeł SQL i porównania SQL w Red Gate. Musieliśmy rozwiązać ten sam problem, ponieważ nasze narzędzie musi wiedzieć, w której wersji były bazy danych, aby wybrać odpowiednie skrypty migracji do zbudowania pełnego skryptu wdrażania.

Rozważaliśmy tabelę wersji, która jest najczęściej opracowywanym rodzimym rozwiązaniem. Jednak z naszych badań dowiedzieliśmy się, że użytkownicy chcieli zachować zestaw obiektów bazy danych "nieskażonych", więc zdecydowaliśmy się na rozszerzoną właściwość na poziomie bazy danych.Dodajemy to do skryptów w następujący sposób:

IF EXISTS (SELECT 1 FROM fn_listextendedproperty(N'SQLSourceControl Database Revision', NULL, NULL, NULL, NULL, NULL, NULL)) 
    EXEC sp_dropextendedproperty N'SQLSourceControl Database Revision', NULL, NULL, NULL, NULL, NULL, NULL 
EXEC sp_addextendedproperty N'SQLSourceControl Database Revision', @RG_SC_VERSION, NULL, NULL, NULL, NULL, NULL, NULL 

Gdy baza danych jest ładowany do SQL Porównaj, wykonuje kontrolę w celu zapewnienia, że ​​wersja, która twierdzi, że jest zgodna z wersją przechowywanych w kontroli źródła.

Mam nadzieję, że to pomoże!

Answer 2

Prawdę mówiąc, po prostu przechowujemy numer schematu każdej z naszych baz danych. Mamy tabelę w bazie danych, która jest używana wyłącznie przez zespół Software Configuration Management, który informuje nas o bieżącej wersji, dzięki czemu możemy szybko zobaczyć w różnych środowiskach, w której wersji jest. Nie martwiłbym się o umieszczenie go poza bazą danych, ponieważ to tylko komplikuje sytuację.

Przypuszczam, że jeśli naprawdę chcesz być bezpieczny, zawsze możesz utworzyć procedurę składowaną z wartością zakodowaną w niej. Następnie możesz zaszyfrować procedurę składowaną, aby nie mogli jej zobaczyć/ingerować w nią bez Twojej wiedzy. Możesz po prostu zaktualizować sp, gdy zmienisz dla nich wersję. Możesz również wejść do systemu i usunąć kod procedury przechowywanej z tabel systemowych po kompilacji, ale naprawdę nie zrobiłbym tego. Doprowadza tylko do problemów.

Answer 3

To, co zrobiłem w poprzedniej firmie, było przechowywanie wersji w tabeli z kilkoma polami (wersja główna, wersja drugorzędna, kompilacja i data), dzięki czemu mogłem mieć historię aktualizacji. Ustawienie odpowiednich uprawnień na stole było wystarczające, aby zapobiec manipulowaniu.

Jeśli naprawdę chcesz, aby trudno było odczytać także dla DBA, możesz zapisać te wartości w tabeli jako zaszyfrowane ciągi. W ten sposób tylko Ty możesz teraz je rozszyfrować.

Answer 4

Mam zaimplementowane rozwiązanie oparte na jednej tabeli, która śledzi czterosegmentową wersję schematu (dur, minor, build, revision) z sygnaturami czasowymi, gdy każda z wersji zaczyna się i kończy swoją ważność. Tylko jeden wiersz ma wartość NULL dla zakończenia znacznika czasu i jest to bieżąca wersja.

Ponadto istnieje wiele procedur przechowywanych, które obsługują ten system wersjonowania, a wszystkie zmienne bazy danych muszą korzystać z tych procedur, aby przetestować i zaktualizować wersję schematu, gdy tylko wprowadzą jakąkolwiek zmianę do schematu bazy danych (np. Dodaj tabelę , upuść kolumnę itp.).

Należy pamiętać, że pełna historia zmian jest przechowywana w tabeli, która śledzi wersje bazy danych. Rozwiązanie jest bardzo elastyczne, gdy coś pójdzie nie tak. Na przykład, jeśli zmienna zostanie przerwana w trakcie wykonywania, wszystkie zmiany, które zostały pomyślnie wprowadzone, są pamiętane w tabeli wersji, ponieważ po każdym kroku zwiększyły liczbę wersji. Możesz ulepszyć zmianę i uruchomić ją ponownie, a ona automatycznie pominie pomyślnie ukończone czynności i będzie kontynuowała od pierwszego kroku, który nie był ostatnim razem.

Jest jeszcze jedna (opcjonalna) sztuczka - użyłem nieparzystych numerów kompilacji dla wersji pośrednich, a nawet numerów kompilacji dla ukończonych wersji. W ten sposób, gdy tylko zaczyna się zmiana, najpierw zmienia numer kompilacji na następną wartość nieparzystą, a następnie robi to, co chce. Jeśli w dowolnym momencie zobaczysz nieparzystą liczbę kompilacji (trzeci segment w numerze wersji), to jesteś pewien, że niektóre zmiany nie zostały zakończone! Gdy modyfikacja zakończy ostatni krok, po prostu zmieni ponownie wersję schematu, tym razem na kolejny, równomierny numer kompilacji, aby powiadomić wszystkich, że została zakończona.

Można zobaczyć kod źródłowy, cały podręcznik i przykłady w tym artykule: How to Maintain SQL Server Database Schema Version