[ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ]

Zusammenfassung

In dieser "all in one" Session werden alle notwendigen SQL Server Grundlagen rund um den Enterprise Manager, den Profiler, den Query Analyzer, sowie über Constraints und Triggers vermittelt, um mit VFP effiziente C/S Anwendungen entwickeln zu können. Es wird aufgezeigt, wie eine C/S Lösung gleichzeitig mit Remote Views und SQL Pass Through (kurz: SPT) transaktional aufgebaut werden kann. Es wird erläutert, wie mehrere updatable Remote Views in ein und denselben Transaktionsprozess zu integrieren sind. Es wird dargelegt, welche allgemeinen Fehler bei der C/S Entwicklung vermieden werden müssen, um eine gute Performance zu erzielen. Es wird gezeigt, wie man seine C/S Anwendung ohne DSN Einträge verteilen kann. Schliesslich wird anhand des VFP C/S Frameworks Visual Extend aufgezeigt, wie eine C/S Lösung grundsätzlich aufgebaut sein kann und wie die Notwendigkeiten einer C/S Lösung mit den aus der Fileserver Entwicklung her bekannten Leistungsmerkmalen zu einer attraktiven Gesamtlösung verbunden werden können. Ebenfalls am Beispiel einer Visual Extend C/S Anwendung wird aufgezeigt, wie Remote Views und SQL Pass Through in der Praxis koexistieren können und wie jeweils das Beste aus beiden Ansätzen für die eigene C/S Anwendung verwendet werden kann. Auch wird aufgezeigt, wie selbst bei Verwendung von mehreren Views für ein und dasselbe Form, nicht alle Views in der Datenumgebung des Forms geöffnet werden müssen.

Einleitung

Jeder Entwickler, der in der Vergangenheit mit Fileserver basierten Systemen, wie z.B. dbf Dateien, gearbeitet hat, kommt irgendwann an einen Punkt, wo er sich fragt, ob ein Einsatz einer Client/Server Struktur nicht sinnvoll wäre. Die Gründe die einen Entwickler in diese Situation bringen, können unterschiedlich sein. Eigentlich ist es unerheblich, weshalb der Entwickler damit konfrontiert wird. Was wirklich zählt, ist das Verständnis, weshalb eine Client/Server (Abkürzung: C/S) Architektur einer Fileserver (Abkürzung: F/S) Architektur vorzuziehen ist und wann diese Vorteile zum Tragen kommen. Im ersten Teil dieses Beitrages werden dann auch die grundlegenden Unterschiede zwischen einer Fileserver und einer C/S basierten Anwendungsarchitektur beschrieben.

Um dem Ganzen von Beginn weg einen Praxisbezug zu verleihen, wird mit xCase ein Datenmodell erstellt, welches auf SQL Server 7.0 appliziert wird. Hierbei werden im Speziellen auch die Datums und Numerischen Datentypen angesprochen. Dies deshalb, weil bereits hier sehr oft Fragen unbeantwortet bleiben. Ebenfalls werden alle notwendigen SQL Server 7.0 Grundlagen rund um den Enterprise Manager, den Profiler, den Query Analyzer, sowie über Constraints und Triggers vermittelt, um mit VFP effiziente C/S Anwendungen entwickeln zu können. In Analogie zur Rushmore Optimierung bei VFP Anwendungen wird gezeigt, wie beim SQL Server das Prüfen auf optimierte Queries mit dem SQL Server Execution Plan erfolgt.

Sehr oft stellt sich zu einem späteren Zeitpunkt die Frage, ob bei einer VFP Client/Server Lösung gleichzeitig mit Remote Views und SQL Pass Through (kurz: SPT) transaktional gearbeitet werden kann. Zu diesem Zweck werden zunächst die Grundlagen von SQL Server Transaktionen erläutert. Insbesondere werden die im Zusammenhang mit Transaktionen bekannte "ACID" Rule, sowie die SQL Server "Isolation Levels" erläutert und anschaulich erklärt, welche Auswirkungen das Auslösen von Transaktionen auf dem SQL Server hat. Es wird zudem aufgezeigt, wie mehrere updatable Remote Views in ein und denselben Transaktionsprozess zu integrieren sind. Am Beispiel einer Visual Extend Client/Server Anwendung wird aufgezeigt, wie Remote Views und SQL Pass Through in der Praxis koexistieren können und wie jeweils das Beste aus beiden Ansätzen für die eigene Client/Server Anwendung verwendet werden kann. Diese Ausführungen eignen sich auch für diejenigen, welche in die n-Tier Entwicklung unter Microsoft Transaction Server einsteigen wollen und sich hierzu das nötige Grundverständnis bzgl. Transaktionen aneignen wollen.

