Strategie projektowania i wdrażania baz danych (VB)

Autor: Scott Mitchell

Podczas wdrażania aplikacji opartej na danych po raz pierwszy można ślepo skopiować bazę danych w środowisku deweloperskim do środowiska produkcyjnego. Jednak wykonanie kopii niewidomej w kolejnych wdrożeniach spowoduje zastąpienie wszystkich danych wprowadzonych do produkcyjnej bazy danych. Zamiast tego wdrożenie bazy danych polega na zastosowaniu zmian wprowadzonych w bazie danych deweloperskich od ostatniego wdrożenia do produkcyjnej bazy danych. Ten samouczek analizuje te wyzwania i oferuje różne strategie ułatwiające chronienie i stosowanie zmian wprowadzonych w bazie danych od ostatniego wdrożenia.

Wprowadzenie

Jak wspomniano w poprzednich samouczkach, wdrażanie aplikacji ASP.NET wiąże się z kopiowaniem istotnej zawartości ze środowiska deweloperskiego do środowiska produkcyjnego. Wdrożenie nie jest jednorazowym zdarzeniem, ale raczej czymś, co dzieje się za każdym razem, gdy nowa wersja oprogramowania zostanie wydana lub gdy zidentyfikowano błędy lub problemy z zabezpieczeniami i zostały rozwiązane. Podczas kopiowania ASP.NET stron, obrazów, plików JavaScript i innych takich plików do środowiska produkcyjnego nie trzeba martwić się, jak ten plik został zmieniony od ostatniego wdrożenia. Możesz niewidomie skopiować plik do środowiska produkcyjnego, zastępując istniejącą zawartość. Niestety ta prostota nie rozszerza się na wdrażanie bazy danych.

Podczas wdrażania aplikacji opartej na danych po raz pierwszy można ślepo skopiować bazę danych w środowisku deweloperskim do środowiska produkcyjnego. Jednak wykonanie kopii niewidomej w kolejnych wdrożeniach spowoduje zastąpienie wszystkich danych wprowadzonych do produkcyjnej bazy danych. Zamiast tego wdrożenie bazy danych polega na zastosowaniu zmian wprowadzonych w bazie danych deweloperskich od ostatniego wdrożenia do produkcyjnej bazy danych. Ten samouczek analizuje te wyzwania i oferuje różne strategie ułatwiające chronienie i stosowanie zmian wprowadzonych w bazie danych od ostatniego wdrożenia.

Wyzwania związane z wdrażaniem bazy danych

Przed wdrożeniem aplikacji opartej na danych po raz pierwszy istnieje tylko jedna baza danych, czyli baza danych w środowisku deweloperskim, dlatego podczas wdrażania aplikacji opartej na danych po raz pierwszy można ślepo skopiować bazę danych w środowisku deweloperskim do środowiska produkcyjnego. Jednak po wdrożeniu aplikacji istnieją dwie kopie bazy danych: jedna w środowisku deweloperskim i jedna w środowisku produkcyjnym.

Między wdrożeniami programistyczne i produkcyjne bazy danych mogą nie być zsynchronizowane. Chociaż schemat produkcyjnej bazy danych pozostaje niezmieniony, schemat bazy danych deweloperskich może ulec zmianie w miarę dodawania nowych funkcji. Możesz dodawać lub usuwać kolumny, tabele, widoki lub procedury składowane. Mogą również istnieć ważne dane dodawane do bazy danych deweloperskich. Wiele aplikacji opartych na danych obejmuje tabele odnośników wypełnione trwale zakodowanymi danymi specyficznymi dla aplikacji, które nie są edytowalne przez użytkownika. Na przykład witryna internetowa aukcji może mieć listę rozwijaną z opcjami opisanymi warunkiem aukcji przedmiotów: Nowe, Podobne do nowych, Dobrych i Sprawiedliwych. Zamiast kodować te opcje bezpośrednio na liście rozwijanej, zwykle lepiej umieścić je w tabeli bazy danych. Jeśli podczas programowania do tabeli zostanie dodany nowy warunek o nazwie Poor ,a następnie podczas wdrażania aplikacji ten sam rekord należy dodać do tabeli odnośników w produkcyjnej bazie danych.

W idealnym przypadku wdrożenie bazy danych wymaga skopiowania bazy danych z programowania do środowiska produkcyjnego. Pamiętaj jednak, że po wdrożeniu aplikacji i wznowieniu programowania produkcyjna baza danych jest wypełniana rzeczywistymi danymi od rzeczywistych użytkowników. W związku z tym, jeśli chcesz po prostu skopiować bazę danych z programowania do środowiska produkcyjnego w następnym wdrożeniu, zastąpisz produkcyjną bazę danych i utracisz istniejące dane. Wynikiem netto jest to, że wdrożenie bazy danych sprowadza się do stosowania zmian wprowadzonych w bazie danych deweloperskich od ostatniego wdrożenia.

Ponieważ wdrażanie bazy danych obejmuje zastosowanie zmian w schemacie i, być może, dane od ostatniego wdrożenia, historia zmian musi być zachowana (lub określona w czasie wdrażania), aby te zmiany mogły być stosowane w środowisku produkcyjnym. Istnieje wiele technik zarządzania i stosowania zmian w modelu danych.

Definiowanie punktu odniesienia

Aby zachować zmiany bazy danych aplikacji, musisz mieć pewien stan początkowy, punkt odniesienia, do którego są stosowane zmiany. W pewnym skrajnym stanie początkowym może być pusta baza danych bez tabel, widoków ani procedur składowanych. Taki punkt odniesienia prowadzi do dużego dziennika zmian, ponieważ musi zawierać tworzenie wszystkich tabel, widoków i procedur składowanych bazy danych wraz z wszelkimi zmianami wprowadzonych po początkowym wdrożeniu. Na drugim końcu spektrum można ustawić punkt odniesienia jako wersję bazy danych, która jest początkowo wdrażana w środowisku produkcyjnym. Ten wybór powoduje znacznie mniejszy dziennik zmian, ponieważ zawiera tylko zmiany wprowadzone w bazie danych po pierwszym wdrożeniu. Jest to podejście, które preferuję. Oczywiście można wybrać bardziej środek podejścia drogowego, definiując punkt odniesienia między początkowym utworzeniem bazy danych a pierwszym wdrożeniem bazy danych.

Po wybraniu punktu odniesienia rozważ wygenerowanie skryptu SQL, który można wykonać w celu odtworzenia wersji punktu odniesienia. Taki skrypt umożliwia szybkie odtworzenie wersji bazowej bazy danych. Ta funkcja jest szczególnie przydatna w większych projektach, gdzie może istnieć wielu deweloperów pracujących nad projektem lub dodatkowymi środowiskami, takimi jak testowanie lub przemieszczanie, które wymagają własnej kopii bazy danych.

Istnieje wiele narzędzi do wygenerowania skryptu SQL w wersji bazowej. W SQL Server Management Studio (SSMS) możesz kliknąć prawym przyciskiem myszy bazę danych, przejść do podmenu Zadania i wybrać opcję Generuj skrypty. Spowoduje to uruchomienie Kreatora skryptów, który można poinstruować o wygenerowaniu pliku zawierającego polecenia SQL w celu utworzenia obiektów bazy danych. Inną opcją jest Kreator publikowania bazy danych, który może wygenerować polecenia SQL, aby nie tylko utworzyć schemat bazy danych, ale także dane w tabelach bazy danych. Kreator publikowania bazy danych został szczegółowo przeanalizowany w samouczku Wdrażanie bazy danych . Niezależnie od używanego narzędzia, w końcu należy mieć plik skryptu, którego można użyć do odtworzenia wersji bazowej bazy danych, jeśli zajdzie taka potrzeba.

Dokumentowanie zmian bazy danych w prozy

Najprostszym sposobem utrzymania dziennika zmian w modelu danych w fazie opracowywania jest zarejestrowanie zmian w prozy. Jeśli na przykład podczas tworzenia już wdrożonej aplikacji dodasz nową kolumnę do Employees tabeli, usuń kolumnę z Orders tabeli i dodaj nową tabelę (ProductCategories), zachowasz plik tekstowy lub dokument microsoft Word z następującą historią:

Zmień datę	Zmień szczegóły
2009-02-03:	Dodano kolumnę DepartmentID (int, NOT NULL) do Employees tabeli. Dodano ograniczenie klucza obcego z Departments.DepartmentID do Employees.DepartmentID.
2009-02-05:	Usunięto kolumnę TotalWeightOrders z tabeli. Dane już przechwycone w skojarzonych OrderDetails rekordach.
2009-02-12:	Utworzono tabelę ProductCategories . Istnieją trzy kolumny: ProductCategoryID (int, IDENTITY, NOT NULL), CategoryName (nvarchar(50), NOT NULL), i Active (bit, NOT NULL). Dodano ograniczenie klucza podstawowego do ProductCategoryIDwartości , a wartość domyślna 1 do Active.

