martinbulinski.de

Wie werde ich PL/SQL Entwickler? Drucken E-Mail
  
Donnerstag, 12. Februar 2009 um 19:35

Während meiner Tätigkeit als Referent zu verschiedensten ORACLE-Themen begegnet mir natürlich das verschiedenste Klientel. Das ist auch gut so. Hätte ich nicht den Austausch mit Teilnehmern und den unterschiedlichsten Anforderungen, würde der Job keinen Spass machen und ich würde keinen guten Job machen. Nun begegnen mir aber auch Menschen mit den verschiedensten Vorkenntnissen, die sich mit ORACLE beschäftigen wollen oder müssen. Den typischen PL/SQL-Lerner möchte ich näher beleuchten, man mag es mir nicht übel nehmen.

 

Ich habe keine Programmiererfahrung und PL/SQL ist meine erste Programmiersprache

Herzlichen Glückwunsch, der Ansatz ist zum Scheitern verurteilt: PL/SQL ist definitiv keine Einsteiger-Sprache. Hier geht es um fortgeschrittene Konzepte wie Cursor und eine enge Integration mit SQL. Kenntnisse in dieser Programmiersprache lohnen sich nur, wenn man 1. viel mit relationalen Datenbanken zu tun hat und 2. mit ORACLE zu tun hat, denn nur hier existiert PL/SQL. Bitte besuchen Sie einen Kurs "Grundlagen der Programmierung", dann "SQL für Einsteiger", dann "SQL für Fortgeschrittene" und dann vielleicht "PL/SQL"

Ich bin Entwickler, meine Heimat ist C/C++/Java/Fortran/Cobol/ABAP(das wären gute Voraussetzungen) und ich soll PL/SQL lernen

Hier wird es spannend. Den Weg zum PL/SQL-Entwickler möchte ich in verschiedene Phasen unterteilen.

Phase 0:

Sie haben Kenntnisse in prozeduralen, funktionalen oder logischen Programmiersprachen. Mehrdimensionale Arrays, File-I/O, Bäume und Listen sind Ihr Zuhause. Gut. Denken Sie um. Denken Sie mengenorientiert. Lernen Sie SQL, um mit Datenbanken zu interagieren.

Phase 1:

Sie haben einen SQL-Kurs besucht und Sie erkennen den grundlegenden Unterschied zwischen mengenorientierter und prozeduraler Herangehensweise. Sie lächeln milde, wenn Ihnen ein Kollege sagt, er "programmiert in SQL". Sie haben im Anschluss an die Schulung nach dem Begriff "Eulersche Kreise" gegoogelt. Ihnen wird bewußt, dass Sie einer Datenbank nicht erklären müssen, wie sie Daten zu finden hat, sondern welche Daten sie zu finden hat. Ohne ein einziges PL/SQL-Programm schreiben zu können, sind Sie bereits PL/SQL-Entwickler Phase 1. Herzlich Willkommen.

Phase 2:

Sie glauben zu erkennen, dass SQL in Ihrer spezifischen Problemstellung nicht hilft, sind der Ansicht, dass eine Verarbeitung in einer klassischen Schleife mit IF-THEN-ELSE das Problem schnell lösen würde, wenn man dann noch mal schnell in einer anderen LOOKUP-Tabelle nachschaut.

Bitte lernen Sie mehr SQL. Machen Sie sich folgende Begriffe zu eigen: JOIN, INNER JOIN, OUTER JOIN, PARTITION OUTER JOIN, SELF JOIN, CROSS JOIN, MULTI TABLE INSERT und MERGE. Wenn Sie nach diesen Schlüsselworten googeln, ist vielleicht schon ein Teil Ihres Problems gelöst. Und damit sind Sie PL/SQL-Entwickler Phase 2. Das ehrt Sie, denn Sie wissen nun, dass man lange auf PL/SQL verzichten kann und vieles mit SQL erledigt. Je mehr SQL-Kenntnisse Sie erwerben, umso mehr werden Sie Ihre Kollegen beneiden, weil Sie PL/SQL beherrschen. Tun Sie ja gar nicht. Sie haben noch nicht eine Zeile programmiert. Aber Sie lösen Probleme.

Phase 3:

Es ist ein Zeitpunkt erreicht, in dem Sie sich mit SQL nicht mehr zu helfen wissen. Sie wollen Werte berechnen wie Fakultaet, Reihen und Folgen. Sie wollen dynamisch die nächsten 30 Kalendertage liefern, weil ein PHP-Entwickler Sie darum bittet. Sie benötigen statistische Daten, vondenen Sie glauben, das nur Sie diese errechnen können. Kumulierte Populationsdichten-Varianz oder ähnlich schwieriges Zeug. Sie sind nun ein Phase-3-PL/SQL-Entwickler, denn Sie beschäftigen sich jetzt (bitte) mit CONNECT BY LEVEL < X, ROWNUM und ganz wichtig: analytischen Funktionen.

Phase 4:

Sie haben als Phase-3-PL/SQL-Entwickler alle Möglichkeiten ausgeschöpft und wundern sich, warum Sie sich PL/SQL-Entwickler nennen dürfen ohne die Sprache PL/SQL zu kennen. Sie suchen nach Automations-Möglichkeiten, haben Probleme mit grossen Batch-Aktivitäten, müssen Aktionen in der DB überwachen oder wollen einfach modularisieren. Sie sind jetzt an einer Stelle angelangt, wo sich der Besuch eines Pl/SQL-Kurses lohnt.

Phase 5:

Der PL/SQL-Kurs ist besucht, Sie verfallen trotzdem nicht in die alten Programmiermuster, sondern sind sich der Interaktion von SQL und PL/SQL bewusst. Sie sind aber nach wie vor der Meinung, auf PL/SQL nicht verzichten zu können. Jetzt beginnt die Suche nach vielleicht folgenden Schlüsselworten: REF CURSOR, AUTONOMOUS TRANSACTION, NOCOPY, EXECUTE IMMEDIATE, BIND VARIABLES und so weiter.

Phase 6:

Sie haben Phase 5 beendet, vielleicht sogar ohne externe Hilfe, und suchen nun nach Herausforderungen. Jetzt fängt die Arbeit mit den von ORACLE gelieferten Packages an. UTL_FILE, DBMS_REDEFINITION, DBMS_LOGMNR, DBMS_CRYPTO, UTL_COMPRESS, DBMS_RLS, DBMS_FGA und viele, viele weitere.
Sie erkennen Performance-Probleme und suchen daher nach Schlüsselworten wie WHERE CURRENT OF oder FORALL.

Phase 7:

Sie kennen PL/SQL aus dem Eff-Eff und alle relevanten Packages sind Ihnen bekannt (UTL_MAIL etc.).
Jetzt ist es Zeit, über Tuning nachzudenken. Sie werden in Ihrem Denken eventuell furchtbar zurückgeworfen, weil Sie erst jetzt wirklich erkennen, dass der Performance-Benefit in erster Linie auf SQL-Seite auswirkt. Trotzdem wollen Sie Ihre Programme verbessern. Jetzt rufen Sie mich an.

 

 

 

 

 

Aktualisiert ( Donnerstag, 16. April 2009 um 07:44 )
 
Benutzerbewertung: / 10
SchwachPerfekt 

Kommentar schreiben


Sicherheitscode
Aktualisieren

Anmeldung



Wer ist online

Wir haben 10 Gäste online