APEX-AT-WORK no image
Tags:

APEX sei ein langsames Tool

Von Tobias Arnhold 11.14.2013
Nachdem ich den Blogpost von Joel Kallman gelesen habe, dachte ich mir ein paar eigene Erfahrungen zum Thema APEX und Performance beizutragen.

Die Aussage APEX sei ein langsames inperformantes Tool, ist einfach nur FALSCH!
Wenn jemand ein Auto mit angezogener Handbremse fährt, dann liegt die langsame Geschwindigkeit nicht am Auto sondern am Fahrer.
Wenn ich in meiner APEX Anwendung inperformanten PL/SQL, SQL oder JS Code einbaue, dann liegt es nicht an APEX sondern an mir, der die internen Funktionalitäten nicht versteht. Der Aussage lieber in Oracle Skills statt in APEX Skills zu investieren kann ich nur beipflichten. Wobei ich statt Oracle Skills eher die SQL Skills im Vordergrund sehe.

In meiner Zeit als Festangestellter und als Freelancer habe ich mit verschiedensten APEX Versionen in unterschiedlichsten Hardware Umgebungen gearbeitet.
Von einer virtuellen 1 CPU Umgebung bis hin zur Exadata war alles dabei. Die inhaltlichen Anforderungen waren bei den LowCost Systemen teilweise anspruchsvoller als in den High Performance Umgebungen.

Wo liegt nun der Schlüssel zum Erfolg?
Meiner Meinung nach in weniger PL/SQL und vielmehr in guten SQL, durchdachter Konzeption und der Verwendung von möglichst viel APEX Standard Funktionalität! 
Die meisten komplexen PL/SQL Themen kann ich mit Hilfe von Oracle Standard SQL Funktionen lösen. Beispiel: "Analytische Funktionen"

Ich meine, Sie arbeiten mit einer der schnellsten Datenbanksoftware auf dem Markt.
Was kann diese am Besten? SQL.

Natürlich ist und bleibt ein erheblicher Erfolgsfaktor einer jeden APEX Lösung, die notwendige Konzeptarbeit am Anfang eines jeden Projektes zu leisten. Da kann auch das Beste SQL schnell zum scheitern Verurteilt sein. Folgende Fragen sollten dabei immer in Betracht gezogen werden?

Was mache ich eigentlich für ein Projekt: OLTP oder OLAP? 
Wie komplex sind die Tabellenstrukturen?
Wie sieht das Mengengerüst aus ?
Wie viele Datensätze werden die Tabellen haben?
Kann ich eventuell Daten auch redundant abspeichern?
Wird das System auf Dauer erheblich mehr Datensätze generieren?
Wenn ja, wie viele? Welche Tabellen sind betroffen? Benötige ich spezielle Tests?
Sind Bottlenecks erkennbar?
Welche Schnittstellen müssen integriert/geschaffen werden?
Gibt es bereits Erfahrungen mit diesen Schnittstellen?
Werden sich auch nach Fertigstellung der Anwendung häufig die Anforderungen ändern?
Haben schon andere Entwickler versucht die Anforderungen umzusetzen? Wenn ja, dann gilt es hier besonders zu Glänzen. :) ...und den Kunden nicht wieder zu enttäuschen.

Statt sich einzig und allein an Vorstudien oder Konzepten zu orientieren, sollte der Kontakt zum Kunden gesucht werden.

Warum?
Die meisten Dokumente die den Inhalt einer neuen Anwendung transportieren sollen, hören dabei immer bei den komplexen Themen auf Antworten zu liefern. Nur die Fachverantwortlichen können einem frühzeitig mit entsprechenden Hinweisen aufkommende Probleme erkennen lassen.
Außerdem kann der Kunde so frühzeitig auf visuelle und funktionale Entscheidungen einwirken.

Nur weil jeder mit APEX sehr schnell Lösungen generieren kann, heißt dies nicht, dass jegliche Softwareentwicklungsprinzipien außer Kraft gesetzt werden können und dürfen.





Post Tags: