Strategien für die Datenbankentwicklung und -bereitstellung (VB)

von Scott Mitchell

Beim erstmaligen Bereitstellen einer datengesteuerten Anwendung können Sie die Datenbank in der Entwicklungsumgebung blind in die Produktionsumgebung kopieren. Durch das Ausführen einer Blindkopie in nachfolgenden Bereitstellungen werden jedoch alle daten überschrieben, die in die Produktionsdatenbank eingegeben wurden. Stattdessen umfasst die Bereitstellung einer Datenbank das Anwenden der Änderungen, die seit der letzten Bereitstellung auf die Produktionsdatenbank vorgenommen wurden. Dieses Tutorial analysiert diese Herausforderungen und bietet verschiedene Strategien zur Unterstützung bei der Dokumentation und Anwendung der seit der letzten Bereitstellung an der Datenbank vorgenommenen Änderungen.

Einführung

Wie in früheren Lernprogrammen erläutert, umfasst die Bereitstellung einer ASP.NET Anwendung das Kopieren der relevanten Inhalte aus der Entwicklungsumgebung in die Produktionsumgebung. Die Bereitstellung ist kein einmaliges Ereignis, sondern etwas, das bei jeder Veröffentlichung einer neuen Version der Software geschieht oder wenn Fehler oder Sicherheitsbedenken identifiziert und behoben wurden. Wenn Sie ASP.NET Seiten, Bilder, JavaScript-Dateien und andere solche Dateien in die Produktionsumgebung kopieren, müssen Sie sich nicht mit der Änderung dieser Datei seit der letzten Bereitstellung befassen. Sie können die Datei blind in die Produktion kopieren und den vorhandenen Inhalt überschreiben. Leider erstreckt sich diese Einfachheit nicht auf die Bereitstellung der Datenbank.

Beim erstmaligen Bereitstellen einer datengesteuerten Anwendung können Sie die Datenbank in der Entwicklungsumgebung blind in die Produktionsumgebung kopieren. Wird jedoch eine Blindkopieoperation in nachfolgenden Bereitstellungen durchgeführt, werden alle Daten überschrieben, die in die Produktionsdatenbank eingegeben wurden. Stattdessen umfasst die Bereitstellung einer Datenbank das Anwenden der Änderungen, die seit der letzten Bereitstellung an der Entwicklungsdatenbank vorgenommen wurden, auf die Produktionsdatenbank. Dieses Tutorial untersucht diese Herausforderungen und bietet verschiedene Strategien zur Unterstützung bei der Erfassung und Anwendung der Änderungen, die an der Datenbank seit der letzten Bereitstellung vorgenommen wurden.

Herausforderungen beim Bereitstellen einer Datenbank

Bevor eine datengesteuerte Anwendung zum ersten Mal bereitgestellt wurde, gibt es nur eine Datenbank, nämlich die Datenbank in der Entwicklungsumgebung. Deshalb können Sie beim erstmaligen Bereitstellen einer datengesteuerten Anwendung die Datenbank in der Entwicklungsumgebung blind in die Produktionsumgebung kopieren. Sobald die Anwendung bereitgestellt wurde, gibt es jedoch zwei Kopien der Datenbank: eine in der Entwicklung und eine in der Produktion.

Zwischen Bereitstellungen können die Entwicklungs- und Produktionsdatenbanken nicht mehr synchronisiert werden. Während das Schema der Produktionsdatenbank unverändert bleibt, kann sich das Schema der Entwicklungsdatenbank ändern, wenn neue Features hinzugefügt werden. Sie können Spalten, Tabellen, Ansichten oder gespeicherte Prozeduren hinzufügen oder entfernen. Es können auch wichtige Daten vorhanden sein, die der Entwicklungsdatenbank hinzugefügt werden. Viele datengesteuerte Anwendungen umfassen Nachschlagetabellen, die mit hartcodierten, anwendungsspezifischen Daten gefüllt sind, die nicht vom Benutzer bearbeitet werden können. Beispielsweise könnte eine Auktionswebsite eine Dropdownliste mit Auswahlmöglichkeiten haben, die den Zustand des Versteigerungselements beschreiben: Neu, Like New, Good und Fair. Anstatt diese Optionen direkt in der Dropdownliste zu codieren, ist es in der Regel besser, sie in einer Datenbanktabelle zu platzieren. Wenn während der Entwicklung eine neue Bedingung namens "Poor" zur Tabelle hinzugefügt wird, muss beim Bereitstellen der Anwendung dieser Datensatz der Nachschlagetabelle in der Produktionsdatenbank hinzugefügt werden.

