APEX oder Eigenbau: die Gegenüberstellung entlang der Kriterien, die zählen
Beide Wege führen zu einer funktionierenden Anwendung, sie unterscheiden sich im Tempo bis zur ersten Version, im Betriebsmodell und darin, wer sie später weiterentwickeln kann.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Die Wahl fällt meist aus Gewohnheit, nicht aus Analyse
Der typische Ausgangspunkt ist eine Tabellenkalkulation, die zu wichtig geworden ist. Zwölf Leute pflegen darin Anträge, Geräte oder Zeiten, es gibt keine Rechteverwaltung, keine Historie und regelmäßig zwei Versionen der Datei. Die Anforderung lautet: dasselbe noch einmal, aber mehrbenutzerfähig, nachvollziehbar und mit Auswertungen.
Ab hier entscheidet meist, wer im Raum sitzt. Das Datenbankteam schlägt APEX vor, weil die Daten ohnehin in Oracle liegen. Das Entwicklungsteam schlägt ein eigenes Frontend vor, weil das dem entspricht, was es sonst baut. Beide Antworten können richtig sein, aber die Begründung stammt aus dem Werkzeugkasten und nicht aus der Anforderung.
Die Rechnung kommt nach zwei Jahren. Eine APEX-Anwendung, die niemand mehr anfassen will, weil die PL/SQL-Kenntnisse mit einer Person gegangen sind, ist genauso teuer wie eine eigene Anwendung, deren Frontend-Abhängigkeiten seit drei Jahren nicht aktualisiert wurden und die niemand mehr baut, ohne eine Woche zu verlieren.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Die sechs Kriterien, an denen die Entscheidung wirklich hängt
Oracle APEX
Deklarative Anwendungsentwicklung in der Datenbank, ausgeliefert über ORDS, mit fertigen Bausteinen für Formulare, Berichte, Suche und Rechteverwaltung.
Eigenentwicklung
Eigenes Frontend gegen eine REST-Schnittstelle, freie Wahl von Technik und Betrieb, dafür volle Verantwortung für Aufbau, Auslieferung und Pflege.
| Entscheidungsfrage | Oracle APEX | Eigenentwicklung |
|---|---|---|
| Wie schnell steht eine belastbare erste Version? | Stärke Tabellenpflege, Berichte, Suche und Anmeldung entstehen deklarativ. Für datennahe Masken sind Tage realistisch, wo sonst Wochen anfallen. | Schwäche Vor der ersten Maske stehen Projektaufbau, Authentifizierung, Schnittstelle, Auslieferung und Testaufbau. Dieser Vorlauf rechnet sich erst über die Laufzeit. |
| Wie frei ist die Gestaltung der Oberfläche? | Kommt darauf an Das Universal Theme deckt viel ab und lässt sich über Theme Roller und eigenes CSS anpassen. Ungewöhnliche Bedienkonzepte arbeiten allerdings gegen das Gerüst. | Stärke Jedes Detail ist frei bestimmbar, von der Navigation bis zum Verhalten einzelner Felder. Diese Freiheit muss allerdings jemand gestalterisch ausfüllen. |
| Wie aufwendig ist der Betrieb? | Stärke Es gibt die Datenbank und ORDS als Web-Schicht. Die Anwendung wandert mit der Datenbank, ein eigener Laufzeitstapel entfällt. | Kommt darauf an Auslieferungskette, Laufzeitumgebung und Abhängigkeiten wollen gepflegt werden. Dafür lässt sich die Anwendung unabhängig von der Datenbank skalieren und veröffentlichen. |
| Wie gut lässt sich im Team parallel arbeiten? | Kommt darauf an Der Export als Skript, auch je Komponente, geht in die Versionsverwaltung. Das Zusammenführen paralleler Änderungen an derselben Seite bleibt unangenehm. | Stärke Übliche Werkzeuge für Verzweigungen, Überprüfungen und automatische Tests greifen ohne Umwege, weil der Quelltext von Hand geschrieben ist. |
| Wie eng bindet die Entscheidung an Oracle? | Schwäche Die Anwendung lebt in der Datenbank. Ein Wechsel des Datenbanksystems bedeutet einen Neubau der Oberfläche und nicht nur eine Datenmigration. | Stärke Hinter der Schnittstelle lässt sich die Datenhaltung tauschen, solange die fachliche Logik nicht in datenbankspezifischen Konstrukten vergraben ist. |
| Wer kann die Anwendung später weiterentwickeln? | Stärke SQL- und PL/SQL-Kenntnisse reichen für die meisten Änderungen. Genau diese Kenntnisse sind in Datenbankteams ohnehin vorhanden. | Kommt darauf an Es braucht dauerhaft Frontend-Kenntnisse im Team. Fällt diese Rolle weg, altert die Anwendung schneller als ihre Fachlichkeit. |
Wie schnell steht eine belastbare erste Version?
Tabellenpflege, Berichte, Suche und Anmeldung entstehen deklarativ. Für datennahe Masken sind Tage realistisch, wo sonst Wochen anfallen.
Vor der ersten Maske stehen Projektaufbau, Authentifizierung, Schnittstelle, Auslieferung und Testaufbau. Dieser Vorlauf rechnet sich erst über die Laufzeit.
Wie frei ist die Gestaltung der Oberfläche?
Das Universal Theme deckt viel ab und lässt sich über Theme Roller und eigenes CSS anpassen. Ungewöhnliche Bedienkonzepte arbeiten allerdings gegen das Gerüst.
Jedes Detail ist frei bestimmbar, von der Navigation bis zum Verhalten einzelner Felder. Diese Freiheit muss allerdings jemand gestalterisch ausfüllen.
Wie aufwendig ist der Betrieb?
Es gibt die Datenbank und ORDS als Web-Schicht. Die Anwendung wandert mit der Datenbank, ein eigener Laufzeitstapel entfällt.
Auslieferungskette, Laufzeitumgebung und Abhängigkeiten wollen gepflegt werden. Dafür lässt sich die Anwendung unabhängig von der Datenbank skalieren und veröffentlichen.
Wie gut lässt sich im Team parallel arbeiten?
Der Export als Skript, auch je Komponente, geht in die Versionsverwaltung. Das Zusammenführen paralleler Änderungen an derselben Seite bleibt unangenehm.
Übliche Werkzeuge für Verzweigungen, Überprüfungen und automatische Tests greifen ohne Umwege, weil der Quelltext von Hand geschrieben ist.
Wie eng bindet die Entscheidung an Oracle?
Die Anwendung lebt in der Datenbank. Ein Wechsel des Datenbanksystems bedeutet einen Neubau der Oberfläche und nicht nur eine Datenmigration.
Hinter der Schnittstelle lässt sich die Datenhaltung tauschen, solange die fachliche Logik nicht in datenbankspezifischen Konstrukten vergraben ist.
Wer kann die Anwendung später weiterentwickeln?
SQL- und PL/SQL-Kenntnisse reichen für die meisten Änderungen. Genau diese Kenntnisse sind in Datenbankteams ohnehin vorhanden.
Es braucht dauerhaft Frontend-Kenntnisse im Team. Fällt diese Rolle weg, altert die Anwendung schneller als ihre Fachlichkeit.
Was passt wann
- Die Daten liegen in Oracle, es geht um Formulare, Listen und Auswertungen, und die Fachabteilung wartet seit Monaten.
- APEX. Die erste nutzbare Version steht in Tagen, und die Rechteverwaltung musst du nicht selbst bauen.
- Die Anwendung ist nach außen sichtbar, soll dem eigenen Auftritt folgen und bedient mehrere Quellsysteme.
- Eigenentwicklung mit einer sauberen Schnittstelle davor. APEX müsstest du an zu vielen Stellen überreden.
- Es ist offen, ob die Datenhaltung langfristig bei Oracle bleibt.
- APEX ist möglich, aber schreib die fachliche Logik in Datenbankpakete statt in Seitenprozesse, damit ein späterer Wechsel die Oberfläche kostet und nicht die Fachlichkeit.
Sechs Fragen, die die Wahl entscheiden
- 01 Liegen die Daten dauerhaft fast vollständig in einer Oracle-Datenbank?
- 02 Soll die Oberfläche einem eigenen Gestaltungsanspruch folgen?
- 03 Wer pflegt die Anwendung in drei Jahren, Datenbank- oder Frontend-Team?
- 04 Muss die Anwendung auch ohne Oracle-Datenbank betreibbar bleiben?
- 05 Wie viele Masken sind es, und wie ähnlich sind sie einander?
- 06 Gibt es ungewöhnliche Bedienkonzepte oder Anforderungen an Offline-Nutzung?
Was du nach dieser Seite belastbar entscheiden kannst
Die Gegenüberstellung arbeitet mit Kriterien, die sich vor dem Projekt beantworten lassen. Was du vorher nicht weißt, gehört in einen kleinen Versuch: Bau die schwierigste Maske einmal auf beiden Wegen, das kostet zwei Tage und ersetzt jede Grundsatzdiskussion.
Den Datenschwerpunkt bestimmen
Liegen die Daten fast vollständig in einer Oracle-Datenbank und bleibt das absehbar so, spricht viel für APEX. Kommen mehrere Systeme, Dateien und Fremdschnittstellen zusammen, wandert die Logik ohnehin nach außen.
Den Anspruch an die Oberfläche klären
APEX bringt mit dem Universal Theme ein fertiges, gut zugängliches Grundgerüst mit. Soll eine Marke bis ins Detail durchgestaltet werden oder ist die Bedienung ungewöhnlich, arbeitest du gegen dieses Gerüst statt mit ihm.
Das Betriebsmodell mitdenken
APEX braucht keinen eigenen Applikationsserver für die Anwendungslogik, aber ORDS als Web-Schicht davor. Eine eigenständige Anwendung braucht Auslieferungskette, Laufzeitumgebung und Aktualisierungen für Abhängigkeiten, ist dafür von der Datenbank unabhängig.
Versionierung realistisch bewerten
APEX-Anwendungen lassen sich als SQL-Skripte exportieren, auch je Komponente, und damit in Git verwalten. Das Zusammenführen paralleler Änderungen bleibt trotzdem mühsam, weil die Datei generiert ist. Plan die Arbeitsteilung entlang von Seiten, nicht entlang von Zeilen.
Die Nachfolge klären
Frag konkret, wer die Anwendung in drei Jahren ändert. Eine APEX-Anwendung ist für ein Team mit SQL- und PL/SQL-Kenntnissen zugänglich, eine moderne Web-Anwendung braucht Frontend-Kenntnisse, die im selben Team oft nicht dauerhaft vorhanden sind.
Den Weg nach draußen offen halten
Halt die fachliche Logik in Datenbankpaketen statt in Seitenprozessen, dann bleibt sie nutzbar, falls später ein anderes Frontend davorkommt. Diese eine Disziplin kostet wenig und entschärft die Entscheidung erheblich.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Was APEX tatsächlich ist
APEX ist kein Werkzeug, das Quelltext erzeugt und ausliefert. Die Anwendung besteht aus Metadaten in der Datenbank, und die Laufzeitumgebung baut daraus bei jedem Aufruf die Seite. Deshalb gibt es kein Projektverzeichnis mit Dateien, und deshalb wandert eine Anwendung zusammen mit der Datenbank, wenn du sie umziehst.
Nach außen sichtbar wird das über ORDS, die Oracle REST Data Services. ORDS ist eine Java-Anwendung, die HTTP-Anfragen entgegennimmt und in Datenbankaufrufe übersetzt. In der Ausfallplanung ist das ein eigener Baustein: Steht ORDS nicht, ist die Anwendung nicht erreichbar, auch wenn die Datenbank läuft.
Der Baukasten selbst ist umfangreicher, als der Ruf als Low-Code vermuten lässt. Interaktive Berichte und Interactive Grids geben den Nutzenden Filter, Sortierung, Gruppierung und Export in die Hand, ohne dass du etwas dafür baust. Faceted Search deckt Suchmasken ab, REST-Datenquellen binden fremde Systeme ein. Wo das nicht reicht, schreibst du PL/SQL, und an der Oberfläche ergänzt du JavaScript und CSS.
Wo APEX regelmäßig an Grenzen stößt
Die erste Grenze ist gestalterisch. Solange du im Rahmen des Universal Theme bleibst, geht alles schnell. Sobald ein Entwurf aus einer Designabteilung kommt, der eigene Bedienmuster mitbringt, kippt das Verhältnis: Du verbringst mehr Zeit damit, den Baukasten zu überreden, als du beim Bau der Masken gespart hast.
Die zweite Grenze ist die Zusammenarbeit. Da die Anwendung als Metadaten in der Datenbank liegt, arbeiten alle auf derselben Instanz oder auf getrennten Kopien mit anschließendem Import. Der Export ist ein generiertes Skript, und Konflikte darin von Hand aufzulösen macht keine Freude. Größere Teams schneiden deshalb entlang von Seiten und Anwendungen statt entlang von Zeilen.
Die dritte Grenze ist die Bindung. Eine APEX-Anwendung ist ohne Oracle-Datenbank nicht lauffähig. Das ist kein Argument gegen APEX, aber es gehört auf den Tisch, bevor in drei Jahren jemand fragt, was ein Wechsel des Datenbanksystems kosten würde. Die Antwort lautet dann: die Oberfläche vollständig.
Was eine Eigenentwicklung wirklich kostet
Die Bauzeit der Masken ist selten der große Posten. Teuer sind Authentifizierung und Berechtigungen, das Zusammenspiel von Prüfung im Browser und Prüfung auf dem Server, Fehlerbehandlung, Protokollierung, Mehrsprachigkeit und die Auslieferungskette. Diese Themen tauchen in keiner Schätzung auf, die sich an der Zahl der Masken orientiert, und sie kommen trotzdem.
Dazu kommt der laufende Unterhalt. Eine Frontend-Anwendung besteht aus Abhängigkeiten, die aktualisiert werden wollen, weil sonst Sicherheitslücken offen bleiben und ein späteres Aktualisieren zum Umbau wird. Rechne mit einigen Tagen pro Jahr allein dafür, unabhängig davon, ob sich fachlich etwas ändert.
Der Vorteil, den du dafür bekommst, ist echt: freie Oberfläche, freie Wahl der Schnittstellen, unabhängiger Betrieb, austauschbare Datenhaltung. Wenn die Anwendung Kundinnen und Kunden erreicht oder Teil des Produkts ist, ist dieser Vorteil den Preis meistens wert. Für die interne Antragsverwaltung ist er es selten.
Der Mittelweg, der oft übersehen wird
Die Entscheidung muss nicht für die ganze Anwendungslandschaft fallen. Ein häufiges und funktionierendes Muster: interne Pflege- und Auswertungsmasken in APEX, das nach außen sichtbare Portal als eigene Anwendung, beide auf denselben Datenbankpaketen. Die Fachlogik existiert dann einmal, und die Oberflächen bedienen unterschiedliche Ansprüche.
Damit das trägt, muss die Logik konsequent in Paketen liegen und nicht in Seitenprozessen. APEX macht es leicht, eine Prüfung schnell in einen Seitenprozess zu schreiben, und genau diese Prüfungen fehlen später der zweiten Oberfläche. Eine Vereinbarung im Team, dass jede Regel in ein Paket gehört, kostet am Anfang etwas Disziplin und erspart viel Nacharbeit.
Für den Einstieg lohnt sich ein Prototyp. Nimm die schwierigste Maske, nicht die einfachste, und bau sie in beiden Welten. Nach zwei Tagen weißt du mehr über die Passung als nach zwei Wochen Konzeptdiskussion, und das Ergebnis lässt sich einer Leitung zeigen.
Dazu passende Kurse
Den kompletten Weg von der Tabelle bis zur fertigen Maske zeigen die Oracle-Kurse rund um APEX-Anwendungen an einem durchgehenden Beispiel.
Weil die Fachlogik unabhängig von der Oberfläche am besten in der Datenbank liegt, sind Datenbankkurse für Entwicklerinnen und Entwickler für beide Wege dieselbe Grundlage.
Wie sicher bist du beim Thema wirklich?
Lesen fühlt sich schnell nach Können an. Ein kurzer Test zeigt dir, was davon schon sitzt und wo sich ein Kurs lohnt. Kostenlos, ohne Anmeldung, mit einer Erklärung zu jeder Antwort.
Super Schulung, in der der Trainer auch auf eigene Fragestellungen eingegangen ist.
Super Grundlagenschulung mit allen wichtigen Punkten und hilfreichen Tipps!
Schön, sich 5 Tage ungestört mit Postgres beschäftigen zu können.
Häufige Fragen
Brauche ich einen eigenen Applikationsserver für APEX?
Lässt sich eine APEX-Anwendung versionieren?
Kann APEX auch fremde Datenquellen anbinden?
Ist APEX für eine öffentlich erreichbare Anwendung geeignet?
Quellen
Passt thematisch dazu
Dieselbe Frage nach der Nachfolge stellt sich bei jedem eingekauften Werkzeug, und wie du sie dort in fünf einzeln beantwortbare Punkte zerlegst, zeigt die Abwägung zwischen Eigenbau, Einkauf und Low-Code .
Deine Ansprechpartner
Du bist dir nicht sicher, welcher Kurs oder welches Level zu dir passt? Wir beraten dich persönlich und kostenlos.
Yves Hoppe
Weiterbildung & Beratung
Hilft dir, aus dem Datenbanken-Programm den passenden Kurs für deinen Stand zu finden.
Norbert Jansen
Beratung & Inhouse
Plant mit dir Inhouse-Trainings, die auf eure Abläufe und euren Datenbestand zugeschnitten sind.
Erst entscheiden, dann bauen
Wie APEX-Anwendungen entstehen und wo die Fachlogik in der Datenbank besser aufgehoben ist, zeigen die Oracle-Kurse bei cmt am durchgehenden Beispiel.