Istnieje wiele wad tego podejścia. Na początek nie ma nadziei na automatyzację. Za każdym razem, gdy te zmiany należy zastosować do bazy danych , na przykład po wdrożeniu aplikacji , deweloper musi ręcznie zaimplementować każdą zmianę, pojedynczo. Ponadto jeśli musisz odtworzyć określoną wersję bazy danych z punktu odniesienia przy użyciu dziennika zmian, wykonanie tego działania zajmie więcej czasu w miarę wzrostu rozmiaru dziennika. Kolejną wadą tej metody jest to, że przejrzystość i poziom szczegółowości każdego wpisu dziennika zmian jest pozostawiony osobie rejestrującej zmianę. W zespole z wieloma deweloperami niektórzy mogą bardziej szczegółowo, czytelniej lub bardziej precyzyjne wpisy niż inne. Ponadto możliwe są literówki i inne błędy wprowadzania danych związane z człowiekiem.

Podstawową zaletą dokumentowania zmian bazy danych w prozy jest prostota. Nie potrzebujesz znajomości składni SQL do tworzenia i zmieniania obiektów bazy danych. Zamiast tego można rejestrować zmiany w prozy i implementować je za pomocą graficznego interfejsu użytkownika SQL Server Management Studio.

Utrzymywanie dziennika zmian w prozy jest, co prawda, nie jest bardzo wyrafinowane i nie będzie działać dobrze z niektórymi projektami, takimi jak te, które są duże w zakresie, mają częste zmiany w modelu danych lub obejmują wielu deweloperów. Ale widziałem, że to podejście działa całkiem dobrze w małych, jednoosobowych projektach, które mają tylko okazjonalne zmiany w modelu danych i gdzie deweloper solo nie ma silnego tła w składni SQL do tworzenia i zmieniania obiektów bazy danych.

Uwaga

Chociaż informacje w dzienniku zmian są technicznie potrzebne tylko do czasu wdrożenia, zalecam zachowanie historii zmian. Jednak zamiast utrzymywać pojedynczy, coraz większy plik dziennika zmian, rozważ użycie innego pliku dziennika zmian dla każdej wersji bazy danych. Zazwyczaj chcesz wersję bazy danych za każdym razem, gdy jest wdrażana. Utrzymując dzienniki zmian, można, począwszy od punktu odniesienia, utworzyć ponownie wersję bazy danych, wykonując skrypty dziennika zmian począwszy od wersji 1 i kontynuując do momentu uzyskania wersji potrzebnej do ponownego utworzenia.

Rejestrowanie instrukcji zmian SQL

Podstawową wadą utrzymania dziennika zmian w prozy jest brak automatyzacji. W idealnym przypadku zaimplementowanie zmian bazy danych w produkcyjnej bazie danych w czasie wdrażania byłoby tak proste, jak kliknięcie przycisku w celu wykonania skryptu, a nie ręczne wykonanie listy instrukcji. Taka automatyzacja jest możliwa dzięki zachowaniu dziennika zmian zawierającego te polecenia SQL używane do zmiany modelu danych.

Składnia SQL zawiera wiele instrukcji do tworzenia i modyfikowania różnych obiektów bazy danych. Na przykład instrukcja CREATE TABLE po wykonaniu tworzy nową tabelę z określonymi kolumnami i ograniczeniami. Instrukcja ALTER TABLE modyfikuje istniejącą tabelę, dodając, usuwając lub modyfikując jej kolumny lub ograniczenia. Istnieją również instrukcje tworzenia, modyfikowania i usuwania indeksów, widoków, funkcji zdefiniowanych przez użytkownika, procedur składowanych, wyzwalaczy i innych obiektów bazy danych.

Wracając do naszego wcześniejszego przykładu, obraz, który podczas tworzenia już wdrożonej aplikacji dodaje nową kolumnę do Employees tabeli, usuwa kolumnę z Orders tabeli i dodaje nową tabelę (ProductCategories). Takie akcje spowodują zmianę pliku dziennika z następującymi poleceniami SQL:

-- Add the DepartmentID column 

ALTER TABLE [Employees] ADD [DepartmentID] 
int NOT NULL 

-- Add a foreign key constraint between Departments.DepartmentID and Employees.DepartmentID
ALTER TABLE [Employees] ADD 
CONSTRAINT [FK_Departments_DepartmentID]
      FOREIGN 