Im Idealfall würde die Bereitstellung der Datenbank das Kopieren der Datenbank von der Entwicklung in die Produktion umfassen. Denken Sie jedoch daran, dass nach der Bereitstellung der Anwendung und der fortgesetzten Entwicklung die Produktionsdatenbank mit echten Daten von echten Benutzern aufgefüllt wird. Wenn Sie daher die Datenbank einfach aus der Entwicklung in die Produktion bei der nächsten Bereitstellung kopieren würden, würden Sie die Produktionsdatenbank überschreiben und die vorhandenen Daten verlieren. Das Nettoergebnis besteht darin, dass die Bereitstellung der Datenbank auf das Anwenden der Änderungen, die seit der letzten Bereitstellung an der Entwicklungsdatenbank vorgenommen wurden, reduziert.

Da die Bereitstellung einer Datenbank das Anwenden der Änderungen im Schema und ggf. die Daten seit der letzten Bereitstellung umfasst, muss ein Verlauf der Änderungen beibehalten (oder zur Bereitstellungszeit bestimmt werden), damit diese Änderungen auf die Produktion angewendet werden können. Es gibt eine Vielzahl von Techniken zum Verwalten und Anwenden von Änderungen am Datenmodell.

Definieren des Basisplans

Um die Änderungen an der Anwendungsdatenbank beizubehalten, müssen Sie einen Anfangszustand haben, einen Basisplan, auf den die Änderungen angewendet werden. Bei einem extrem hohen Anfangszustand kann es sich um eine leere Datenbank ohne Tabellen, Ansichten oder gespeicherte Prozeduren handeln. Ein solcher Basisplan führt zu einem großen Änderungsprotokoll, da es die Erstellung aller Datenbanktabellen, Ansichten und gespeicherten Prozeduren sowie alle Änderungen umfassen muss, die nach der ersten Bereitstellung vorgenommen wurden. Am anderen Ende des Spektrums könnten Sie den Basisplan als Version der Datenbank festlegen, die ursprünglich in der Produktionsumgebung bereitgestellt wird. Diese Auswahl führt zu einem wesentlich kleineren Änderungsprotokoll, da sie nur die Änderungen enthält, die an der Datenbank nach der ersten Bereitstellung vorgenommen wurden. Dies ist der Ansatz, den ich bevorzugen. Und natürlich können Sie eine ausgewogenere Herangehensweise wählen und den Ausgangspunkt als einen Punkt zwischen der anfänglichen Erstellung der Datenbank und dem Zeitpunkt der ersten Bereitstellung der Datenbank definieren.

Nachdem Sie einen Basisplan ausgewählt haben, sollten Sie ein SQL-Skript generieren, das ausgeführt werden kann, um die Basisplanversion neu zu erstellen. Ein solches Skript ermöglicht es, die Basisplanversion der Datenbank schnell neu zu erstellen. Diese Funktionalität ist besonders bei größeren Projekten nützlich, bei denen es möglicherweise mehrere Entwickler gibt, die an dem Projekt arbeiten, oder zusätzliche Umgebungen, z. B. Tests oder Staging, die jeweils eine eigene Kopie der Datenbank benötigen.

Es stehen verschiedene Tools zur Verfügung, um ein SQL-Skript der Basisplanversion zu generieren. In SQL Server Management Studio (SSMS) können Sie mit der rechten Maustaste auf die Datenbank klicken, zum Untermenü "Aufgaben" wechseln und die Option "Skripts generieren" auswählen. Dadurch wird der Skript-Assistent gestartet, den Sie anweisen können, eine Datei zu generieren, die die SQL-Befehle zum Erstellen der Datenbankobjekte enthält. Eine weitere Option ist der Datenbankveröffentlichungs-Assistent, der die SQL-Befehle generieren kann, um nicht nur das Datenbankschema zu erstellen, sondern auch die Daten in den Datenbanktabellen. Der Datenbankveröffentlichungs-Assistent wurde im Tutorial zum Bereitstellen einer Datenbank detailliert behandelt. Unabhängig davon, welches Tool Sie verwenden, sollten Sie letztendlich über eine Skriptdatei verfügen, die Sie verwenden können, um die Basisversion Ihrer Datenbank neu zu erstellen, falls dies erforderlich ist.

