Jak zarządzać aktualizacjami schematu do produkcyjnej bazy danych?

To świetne pytanie. ( Istnieje duża szansa, że skończy się to znormalizowaną dyskusją na temat bazy danych..którego nie zamierzam zacząć... Ok, teraz trochę uwagi.)

Niektóre rzeczy z mojej głowy, które zrobiłem (dodam więcej, gdy będę miał więcej czasu lub potrzebuję przerwy)

Client design - tutaj metoda VB inline sql (nawet z przygotowanymi instrukcjami) wpędza cię w kłopoty. Możesz spędzić całe wieki na szukaniu tych stwierdzeń. W przypadku stosowania coś jak Hibernate i umieścić jak najwięcej SQL w nazwanych zapytań masz jedno miejsce dla większości sql (nic gorszego niż próba przetestowania sql, który jest wewnątrz niektórych instrukcji IF i po prostu nie trafisz" trigger " kryteria w testowanie dla tego instrukcji IF). Przed użyciem hibernate (lub innych orms'), gdy wykonywałbym SQL bezpośrednio w JDBC lub ODBC, chciałbym umieścić wszystkie polecenia sql jako publiczne pola obiektu (z konwencją nazewnictwa) lub w pliku właściwości (również z nazwą konwencja dla wartości mówią PREP_STMT_xxxx. I użyj albo odbicia lub iteracji nad wartościami przy starcie w) przypadkach testowych b) uruchamiania aplikacji (niektóre rdbms pozwalają na pre-kompilację z przygotowanymi instrukcjami przed wykonaniem, więc na starcie po zalogowaniu chciałbym wstępnie skompilować prep-stmts przy starcie, aby aplikacja sam testowania. Nawet dla 100-tych wypowiedzi na dobrym rdbms to tylko kilka sekund. i tylko raz. I to bardzo uratowało mój tyłek. Na jednym projekcie DBA nie chciał się komunikować (inny zespół, w innym kraju) i schemat wydawał się zmieniać co noc, bez powodu. I każdego ranka mamy listę dokładnie gdzie zepsuł aplikację, na starcie.

Jeśli potrzebujesz funkcjonalności adhoc, umieść ją w dobrze nazwanej klasie (np. ponownie konwencja nazewnictwa pomaga w testowaniu Auto mated), który działa jako jakiś rodzaj fabryki dla zapytania (np. buduje zapytanie). I tak będziesz musiał napisać odpowiedni kod, wystarczy umieścić w miejsce. Możesz nawet napisać kilka podstawowych metod testowych na tym samym obiekcie lub w osobnej klasie.

Jeśli możesz , Spróbuj również użyć procedur przechowywanych. Są nieco trudniejsze do przetestowania, jak powyżej. Niektóre bazy danych nie sprawdzają poprawności sql w przechowywanych procach względem schematu w czasie kompilacji tylko w czasie wykonywania. Zwykle polega to na pobraniu kopii struktury schematu (brak danych), a następnie utworzeniu wszystkich przechowywanych proców na tej kopii (w przypadku, gdy zespół db dokonujący zmian nie poprawność poprawności). W ten sposób można sprawdzić strukturę. ale jako punkt zarządzania zmianami przechowywane proc są świetne. Na zmiany wszystko dostać. Zwłaszcza, gdy zmiany db są wynikiem zmian procesów biznesowych. I wszystkie języki (java, vb, etc get the change)

Zwykle ustawiam również tabelę, której używam o nazwie system_setting itp. W tej tabeli zachowujemy identyfikator wersji. W ten sposób biblioteki klienckie mogą łączyć się i sprawdzać, czy są poprawne dla tej wersji schematu. W zależności od zmian w schemacie, nie chcesz zezwalać klientom na łączenie się, jeśli mogą uszkodzić twój schemat(np. nie masz zbyt wielu referencjalnych reguł w db, ale na kliencie). To zależy, czy będziesz mieć również wiele wersji klienta (co dzieje się w aplikacjach innych niż web, np. uruchamiają zły binarny). Możesz również mieć narzędzia wsadowe itp. Innym podejściem, które również zrobiłem, jest zdefiniowanie zestawu schematów do wersji operacji w jakimś pliku Właściwości lub ponownie w tabeli system_info. Ta tabela jest ładowana podczas logowania, a następnie używana przez każdego "menedżera" (zwykle mam jakiś rodzaj interfejsu API po stronie klienta, który wykonuje większość operacji db) do walidacji dla tej operacji, jeśli jest to właściwa wersja. W ten sposób większość operacji może odnieść sukces, ale możesz również zawieść (rzucić jakiś wyjątek) NA nieaktualne metody i powiedzieć, dlaczego.

Zarządzanie zmianą schematu - > czy aktualizujesz tabelę lub dodajesz relacje 1-1 do nowych tabel ? Widziałem wiele sklepów, do których zawsze dostęp dane za pomocą widoku z tego powodu. Pozwala to na zmianę nazw tabel , kolumn itp. Bawiłem się pomysłem, aby traktować widoki jak interfejsy w COM. ie. dodajesz nowy widok dla nowych funkcjonalności / wersji. Często to, co cię tutaj sprowadza, to fakt, że możesz mieć wiele raportów (zwłaszcza niestandardowych raportów użytkownika końcowego), które przyjmują formaty tabel. Widoki pozwalają wdrożyć nowy format tabeli, ale obsługują istniejące aplikacje klienckie (pamiętaj o wszystkich nieznośnych raportach adhoc).

Również trzeba napisz Skrypty aktualizacji i wycofywania. i jeszcze raz TEST, TEST, TEST...

------------ OK - TO TROCHĘ PRZYPADKOWY CZAS NA DYSKUSJĘ --------------

Faktycznie miał duży projekt komercyjny (tj. software shop) gdzie mieliśmy ten sam problem. Architektura była warstwą 2 i używali produktu trochę podobnego do PHP, ale pre-php. To samo. inna nazwa. tak czy siak wszedłem w wersji 2....

To kosztowało dużo pieniędzy, aby zrobić uaktualnienia. Bardzo. ie. Rozdaj tygodnie za darmo czas konsultacji na miejscu.

I doszliśmy do tego, że chcemy albo dodać nowe funkcje, albo zoptymalizować kod. Niektóre z istniejących kodów używały procedur składowanych, więc mieliśmy wspólne punkty, w których mogliśmy zarządzać kodem. ale inne obszary były to osadzone znaczniki sql w html. Co było świetne do szybkiego wejścia na rynek, ale przy każdej interakcji z nowymi funkcjami koszt co najmniej podwoił się, aby przetestować i utrzymać. Więc kiedy patrzyliśmy na wyciągnięcie kodu typu php, umieszczając w warstwach danych (to było 2001-2002, pre any ORM ' s etc) i dodanie wielu nowych funkcji (opinie klientów) spojrzał na ten problem jak inżynier aktualizacji do systemu. Co jest wielką sprawą, ponieważ uaktualnienia kosztują dużo pieniędzy, aby zrobić poprawnie. Teraz większość wzorców i wszystkie inne rzeczy, które ludzie dyskutują z pewnym poziomem energii zajmuje się kodem oo, który jest uruchomiony, ale co z faktem, że Twoje dane muszą a) zintegrować się z tą logiką, b) znaczenie, a także struktura danych może się zmienić z biegiem czasu, często ze względu na sposób działania danych, w Twojej organizacji klientów pojawia się wiele podrzędnych procesów / aplikacji, które wymagają tych danych -> Raportowanie ad hoc lub dowolne złożone raportowanie niestandardowe, a także zadania wsadowe, które zostały wykonane dla niestandardowych kanałów danych itp.

Mając to na uwadze zacząłem grać z czymś, co zostało z pola. Ma też kilka założeń. a) dane są znacznie bardziej odczytywane niż zapisywane. b) aktualizacje zdarzają się, ale nie na poziomie banków tj. jeden lub dwa na sekundę powiedz.