Client/Server Entwicklungen drängen sich nicht nur wegen Performance Überlegungen auf. Dennoch spielt in der heutigen IT Landschaft die Performance einer Client/Server Lösung eine entscheidende Rolle. Performance wird hierbei als Gradmesser für die Geschwindigkeit verstanden, mit welcher der Benutzer einer Software seine Arbeit erledigen kann. Es wird aufgezeigt, welche allgemeinen Fehler bei der Client/Server Entwicklung vermieden werden müssen, um eine gute Performance zu erzielen. Am Beispiel des Client/Server Frameworks Visual Extend wird aufgezeigt, dass selbst bei Verwendung von mehreren Views für ein und dasselbe Form, nicht alle Views in der Datenumgebung des Forms geöffnet werden müssen. Auch wird darauf hingewiesen, wie für Auswahllisten und Comboboxen resourcenschonend gearbeitet werden kann, um die Gesamtperformance zu verbessern.

Anhand des VFP/Client/Server Frameworks Visual Extend wird aufgezeigt, wie eine Client/Server Lösung grundsätzlich aufgebaut sein kann und wie die Notwendigkeiten einer Client/Server Lösung mit den aus der Fileserver Entwicklung her bekannten Leistungsmerkmalen zu einer attraktiven Gesamtlösung verbunden werden können.

Arbeiten mehrere Anwender einer Anwendung mit ein und demselben VFP Datenbankcontainer ergibt sich rasch das Problem, dass die Connection Informationen, falls benutzerspezifisch (und dies ist bei nicht trusted Umgebungen der Fall) für jeden Benutzer angepasst werden müssen. Statt den Aufwand individuelle DBC's zu erstellen, stelle ich einen Lösungsweg dar, der durch Einfachheit besticht.

Grundlagen der C/S Entwicklung

Ich werde an der Session nicht detailliert auf diese Grundlagen eingehen, lasse diese dennoch der Vollständigkeit halber in den Session Notes.

Client/Server vs. Fileserver

Wir alle waren in der Zeit der File basierten Datenbanken à la FoxPro sehr verwöhnt. Wir haben uns mit der Frage, welche Daten dem Anwender in einer Applikation präsentiert werden, nicht unbeding auseinandersetzen müssen. Zumindest konnten wir uns vor dieser Frage etwas drücken und die Vorteile eines Index Sequentiellen Dateisystems, wie FoxPro e ines ist, zu unserem Vorteil nutzen. In einer File Server basierten Lösung stehen uns durch das öffnen einer Tabelle die darin enthaltenen Datensätze uneingeschränkt zur Verfügung. Ein "Locate" oder "Seek" genügt, um auf einen bestimmten Datensatz zu positionieren. Man spricht in diesem Zusammenhang deshalb oft auch von einer "Seek" basierten Umgebung.

Alle File basierten Datenbankanwendungen haben u.A. jedoch leider immer wieder mit demselben Grundproblem zu kämpfen: Bei steigender Benutzerzahl und grösser werdenden Indexdateien wird die resultierende Netzwerkbelastung immer höher. Stellt man sich vor, dass viele Benutzer gleichzeitig eine Datei mit einer 20MB grossen Index Datei wiederholt öffnen und darauf zugreifen, wird einem bewusst, welche Netzwerkbelastung dadurch entsteht. VFP muss nämlich für jeden Benutzer, der eine Tabelle öffnet, den ganzen aktiven Index Tag über das Netzwerk herunterladen. Deshalb sind auch die CDX Dateien in VFP komprimiert. Tatsache ist, dass VFP, genauso wie alle Fileserver Datenbanken, über keinerlei Server Intelligenz verfügt, alles, wirklich alles, erfolgt im Arbeitsspeicher der Arbeitsstation! Egal ob Rushmore zur Anwendung gelangt oder nicht, sobald direkt auf "dbf" Dateien zugegriffen wird, hat man erneut eine entsprechende Netzbelastung, da grundsätzlich alles in den Arbeitsspeicher des Benutzer runtergeladen werden muss bevor damit etwas angefangen werden kann.