Dokumentieren der Datenbankänderungen in Prosa

Die einfachste Möglichkeit, ein Protokoll von Änderungen am Datenmodell während der Entwicklungsphase zu verwalten, besteht darin, die Änderungen in Prose aufzuzeichnen. Wenn Sie beispielsweise während der Entwicklung einer bereits bereitgestellten Anwendung eine neue Spalte zur Employees Tabelle hinzufügen, eine Spalte aus der Orders Tabelle entfernen und eine neue Tabelle hinzufügen (ProductCategories), würden Sie eine Textdatei oder ein Microsoft Word-Dokument mit dem folgenden Verlauf verwalten:

Es gibt eine Reihe von Nachteilen für diesen Ansatz. Zunächst einmal gibt es keine Hoffnung auf Automatisierung. Jedes Mal, wenn diese Änderungen auf eine Datenbank angewendet werden müssen – z. B. wenn die Anwendung bereitgestellt wird – muss ein Entwickler jede Änderung einzeln manuell implementieren. Wenn Sie außerdem eine bestimmte Version der Datenbank unter Verwendung des Änderungsprotokolls rekonstruieren müssen, dauert dies immer mehr Zeit, je größer das Protokoll wird. Ein weiterer Nachteil dieser Methode ist, dass die Klarheit und Detailebene jedes Änderungsprotokolleintrags der Person, die die Änderung erfasst, überlassen wird. In einem Team mit mehreren Entwicklern können einige detailliertere, besser lesbare oder präzisere Einträge als andere machen. Außerdem sind Tippfehler und andere menschlichen Dateneingabefehler möglich.

Der Hauptvorteil der Dokumentation der Datenbankänderungen in Prose ist die Einfachheit. Sie benötigen keine Kenntnisse mit der SQL-Syntax zum Erstellen und Ändern von Datenbankobjekten. Stattdessen können Sie die Änderungen in Prose aufzeichnen und über die grafische Benutzeroberfläche von SQL Server Management Studio implementieren.

Die Verwaltung eines Änderungsprotokolls in Prosa ist zugegebenermaßen nicht sehr anspruchsvoll und funktioniert nicht gut bei Projekten, die von großem Umfang sind, häufige Änderungen am Datenmodell erfordern oder mehrere Entwickler umfassen. Aber ich habe gesehen, dass dieser Ansatz recht gut in kleinen Ein-Mann-Projekten funktioniert, die nur gelegentlich Änderungen am Datenmodell haben und wo der Soloentwickler keinen starken Hintergrund in der SQL-Syntax zum Erstellen und Ändern von Datenbankobjekten hat.

Aufzeichnen der SQL-Änderungsanweisungen

Der Hauptnachteil der Aufrechterhaltung des Änderungsprotokolls in Prose ist der Mangel an Automatisierung. Im Idealfall wäre die Implementierung der Datenbankänderungen an der Produktionsdatenbank zur Bereitstellung so einfach wie das Klicken auf eine Schaltfläche zum Ausführen eines Skripts, anstatt eine Liste von Anweisungen manuell ausführen zu müssen. Eine solche Automatisierung ist möglich, indem ein Änderungsprotokoll beibehalten wird, das diese SQL-Befehle enthält, die zum Ändern des Datenmodells verwendet werden.

Die SQL-Syntax enthält eine Reihe von Anweisungen zum Erstellen und Ändern verschiedener Datenbankobjekte. Beispielsweise erstellt die CREATE TABLE-Anweisung bei Ausführung eine neue Tabelle mit den angegebenen Spalten und Einschränkungen. Die ALTER TABLE-Anweisung ändert eine vorhandene Tabelle, fügt deren Spalten oder Einschränkungen hinzu, entfernt oder ändert sie. Es gibt auch Anweisungen zum Erstellen, Ändern und Ablegen von Indizes, Ansichten, benutzerdefinierten Funktionen, gespeicherten Prozeduren, Triggern und anderen Datenbankobjekten.

