Online Suche im Handbuch

56. Frontends und Cursor unter MySQL

Cursor erhöhen bei Anwndungsprogrammen erheblich den Komfort bei der Datenerfassung und der Änderung. In vielen Fällen sind diese einfach unentbehrlich. Man findet häufig die Aussage, daß Cursor unter MySQL nicht unterstützt werden. Das ist zwar richtig, aber man muß auch dazu sagen, daß Cursor und deren Implementierung noch Fossile aus der Vergangenheit sind, wo Mainframes mit ThinClients noch Standard waren. Heutzutage gibt es kaum noch ThinClients, sodaß z.B. Serverside Cursor nicht mehr notwendig sind. Mit Hilfe von ThickClients, also normalen PC´s unter Microsoft Windows kann man völlig ohne serverside cursors komfortabelste Anwendungen schreiben. Es ist inzwischen völlig egal, welche Datenbank hinter den Frontends (ACCESS, JAVA RMI....JDBC, ODBC) steht, da die intelligenten Frontends z.B. Cursor und Caching selber verwalten. Die SQL Datenbank steuert nur die durch SELECT angeforderten result sets bei und übergibt diese an den Client. Probleme, wie Scrollig u.s.w. übernimmt der das Frontend. Allen voran ist ACCESS sicher dasjenige Frontend, die es einem Anwender ohne Programmierkenntnissen es ermöglicht, eigene Frontends für Datenbanken zu erstellen (Ich selber habe ca. 1 Tag Einarbeitung gebraucht ...).

Verfechter der individuell programmierten Frontends, die von den komplexen serverside cursors Gebrauch machen, werden immer einsamer.

Cursor sind eine komplexe Angelegenheit. Es gibt Serverside, Clientside, Forward-Only .... Cursor. Danach ist es eine Frage des Anwendungs-Interfaces, also den Fähigkeiten des ODBC-Treibers oder JDBC Treibers. MyODBC unterstützt in Verbindung mit Microsoft Applikationen clientside cursors, auch als front-end cursors beschrieben. Diese funktionieren mit allen Microsoft Anwendungen und Programmiersprachen. Serverside Cursor werden von MySQL nicht unterstützt, da diese oft erhebliche Performanceprobleme auf dem Server machen. Bei vielen simultanen Clients, wie sie oft im Internet auftreten können, sind Serverside Cursor das Ende jeder SQL Datenbank. Der Grund dafür liegt einfach darin, daß alle Statements über einen Postprozessor der Datenbank laufen, der dann die Cursor mit der Ausgabe der Statements verknüpft, und daraufhin entscheidet, welche Daten dem Client übermittelt werden. Das kostet Auslagerungsspeicher und viel CPU-Zeit. Clientside Cursor schonen erheblich Serverresourcen, da diese neuerdings Caching - Mechanismen unterstützen. Bei Internet-Anwendungen sind also in jedem Falle eine hochkarätige Datenbank, wie z.B. ORACLE, SYSBASE oder MS-SQL mit serverside cursors völlig ungeeignet. Unter JDBC gibt es ebenfalls clientside cursor für MySQL, die auch völlig problemlos funktionieren. Einige Hersteller bieten für MySQL erweiterte Bibliotheken an, die erhebliche Erweiterungen und Vorteile gegenüber den RMI JDBC Bibliotheken von SUN bieten.

Online Suche im Handbuch