Der grundsätzlichste Unterschied zwischen einer Client/Server Umgebung und einer "Seek" basierten Umgebung besteht darin, dass in einer Client/Server Umgebung die Daten durch den Client immer zuerst beim Server angefordert werden müssen. Somit stellt sich die Frage "welche Daten zu beziehen sind" unweigerlich und in allererster Instanz. Da die verwendete normierte Abfragesprache in diesem Zusammenhang SQL (Structured Query Language) ist, spricht man auch von einer "SQL" basierten Umgebung.

Datenumgebungen bei C/S vs. Fileserver

Wenn wir die Datenumgebung eines Forms aus einer Fileserver Umgebung mit derjenigen aus einer Client/Server Umgebung vergleichen, fällt uns zunächst nichts besonderes auf. Auf den zweiten Blick sind es aber gerade die Relationen zwischen den einzelnen Tabellen, welche bei der Fileserver Umgebung unsere Aufmerksamkeit verdienen sollten. Das explizite Vorhandensein aller relational verbundenen Tabellen ist ein sehr wichtiger Sachverhalt. Sind es doch gerade die Tabellen, welche in der Datenumgebung einer Fileserverumgebung auftauchen, welche zu der eingangs erwähnten Performance Problematik beim Öffnen des Forms führen.

Beispiel einer Datenumgebung eines Forms bei einer Fileserver Umgebung:

Im Gegensatz dazu ist bei derselben Funktionalität bei einem Client/Server Form die Datenumgebung "leichter":

Statt Relationen in der Datenumgebung finden wir die "Table Joins" in der View Definition:

Der aber wirklich alles entscheidende Unterschied liegt hierbei darin, dass diese "Joins" auf dem Server abgewickelt werden und überhaupt keinen Einfluss auf die Netzbelastung oder die Rechenleistung des Arbeitsplatzes haben.

Wenn man diesen fundamentalen Unterschied einmal "verinnerlicht" hat, versteht man, dass die Vorteile einer Trennung zwischen dem Client und dem Daten Tier absolut Sinn macht! Man freut sich dann jedesmal entsprechend, wenn man dem Daten Tier wieder mal einen Haufen Arbeit (in Form von komplexen SQL Abfragen über mehrere Tabellen) zuschaufeln kann.

C/S Datenmodellierung

Der SQL Server Enterprise Manager bietet grundsätzlich alle Möglichkeiten, eine Datenbank aufzusetzen, Tabellen zu definieren, Indices aufzusetzen sowie Constraints, Rules und Triggers zu implementieren. In der SQL Server Books Online Dokumentation finden sich hierzu genügend Informationen, so dass ein Verweis auf diese Referenz an dieser Stelle genügt.

Für diejenigen, welche xCase bereits für die Datenmodellierung ihrer VFP Datanbanken verwendet haben, ist es ein Leichtes, dasselbe Tool, mitlerweile in der Version 5.5, auch für SQL Server 7.0 einzusetzen.

Erstellen der Datenbank aus dem Enterprise Manager

Obwohl es auch aus xCase heraus möglich ist, die Datenbank physisch auf dem SQL Server anzulegen, ziehe ich es vor, diesen Schritt im SQL Server Enterprise Manager zu bewerkstelligen. Da bei MSDE Implementationen kein Enterprise Manager zur Verfügung steht, muss man für die Distribution der MSDE basierten Anwendung ein wenig anders vorgehen, ich werde dies am Ende der Session noch kurz anschneiden. Soviel sei aber schon einmal verraten: auch eine MSDE Datenbank Installation kann von einem beliebigen Enterprise Manager im Netz administriert werden, hierzu genügt es, den entsprechenden Server zu registrieren!