Kehren Sie zu unserem früheren Beispiel zurück, dass Sie während der Entwicklung einer bereits bereitgestellten Anwendung eine neue Spalte zur Employees Tabelle hinzufügen, eine Spalte aus der Orders Tabelle entfernen und eine neue Tabelle (ProductCategories) hinzufügen. Solche Aktionen führen zu einer Änderungsprotokolldatei mit den folgenden SQL-Befehlen:

-- 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])
)

Das Übertragen dieser Änderungen an die Produktionsdatenbank zum Zeitpunkt der Bereitstellung ist ein Klickvorgang: Öffnen Sie SQL Server Management Studio, stellen Sie eine Verbindung mit Ihrer Produktionsdatenbank her, öffnen Sie ein 'Neue Abfrage'-Fenster, fügen Sie den Inhalt des Änderungsprotokolls ein, und klicken Sie auf 'Ausführen', um das Skript auszuführen.

Verwenden eines Vergleichstools zum Synchronisieren der Datenmodelle

Das Dokumentieren von Datenbankänderungen in Prose ist einfach, aber die Implementierung der Änderungen erfordert, dass ein Entwickler jede Änderung an der Produktionsdatenbank einzeln vornehmen muss; Durch das Dokumentieren der Sql-Änderung werden diese Änderungen in der Produktionsdatenbank so einfach und schnell wie durch Klicken auf eine Schaltfläche implementiert, aber zum Erstellen und Ändern von Datenbankobjekten müssen Sie die SQL-Anweisungen und -Syntax erlernen und beherrschen. Datenbankvergleichstools nutzen das Beste aus beiden Ansätzen und verwerfen das Schlechteste.

Ein Datenbankvergleichstool vergleicht das Schema oder die Daten von zwei Datenbanken und zeigt einen Zusammenfassenden Bericht an, der zeigt, wie sich die Datenbanken unterscheiden. Anschließend können Sie mit dem Klicken auf eine Schaltfläche die SQL-Befehle für die Synchronisierung eines oder mehrerer Datenbankobjekte generieren. Kurz gesagt, Sie können ein Datenbankvergleichstool verwenden, um die Entwicklungs- und Produktionsdatenbanken zur Bereitstellung zu vergleichen und eine Datei zu generieren, die die SQL-Befehle enthält, die bei ausführung die Änderungen auf das Schema der Produktionsdatenbank anwenden, sodass es das Schema der Entwicklungsdatenbank widerspiegelt.

Es gibt eine Vielzahl von Drittanbieter-Datenbankvergleichstools, die von vielen verschiedenen Anbietern angeboten werden. Ein solches Beispiel ist SQL Compare, von Red Gate Software. Im Folgenden wird der Prozess der Verwendung von SQL Compare zum Vergleichen und Synchronisieren der Entwicklungs- und Produktionsdatenbankschemas beschrieben.

Wenn sql Compare startet, wird das Dialogfeld "Vergleichsprojekte" geöffnet, in dem die gespeicherten SQL-Vergleichsprojekte angezeigt werden. Erstellen Sie ein neues Projekt. Dadurch wird der Projektkonfigurations-Assistent gestartet, der Informationen zu den zu vergleichenden Datenbanken auffordert (siehe Abbildung 1). Geben Sie die Informationen für die Entwicklungs- und Produktionsumgebungsdatenbanken ein.

Abbildung 1: Vergleichen der Entwicklungs- und Produktionsdatenbanken (Klicken Sie hier, um das Bild in voller Größe anzuzeigen)

Zusätzlich zur Auswahl der zu vergleichenden Datenbanken können Sie auch eine Vielzahl von Vergleichseinstellungen auf der Registerkarte "Optionen" angeben. Eine Option, die Sie aktivieren möchten, ist die Option "Einschränkungs- und Indexnamen ignorieren". Erinnern Sie sich daran, dass wir im vorherigen Lernprogramm die Anwendungsdienste-Datenbankobjekte zu den Entwicklungs- und Produktionsdatenbanken hinzugefügt haben. Wenn Sie das aspnet_regsql.exe Tool zum Erstellen dieser Objekte in der Produktionsdatenbank verwendet haben, werden Sie feststellen, dass sich der Primärschlüssel und eindeutige Einschränkungsnamen zwischen den Entwicklungs- und Produktionsdatenbanken unterscheiden. Daher kennzeichnet SQL Compare alle Anwendungsdiensttabellen als unterschiedlich. Sie können entweder die "Einschränkungs- und Indexnamen ignorieren" deaktiviert lassen und die Einschränkungsnamen synchronisieren oder SQL Compare anweisen, diese Unterschiede zu ignorieren.