KEY ([DepartmentID]) 
      REFERENCES 
[Departments] ([DepartmentID]) 

-- Remove TotalWeight column from Orders
ALTER TABLE [Orders] DROP COLUMN 
[TotalWeight] 

-- Create the ProductCategories table

CREATE TABLE [ProductCategories]
(
      [ProductCategoryID] 
int IDENTITY(1,1) NOT NULL,
      [CategoryName] 
nvarchar(50) NOT NULL,
      [Active] 
bit NOT NULL CONSTRAINT [DF_ProductCategories_Active]  DEFAULT 
((1)),
      CONSTRAINT 
[PK_ProductCategories] PRIMARY KEY CLUSTERED ( [ProductCategoryID])
)

Wypychanie tych zmian do produkcyjnej bazy danych w czasie wdrażania jest operacją jednokrotną: otwórz SQL Server Management Studio, połącz się z produkcyjną bazą danych, otwórz okno Nowe zapytanie, wklej zawartość dziennika zmian, a następnie kliknij przycisk Wykonaj, aby uruchomić skrypt.

Używanie narzędzia porównania do synchronizowania modeli danych

Dokumentowanie zmian bazy danych w prozy jest łatwe, ale implementacja zmian wymaga od dewelopera wprowadzenia każdej zmiany w produkcyjnej bazie danych jednocześnie; dokumentowanie zmian poleceń SQL sprawia, że implementowanie tych zmian w produkcyjnej bazie danych jest tak proste i szybkie, jak kliknięcie przycisku, ale wymaga nauki i opanowania instrukcji SQL oraz składni do tworzenia i zmieniania obiektów bazy danych. Narzędzia do porównywania baz danych najlepiej przyjmują zarówno podejścia, jak i odrzucają najgorsze.

Narzędzie do porównywania bazy danych porównuje schemat lub dane dwóch baz danych i wyświetla raport podsumowania pokazujący, jak różnią się bazy danych. Następnie za pomocą kliknięcia przycisku można wygenerować polecenia SQL służące do synchronizowania co najmniej jednego obiektu bazy danych. W skrócie można użyć narzędzia do porównywania baz danych, aby porównać deweloperskie i produkcyjne bazy danych w czasie wdrażania, generując plik zawierający polecenia SQL, które po wykonaniu będą stosować zmiany do schematu produkcyjnej bazy danych, tak aby odzwierciedlał schemat bazy danych deweloperskich.

Istnieje wiele narzędzi do porównywania baz danych innych firm oferowanych przez wielu różnych dostawców. Jednym z takich przykładów jest NARZĘDZIE SQL Compare firmy Red Gate Software. Przeanalizujmy proces używania programu SQL Compare do porównywania i synchronizowania schematów programowania i produkcyjnych baz danych.

Uwaga

W momencie pisania bieżącej wersji programu SQL Compare była w wersji 7.1, a wersja Standard Edition kosztuje 395 USD. Możesz kontynuować, pobierając bezpłatną 14-dniową wersję próbną.

Po uruchomieniu programu SQL Compare zostanie otwarte okno dialogowe Projekty porównania, w którym są wyświetlane zapisane projekty SQL Compare. Tworzenie nowego projektu. Spowoduje to uruchomienie Kreatora konfiguracji projektu, który wyświetla monit o informacje o bazach danych do porównania (zobacz Rysunek 1). Wprowadź informacje dotyczące baz danych środowiska deweloperskiego i produkcyjnego.

Rysunek 1. Porównanie baz danych programowania i produkcji (kliknij, aby wyświetlić obraz o pełnym rozmiarze)

Uwaga

Jeśli baza danych środowiska deweloperskiego jest plikiem bazy danych programu SQL Express Edition w App_Data folderze witryny internetowej, musisz zarejestrować bazę danych na serwerze bazy danych SQL Server Express, aby wybrać ją z okna dialogowego pokazanego na rysunku 1. Najprostszym sposobem osiągnięcia tego celu jest otwarcie SQL Server Management Studio (SSMS), nawiązanie połączenia z serwerem bazy danych SQL Server Express i dołączenie bazy danych. Jeśli na komputerze nie zainstalowano programu SSMS, możesz pobrać i zainstalować bezpłatną SQL Server Management Studio.