Pomysł polegał na zastosowaniu widoku COM / Interface do dostępu do danych przez klientów w zestawie konkretnych tabel (które zmieniały się wraz ze zmianami schematu). Możesz utworzyć osobny widok dla każdej operacji typu-Aktualizuj, Usuń, Wstaw i czytaj. To ważne. Widoki albo mapują bezpośrednio do tabeli, albo pozwalają wyzwalać fałszywą tabelę, która wykonuje rzeczywiste aktualizacje lub wstawia itp. To, czego naprawdę chciałem, to jakiś rodzaj pułapki na poziomie, który wciąż może być wykorzystywane przez crystal reports itp. Uwaga-do wstawiania, aktualizacji i usuwania można również użyć zapisanych proc. I miałeś wersję dla każdej wersji produktu. W ten sposób Twoja Wersja 1.0 miała swoją wersję schematu, a jeśli tabele się zmieniły, nadal będziesz mieć widoki w wersji 1.0, ale z nową logiką zaplecza, aby mapować do nowych tabel w razie potrzeby, ale masz również widoki w wersji 2.0, które obsługują nowe pola itp. To było naprawdę po prostu wsparcie raportowanie ad hoc, które jeśli Twoja firma osoba, a nie koder jest prawdopodobnie cały sens, dlaczego masz produkt. (twój produkt może być Bzdura, ale jeśli masz najlepsze raportowanie na świecie nadal można wygrać, odwrotna jest prawda-twój produkt może być najlepszy mądry funkcji, ale jeśli jego gorzej na raportowanie można bardzo łatwo stracić).

Ok, mam nadzieję, że niektóre z tych pomysłów pomogą.