Nachdem Sie die zu vergleichenden Datenbanken ausgewählt haben (und die Vergleichsoptionen überprüfen), klicken Sie auf die Schaltfläche "Jetzt vergleichen", um den Vergleich zu starten. Sql Compare untersucht in den nächsten Sekunden die Schemas der beiden Datenbanken und generiert einen Bericht darüber, wie sie unterschiedlich sind. Ich habe absichtlich einige Änderungen an der Entwicklungsdatenbank vorgenommen, um zu zeigen, wie solche Diskrepanzen in der SQL Compare-Schnittstelle angegeben werden. Wie in Abbildung 2 dargestellt, habe ich der Authors-Tabelle eine BirthDate-Spalte hinzugefügt, die ISBN-Spalte aus der Books-Tabelle entfernt und eine neue Tabelle namens Ratings hinzugefügt, die es den Benutzern ermöglicht, die dort überprüften Bücher zu bewerten.

Abbildung 2: SQL Compare listet die Unterschiede zwischen den Entwicklungs- und Produktionsdatenbanken auf (Klicken Sie, um das Bild in voller Größe zu sehen)

SQL Compare unterteilt die Datenbankobjekte in Gruppen, zeigt Ihnen schnell an, welche Objekte in beiden Datenbanken vorhanden sind, aber unterschiedlich sind, welche Objekte in einer Datenbank, aber nicht in der anderen vorhanden sind und welche Objekte identisch sind. Wie Sie sehen können, gibt es zwei Objekte, die in beiden Datenbanken vorhanden sind, aber unterschiedlich sind: die Authors Tabelle, die eine Spalte hinzugefügt hatte, und die Tabelle, die Books entfernt wurde. Es gibt ein Objekt, das nur in der Entwicklungsdatenbank vorhanden ist, nämlich die neu erstellte Ratings Tabelle. Und es gibt 117 Objekte, die in beiden Datenbanken identisch sind.

Wenn Sie ein Datenbankobjekt auswählen, wird das Fenster "SQL-Unterschiede" angezeigt, in dem gezeigt wird, wie sich diese Objekte unterscheiden. Im Fenster "SQL-Unterschiede" (unten in Abbildung 2) wird hervorgehoben, dass die Authors Tabelle in der Entwicklungsdatenbank über die BirthDate Spalte verfügt, die in der Tabelle in der Authors Produktionsdatenbank nicht gefunden wird.

Nachdem Sie die Unterschiede überprüft und ausgewählt haben, welche Objekte synchronisiert werden sollen, besteht der nächste Schritt darin, die SQL-Befehle zu generieren, die erforderlich sind, um das Schema der Produktionsdatenbank entsprechend der Entwicklungsdatenbank zu aktualisieren. Dies erfolgt über den Synchronisierungs-Assistenten. Der Synchronisierungs-Assistent bestätigt, welche Objekte synchronisiert werden sollen, und fasst den Aktionsplan zusammen (siehe Abbildung 3). Sie können die Datenbanken sofort synchronisieren oder ein Skript mit den SQL-Befehlen generieren, die nach Belieben ausgeführt werden können.

Abbildung 3: Verwenden des Synchronisierungs-Assistenten zum Synchronisieren Ihrer Datenbankschemas (Klicken Sie hier, um das Bild in voller Größe anzuzeigen)

Datenbankvergleichstools wie SQL Compare von Red Gate Software machen das Anwenden von Änderungen am Entwicklungsdatenbankschema auf die Produktionsdatenbank ganz einfach per Mausklick.

Offline-Nutzung der Anwendung während der Bereitstellung

Wie wir in diesen Lernprogrammen gesehen haben, ist die Bereitstellung ein Prozess, der mehrere Schritte umfasst: Kopieren der ASP.NET Seiten, Gestaltungsvorlagen, CSS-Dateien, JavaScript-Dateien, Bilder und anderer erforderlicher Inhalte aus der Entwicklungsumgebung in die Produktionsumgebung; Kopieren der konfigurationsspezifischen Konfigurationsinformationen für die Produktionsumgebung bei Bedarf; und anwenden der Änderungen am Datenmodell seit der letzten Bereitstellung. Abhängig von der Anzahl der Dateien und der Komplexität Ihrer Datenbankänderungen können diese Schritte von ein paar Sekunden bis zu mehreren Minuten ausgeführt werden. Während dieses Zeitraums befindet sich die Webanwendung in einem Übergang, und Benutzer, die die Website besuchen, können auf Fehler oder unerwartetes Verhalten stoßen.