Oprócz wybierania baz danych do porównania można również określić różne ustawienia porównania na karcie Opcje. Jedną z opcji, którą można włączyć, jest "Ignoruj ograniczenia i nazwy indeksów". Jak pamiętasz, w poprzednim samouczku dodaliśmy obiekty bazy danych usług aplikacji do baz danych programowania i produkcji. Jeśli użyto aspnet_regsql.exe narzędzia do utworzenia tych obiektów w produkcyjnej bazie danych, okaże się, że klucz podstawowy i unikatowe nazwy ograniczeń różnią się między bazami danych deweloperskich i produkcyjnych. W związku z tym funkcja SQL Compare oznaczy wszystkie tabele usług aplikacji jako różne. Możesz pozostawić niezaznaczone pole wyboru "Ignoruj ograniczenia i nazwy indeksów" i zsynchronizować nazwy ograniczeń lub poinstruować narzędzie SQL Compare, aby zignorowało te różnice.

Po wybraniu baz danych do porównania (i przejrzeniu opcji porównania) kliknij przycisk Porównaj teraz, aby rozpocząć porównywanie. W ciągu najbliższych kilku sekund narzędzie SQL Compare analizuje schematy dwóch baz danych i generuje raport o tym, jak się różnią. Celowo wprowadzono pewne modyfikacje w bazie danych deweloperów, aby pokazać, jak takie rozbieżności są zanotowane w interfejsie SQL Compare. Jak pokazano na rysunku 2, dodano kolumnę BirthDate do Authors tabeli, usunięto ISBN kolumnę z Books tabeli i dodano nową tabelę , Ratingsktóra ma umożliwić użytkownikom odwiedzającym witrynę ocenę przeglądanych książek.

Uwaga

Zmiany modelu danych wprowadzone w tym samouczku zostały wykonane w celu zilustrowania przy użyciu narzędzia do porównywania bazy danych. Te zmiany nie będą znajdować się w bazie danych w przyszłych samouczkach.

Rysunek 2. Porównanie sql Listy różnice między bazami danych deweloperskich i produkcyjnych (kliknij, aby wyświetlić obraz w pełnym rozmiarze)

Funkcja SQL Compare dzieli obiekty bazy danych na grupy, szybko pokazując, jakie obiekty istnieją w obu bazach danych, ale są różne, które obiekty istnieją w jednej bazie danych, ale nie w drugiej, i które obiekty są identyczne. Jak widać, istnieją dwa obiekty, które istnieją w obu bazach danych, ale są różne: Authors tabela, która zawierała dodaną kolumnę, oraz Books tabelę, która została usunięta. Istnieje jeden obiekt, który istnieje tylko w bazie danych deweloperów, a mianowicie nowo utworzoną Ratings tabelę. Istnieje również 117 obiektów, które są identyczne w obu bazach danych.

Wybranie obiektu bazy danych powoduje wyświetlenie okna Różnice SQL, które pokazuje różnice między tymi obiektami. W oknie Różnice SQL wyświetlane u dołu na rysunku 2 wyróżniono, że Authors tabela w bazie danych deweloperskich zawiera kolumnę BirthDate , która nie znajduje się w Authors tabeli w produkcyjnej bazie danych.

Po przejrzeniu różnic i wybraniu obiektów, które chcesz zsynchronizować, następnym krokiem jest wygenerowanie poleceń SQL potrzebnych do zaktualizowania schematu produkcyjnej bazy danych w celu dopasowania do bazy danych deweloperskiej. Jest to realizowane za pośrednictwem Kreatora synchronizacji. Kreator synchronizacji potwierdza, jakie obiekty mają być synchronizowane i podsumowuje plan działania (zobacz Rysunek 3). Bazy danych można natychmiast zsynchronizować lub wygenerować skrypt za pomocą poleceń SQL, które można uruchamiać w czasie wolnym.

Rysunek 3. Synchronizowanie schematów baz danych za pomocą Kreatora synchronizacji (kliknij, aby wyświetlić obraz o pełnym rozmiarze)

Narzędzia do porównywania baz danych, takie jak oprogramowanie Red Gate Software s SQL Compare, umożliwiają stosowanie zmian do schematu bazy danych deweloperskiej do produkcyjnej bazy danych tak łatwo, jak tylko wskaż i kliknij.

Uwaga

Narzędzie SQL Compare porównuje i synchronizuje dwa schematy baz danych. Niestety, nie porównuje i nie synchronizuje danych w dwóch tabelach baz danych. Oprogramowanie Red Gate software oferuje produkt o nazwie SQL Data Compare , który porównuje i synchronizuje dane między dwiema bazami danych, ale jest to oddzielny produkt od usługi SQL Compare i kosztuje kolejne 395 USD.