Bei der Bereitstellung einer Website ist es am besten, die Webanwendung "offline" zu nehmen, bis die Bereitstellung abgeschlossen ist. Das Herunterfahren der Anwendung (und das anschließende Wiederhochfahren, nachdem der Bereitstellungsprozess abgeschlossen ist) ist so einfach wie das Hochladen einer Datei und deren anschließendes Löschen. Ab ASP.NET 2.0 setzt das bloße Vorhandensein einer Datei app_offline.htm im Stammverzeichnis der Anwendung die gesamte Website "offline". Jede Anforderung an eine ASP.NET-Seite auf dieser Website wird automatisch mit dem Inhalt der app_offline.htm-Datei beantwortet. Sobald diese Datei entfernt wurde, wird die Anwendung wieder online angezeigt.

Wenn Sie eine Anwendung während der Bereitstellung offline schalten, ist dies einfach wie das Hochladen einer app_offline.htm Datei in das Stammverzeichnis der Produktionsumgebung vor beginn des Bereitstellungsprozesses und anschließendes Löschen (oder Umbenennen einer Datei in etwas anderes), sobald die Bereitstellung abgeschlossen ist. Weitere Informationen zu dieser Technik finden Sie im Artikel von John Peterson unter "Erstellen einer ASP.NET Anwendung offline".

Zusammenfassung

Die wichtigste Herausforderung bei der Bereitstellung einer datengesteuerten Anwendung konzentriert sich auf die Bereitstellung der Datenbank. Da es zwei Versionen der Datenbank gibt – eine in der Entwicklungsumgebung und eine in der Produktionsumgebung – können diese beiden Datenbankschemas nicht mehr synchronisiert werden, da neue Features in der Entwicklung hinzugefügt werden. Was mehr ist, da die Produktionsdatenbank mit echten Daten von realen Benutzern gefüllt wird, können Sie die Produktionsdatenbank nicht mit der geänderten Entwicklungsdatenbank überschreiben, z. B. wenn Sie die Dateien bereitstellen, aus denen die Anwendung besteht (die ASP.NET Seiten, Bilddateien usw.). Die Bereitstellung einer Datenbank erfordert stattdessen die Implementierung der genauen Änderungen, die seit der letzten Bereitstellung an der Entwicklungsdatenbank in der Produktionsdatenbank vorgenommen wurden.

In diesem Lernprogramm wurden drei Techniken zum Verwalten und Anwenden eines Protokolls von Datenbankänderungen behandelt. Der einfachste Ansatz besteht darin, die Änderungen in Prose aufzuzeichnen. Diese Taktik führt zwar die Implementierung dieser Änderungen in der Produktionsdatenbank zu einem manuellen Prozess durch, erfordert jedoch keine Kenntnisse der SQL-Befehle zum Erstellen und Ändern von Datenbankobjekten. Ein anspruchsvollerer Ansatz, der in größeren Projekten oder Projekten mit mehreren Entwicklern viel angenehmer ist, besteht darin, die Änderungen als eine Reihe von SQL-Befehlen aufzuzeichnen. Dadurch wird die Einführung dieser Änderungen an der Zieldatenbank erheblich vereinfacht. Das Beste aus beiden Ansätzen kann mithilfe eines Datenbankvergleichstools erreicht werden, wie z. B. Red Gate Software s SQL Compare.

Dieses Lernprogramm schließt unseren Fokus auf der Bereitstellung einer datengesteuerten Anwendung ab. Die nächste Reihe von Lernprogrammen befasst sich mit der Reaktion auf Fehler in der Produktionsumgebung. Wir sehen uns an, wie statt des Gelben Bildschirms des Todes eine freundliche Fehlerseite angezeigt wird. Außerdem erfahren Sie, wie Sie die Fehlerdetails protokollieren und wie Sie benachrichtigt werden, wenn solche Fehler auftreten.

Glückliche Programmierung!