Przełączanie aplikacji w tryb offline podczas wdrażania

Jak widzieliśmy w tych samouczkach, wdrażanie to proces obejmujący wiele kroków: kopiowanie stron ASP.NET, stron wzorcowych, plików CSS, plików JavaScript, obrazów i innej niezbędnej zawartości ze środowiska projektowego do środowiska produkcyjnego; skopiowanie informacji konfiguracyjnych specyficznych dla środowiska produkcyjnego, w razie potrzeby; i zastosowanie zmian do modelu danych od ostatniego wdrożenia. W zależności od liczby plików i złożoności zmian bazy danych wykonanie tych kroków może potrwać od kilku sekund do kilku minut. W tym oknie aplikacja internetowa jest w strumieniu, a użytkownicy odwiedzający witrynę mogą napotkać błędy lub nieoczekiwane zachowanie.

Podczas wdrażania witryny internetowej najlepiej jest przejąć aplikację internetową "w tryb offline", dopóki wdrożenie nie zostanie ukończone. Przełączenie aplikacji w tryb offline (i przywrócenie jej po zakończeniu procesu wdrażania) jest tak proste, jak przekazanie pliku, a następnie usunięcie go. Począwszy od ASP.NET 2.0, sama obecność pliku o nazwie app_offline.htm w katalogu głównym aplikacji pobiera całą witrynę internetową "offline". Każde żądanie do strony ASP.NET w tej witrynie jest automatycznie odpowiadać zawartością app_offline.htm pliku. Po usunięciu tego pliku aplikacja wraca do trybu online.

Przełączenie aplikacji w tryb offline podczas wdrażania jest tak proste, jak przekazanie app_offline.htm pliku do katalogu głównego środowiska produkcyjnego przed rozpoczęciem procesu wdrażania, a następnie usunięcie go (lub zmiana nazwy na coś innego) po zakończeniu wdrażania. Aby uzyskać więcej informacji na temat tej techniki, zapoznaj się z artykułem John Peterson: Taking an ASP.NET Application Offline (Wykonywanie aplikacji w trybie offline ASP.NET).

Podsumowanie

Głównym wyzwaniem w wdrażaniu opartych na danych centrów aplikacji wokół wdrażania bazy danych. Ponieważ istnieją dwie wersje bazy danych — jedna w środowisku deweloperskim i jedna w środowisku produkcyjnym — te dwa schematy baz danych mogą nie być zsynchronizowane, ponieważ nowe funkcje są dodawane do programowania. Co więcej, ponieważ produkcyjna baza danych jako wypełniana rzeczywistymi danymi od rzeczywistych użytkowników, nie można zastąpić produkcyjnej bazy danych zmodyfikowaną bazą danych programistyjną, jak można podczas wdrażania plików tworzących aplikację (strony ASP.NET, pliki obrazów itd.). Zamiast tego wdrożenie bazy danych wiąże się z wdrożeniem dokładnego zestawu zmian wprowadzonych w bazie danych deweloperskich w produkcyjnej bazie danych od ostatniego wdrożenia.

W tym samouczku przedstawiono trzy techniki konserwacji i stosowania dziennika zmian bazy danych. Najprostszym podejściem jest zarejestrowanie zmian w prozy. Chociaż ta taktyka sprawia, że implementowanie tych zmian w produkcyjnej bazie danych jest procesem ręcznym, nie wymaga znajomości poleceń SQL do tworzenia i zmieniania obiektów bazy danych. Bardziej wyrafinowane podejście i takie, które jest znacznie bardziej smaczne w większych projektach lub projektach z wieloma deweloperami, polega na rejestrowaniu zmian w postaci serii poleceń SQL. Znacznie rozszerza to wprowadzanie tych zmian w docelowej bazie danych. Najlepsze z obu podejść można osiągnąć przy użyciu narzędzia do porównywania baz danych, takiego jak Red Gate Software s SQL Compare.

W tym samouczku skoncentrujemy się na wdrażaniu aplikacji opartej na danych. W następnym zestawie samouczków przedstawiono sposób reagowania na błędy w środowisku produkcyjnym. Przyjrzymy się, jak wyświetlić przyjazną stronę błędu zamiast żółtego ekranu śmierci. Zobaczymy również, jak rejestrować szczegóły błędu i jak otrzymywać alerty w przypadku wystąpienia takich błędów.

Szczęśliwe programowanie!

WsteczDalej