• Backendentwicklung von (Micro)services in Java mit Spring Boot
• Datenmodellierung
• Analyse und Konzeption von Anwendungslösungen
• Automatisierte (Integrations-)Tests
• CI/CD
• (Cloud-) Architektur
• (Unterstützung in der) Team-/Projektleitung sowie Entwicklungsplanung

Profil

• Meine Stärke liegt ganz klar in dem Interesse ein gutes technisches Verständnis von Systemen zu erlangen und zu wissen wie diese arbeiten. Es gelingt mir deshalb vergleichsweise schnell mir dieses anzueignen und zu merken. Für mich ist in diesem Zusammenhang extrem wichtig, dabei eine präzise Sprache zu haben oder zu entwickeln; Begriffe müssen gut zu definieren sein und korrekt verwendet werden. Mit diesem Rüstzeug gelingt es mir dann auch komplizierte Sachverhalte zu beschreiben und im Gespräch mit anderen zu diskutieren und zu verfeinern.
• Neben diesen analytischen Fähigkeiten zeichne ich mich durch eine hohe Belastbarkeit aus. Ich habe Projekte mit hohem Einsatz über einen langen Zeitraum als auch die typischen Stress-Phasen in Projekten, z.B. kurz vor dem Release-Termin ohne Probleme gemeistert.

Kenntnisse:

• Ich besitzte allgmein ein gutes Verständnis von Daten und deren Zusammenhänge, ebenso kenne ich auch die grundlegenden Prinzipien der Arbeitsweise und Internas von DBs.
• Dabei sind mir die Standard-Objekte der Datenbanken wie Views, Tabellen, Trigger, Indexe vertraut und ich beherrsche derem Umgang. Besonders das Schreiben von SQL Queries mit komplexten Joins habe ich im Rahmen eines OLAP/DWH-Projektes in großem Umfang betrieben.
• Mein Kontakt zu Datenbanken war stehts im Kontext der Entwicklung zu sehen, wozu es u.A. als Architekt und Technischer Projektleiter auch gehört Datenbank-Schemata zu entwerfen als auch die Infrastruktur zu planen und in Auftrag zu geben. Der Portierbarkeit wegen wurde i.d.R. auf Stored Procedures verzichtet und möglichst mit Standard-DB-Mitteln und -Mechnismen gearbeitet. Gleichwohl besitze ich hier Grundkenntnisse und habe Funktionen sowohl für SQL Server als auch Oracle umgesetzt.
• Viel interessanter wäre heutzutage in diese Zusammenhang zu erfragen, wie das mit der Sicherheit in der Datenkommunkation ist - z.B. Zertifikate, Verschlüsselung etc. Hier habe ich grundlegende Kenntnisse der Arbeitsweisen und muss mich in der Entwicklung darum kümmern, dass gemäß den allgmeinen und speziellen Anforderungen eine Einschätzung zur Datenklassifikation erfolgt und entsprechend umgesetzt wird.
• Daher habe ich nur wenig pratisches Wissen zur Einrichtung und Administration, da dieses in meinem Projekten von der Infrastruktur-Abteilung erledigt wird.
• Wenn man daher nicht unbedingt nach einem Adminstrator in der Infra sucht, ist von den obigen Punkten einzig "Message Queues" interessant. Diese habe ich sowohl in J2EE als auch sonstigen Server-Applikationen als Transport-Kanal genutzt, um Daten zwischen verschiedenen Applikation auszutauschen oder aber an die Knoten in einem Server-Cluster zu verteilen.
• Neben den MQs finde ich auch Datenformate zur Übertragung wie XML oder JSON in diesem Bereich interessanter und erwähnenswerter als z.B. "Router".
• In XML habe ich äußerst umfangreiche und fortgeschrittene Kenntnisse, da ich es seit 2000 in vielen Projekten genutzt habe, sowohl zur Konfiguration als auch zum Austausch von Daten zwischen Systemen. Ich auch inbesondere fortgeschritte Kenntnisse im im Design von XML Schemata und deren Nutzung zur Validierung eines XML Dokumentes.
• JSON habe ich erst in den letzten 3 Jahren gelegentlich zur Serialisierung und Übetragung genutzt und schätze dabei seine teilweise bessere Lesbarkeit aufgrund der kompakteren schreibweise.

Methoden

• Entwicklungsprozess (Agile Development)
  • Bis 2016 habe ich in keinem Projekt formal Agile Methodik genutzt aber auch nie ein reines V- oder Wasserfallmodell. Die Wahrheit liegt, wie so oft, dazwischen, d.h. viele der Agilen Prinzipien ergeben sich in der Praxis von selbst, will man eine funktionierende und für den Kunden nützliche und nutzbare Software erstellen, auch wenn formal ein eher klassischer Prozess definiert ist.
  • Wesentlichster Punkt ist für mich als Teamlead, der meistens auch für Analyse Konzeption und Planung zuständig war, auf Änderungen von Anforderungen und Gegebenheiten reagieren und eingehen zu können. Das schmeißt zwar immer wieder Planungen über den Haufen, aber am Ende muss die Software die tatsächlichen Anforderungen des Kunden erfüllen und nicht unbedingt was zu Beginn gefordert wurde, selbst wenn es abgestimmt und spezifiziert war.
  • Zum Glück werden seit einiger Zeit auch in Konzernen auf Agile Methoden formal umgestellt

• Scrum
  • Ab 2016 wurde im Projekt Engpasstool auf Scrum umgestellt. Hierbei übernahm ich für die bislang verantwortete Applikation einen Gutteil der Rolle des Product Owners als auch die des Entwicklers (obwohl diese Rollen nicht in Personalunion ausgeführt werden sollten).
• Team- und Projektleitung
  • Kernaspekte sind hier aus der Entwicklung heraus:
    • die Aufwände realistisch zu schätzen
    • in einen Release-Zyklus einzuplanen
    • die Aufgaben im Team zu verteilen
    • die Koordination mit anderen Bereichen bzw. Schnittstellen-Partnern
    • sich um das Ganze Drum-Herum (z.B. Entwicklungs-Infrastruktur, Berechtigungen und System-Zugängen, etc.) zu kümmern (Mädchen für alles)
  • Anmerkung: Derzeit liegt mein gewünschter Fokus mehr auf der Entwicklung. Bin aber gerne bereit auch in Teilen Leitungsfunktionen zu übernehmen bzw. darin zu unterstützen.
• Anforderungs-Analyse Lösungs-Design und Spezifikation
  • Meine starke analytische Fähigkeit auch komplexe und komplizierte Sachverhalte zu durchdringen, sie zu formulieren und in verdaubarere Teile zerlegen zu können, sind für mich Schlüssel-Faktoren in diesem Bereich.
  • Oft werden diese Tätigkeiten separat betrachtet und haben auch eigene Schwerpunkte und Ziele, aber sie komplett zu trennen (klassisches Modell) erachte ich nicht als sinnvoll, weil sehr große Wechselwirkungen bestehen und u.A. die Agilen Entwicklung motiviert haben.
  • Wesentlich ist für mich hierbei das Formulieren und Verbalisieren sowohl der Anforderung als auch der zugehörigen Lösung(en) in einem konsistenten und wohl definierten Vokabular (DSL).
  • Die zahlreichen Dokumente, die ich hier selber verfasst habe, reich(t)en von wenigen Seiten bis zu Werken mit über 100 Seiten.
  • Als sehr hilfreiche empfinde ich es hierbei, mit dem breiten Wissen aus der Entwicklung zu praktikablen Lösungskonzepten zu kommen, die auch mit vertretbarem Aufwand implementiert werden können.
• Unit Testing/TDD
  • TDD nutze ich sehr gerne aber nicht in der reinen Form, da diese mir zu kleinteilig ist und der Code aus den vielen Zwischenschritten am Ende weggeworfen wird. Von den Auswirkungen schätze ich:
    • Fokus auf das Ziel, was die Auseinandersetzung mit den Anforderungen erzwingt
    • Den produktiven Code aus einer anderen Warte zu betrachten
    • testbarere Einheiten (DI)
    • eine bessere Testabdeckung
    • eine echte Kunst ist es die Testfälle möglichst orthogonal anzuordnen
  • Tooling/Libraries
    • Junit 5
    • JaCoCo (Coverage mit Sonar)
    • Cucumber
    • Testcontainers
• Mocking
  • jMockit
  • EasyMock 
  • Mockito
• Rollout- /Release-/Deploy -Management
  • Hierbei handelt es sich i.d.R. um die Installation der Entwicklungs-Pakete auf dem Server durch den Betrieb. 
  • Dieses war entsprechend vorzubereiten und mit allen Beteiligten abzustimmen (z.B. Firewall-Freischaltungen für neue Schnittstellen, MQ Konfigurationen, etc.) aber es schließt auch Nutzerschulungen mit ein
• UML
  • UML wird fast immer gefordert, tatsächlich habe ich es bisher kaum nutzen müssen, lediglich das ein oder andere State-, Activity- und Use Case-Diagramm und dann nur im Rahmen der Spezifikation bzw. Diskussion im Team
• BPMN
  • Für die praktische Arbeit und das besprechen von Abläufen finde ich BPMN Diagramme i.A. leichter verständlich und bevorzuge diese über UML Activity Diagrammen.
• Software/Applikations-Architektur
  • Design der inneren Architektur der Applikation: d.h. Aufteilung der Module und Schichten, genutzte Technologien & Frameworks.
  • Design der äußeren Architektur anhand der Rahmenbedungen: d.h. Schnittstellen und Protokolle zu anderen Systemen, Integration in die Betriebslandschaft
• Patterns
  • Das schönste ist, wenn man ein Muster angewandt hat, ohne es vorher zu kennen.

Softskills

• Motivation
  • Ich hatte noch nie ein Problem mich zu motivieren, höchstens mit mangelnder Motivation anderer.
  • Insofern ist auch meine Belastbarkeit eher überdurchschnittlich, denn ?wenn es Freude macht, ist es keine Arbeit?; andere sagen dazu ?Workaholic
• Arbeitsweise
  • eigenständige, strukturierte und nachvollziehbare Arbeitsweise
  • Anforderung möglichst direkt und ohne Goldkante erstmal erreichen. Dabei aber auf Potentiale aufmerksam machen.
  • sehr Effizienz-orientiert (scripting)
  • möglichst wenig Planungsoverhead
  • immer auf der Suche nach Optimierung/Automatisierung der Abläufe und Prozesse
• Kommunikation
  • Offene und zielgerichtete Kommunikation gegenüber allen Projektbeteiligten mit dem Fokus auf ?Denotation?.
  • Darüber hinaus ist mir natürlich auch die konnotative Dimension bewusst und ist u.A. wichtig, um frühzeitig auf Probleme in der Beziehungs-Ebene im Team reagieren zu können.
• Teamfähigkeit
  • bringe mich stets ein
  • helfe ohne Umschweife
  • äußere meine Meinung und Sicht und respektiere andere

AWS Cloud

• Terraform
  • Ich hatte erst mit manuell Skripten unter Nutzung der AWS CLI begonnen. TF macht das Leben aber viel leichter
    • Parametrisierung des Infra-Stacks so dass dieser für alle Stages verwendet werden konnte unter Nutzung von Workspaces
• Beanstalk
  • Einfacher Weg skalierende Applikationen zu deployen aber halt etwas eingeschränkter
• ECS
  • Der nächste Schritt nach Beanstalk seine Docker-Container zu deployen. 
  • Grundgerüst wurde bereitgestellt und ich habe hauptsächlich dieses dann an die Bedürfnisse angepasst
• ALB
  • Grundgerüst wurde bereitgestellt und ich habe gelegentlich die Regeln angepasst
• Cognito
  • Genutzt als einfaches User-Management für die UI mit manueller bzw. geskripteter Anlage der User
• RDS/Aurora
  • Naja, es ist ein RDBMs in der Wolke, ohne nennenswerte Sonder-Konfigurationen
• SNS
  • Nur im Rahmen der AWS CodePipeline manuell eingerichtet Benachrichtigungen
• CodeCommit
  • AWS Git Repo, mit viel Luft nach oben
• CodeBuild, CodePipeline
  • Inzwischen gar nicht so schlechte Möglichkeit seine Applikationen zu bauen. 
  • Habe von Grund auf unsere CI/CD-Pipeline aufgesetzt
• ParameterStore
  • Genutzt als Datenspeicher für die Parametrisierung der CI/CD Pipeline als auch der Applikation in den einzelnen Stages
• VPC
  • Genutzt zur Trennung der verschiedenen Stages auf Netzwerk-Ebene.
• S3 
  • Genutzt als ausschließlich interne Ablage für verschiedenste Artefakte mit Nutzung von Versionen.
• X-Ray
  • Service ?missbraucht? um im Betrieb eher fachliche Datenströme zu visualisieren
• Kibana
  • ELK Stack für die Logs inkl. Einrichtung von Dashboard aber hauptsächlich genutzt um Logs für die Fehleranalyse zu sichten.
  • Für komplexerer Analyse-Aufgaben habe ich dann aber eine kleines Tool geschrieben, das mittels Elasticsearch Logeinträge sucht und korreliert.
• AWS Kinesis 
• SecurityGroups 
  • Genutzt um klassisch Zugriffe auf Ressourcen ähnlich zu einer Firewall zu beschränken.
• IAM
  • Genutzt haben ich Rollen und Policies (auch Cross-Account) um weiter den Zugriff auf Ressourcen beschränken zu können.

IDEs & Tools

• IntelliJ
  • Habe nach langer Zeit meinen Wiedersand dagegen aufgrund der Anforderungen in einem Projekt aufgegeben und finde es nun tatsächlich konsistenter als Eclipse, auch wenn ich von dort noch das ein oder andere Feature vermisse
• Eclips
  •  Überzeugter Nutzer von Eclipse trotz einiger Schwachstellen:
    • Egit ? nutze daher die Git Bash
    • Mangelhafter JS Support
  • War bislang immer einer der Most-Advanced User in den jeweiligen Teams, bin mir aber sicher nicht alles zu wissen
  • J2EE und RCP Distributions
  • Plugins
  • Maven
  • RBE
  • MoreUnit
  • JAutoDoc
  • Spring IDE
  • JRebel
  • Mylyn
  • AutoDeriv
  • Asciidoc
  • PlantUMLo
• Maven
  • Mittlere Komplexität unter Nutzung diverser Plugins.
• Git Seit
  • Habe in 2015 begonnen Git zunächst als Frontend für SVN, Perforce zu nutzen.
  • Seit 2017 nutze ich nur noch Git direkt und kann mir gar nichts anders mehr vorstellen
  • Hoster: Gitlab, Github, Bitbucket
• Docker
  • Nutzung im Rahmen der lokalen Entwicklung /Debugging
  • Docker compose
• CI/CD
  • Gitlab (bis 2023), GitHub (2024)
  • Hudson/Jenkins (bis 2016)
  • Bamboo (bis 2012)
  • ArgoCD (2024)
• Sonar
  • 2024 Einbindung von SonarCloud in CI Pipeline auf Github getriggert durch Maven
• Bash/CMD
  • Automatisierung immer wieder kehrender Aufgaben sowohl privat als auch im Projekt
  • Immer auch Teil und nötig für CI/CD Pipelines
  • Angefangen mit DOS/CMD auf Windows mit mit GnuWin32 u.Ä Erweiterung um es Unix-ähnlicher zu machen. 
  • Ab 2016 mit Git Bash auf Windows und danach mit WSL echtes Linux/Posix Bash

Microsoft Office

• Word
  • Hauptsächlich und viel im Rahmen von Spezifikationen genutzt
  • Zur Automatisierung auch einige VBA Skripte erstellt
  • Styles sind selbst in der Version 2016 immer noch ein Kampf und die wenigsten wissen leider diese einzusetzen, was besonders schlimm ist, wenn diese dann Templates bereitstellen.
  • Seit 2016 schreibe ich nur noch wenig in Word, weil vielfach im Rahmen der Agilen Entwicklung zu Wikis übergegangen wurde. Dennoch bin im in Word immer noch deutlich produktiver als in den Wikis und bevorzuge es daher.
• Excel
  • Übliche Office-Nutzung professionell und privat
  • Diagramme
  • Daten-Import/Export auch mit Java Bibliotheken
• PowerPoint
  • einfache Präsentationen
• OneNote
  • Ein super Wiki für die Dokumentation in kleinen Teams und auch probates Mittel gegen die persönliche Zettelwirtschaft

Beruflicher Werdegang

07/2012 ? heute

Rolle: Software-Engineer, -Architekt, Teamlead, Techn. Projektleiter 

04/2005 ? 07/2012

Rolle: Software-Engineer, -Architekt, Projektleiter

Kunde: BROX IT Solutions GmbH, Hannover

04/2000 ? 04/2005

Rolle: Software-Engineer (50% Stelle neben Studium)

Kunde: BROX IT Solutions GmbH, Hannover

04/1999 ? 04/2000

Rolle: Software-Engineer 

Kunde: BROX IT Solutions GmbH, Hannover

WSL2

• Mit WSL2 habe ich nun für mein Entwicklungssetup die goldene Mitte zwischen der Produktivität der Windowsumgebung und den Linux Toolchains gefunden.
• D.h. meine IDE (via X-Server) und alles was für die Entwicklung nötig ist, läuft in WSL, der Rest in Windows.

Windows

• Habe ich seit Anbeginn der Tage genutzt (Win 3.11)
• Der Level bezieht sich auf die Nutzung und nicht auf die Administration von Windows-Netzwerken, obwohl ich da auch ein paar Kenntnisse habe
• Viele kleinere Tools um das Leben zu erleichtern
• Seit 2019 arbeite ich entwicklungs-technisch ausschließlich aus der WSL heraus -> siehe Linuxe

Linuxe

• Seit 2005 liefen die Webanwendungen meiner Projekte standartmäßig auf Linux Umgebungen
• Seit 2019 arbeite ich entwicklungs-technisch ausschließlich aus der WSL heraus, grundsätzlich auf einem aktuellen Ubuntu LTS
• Mein Host OS ist aber weiterhin Windows weil ich einfach in Windows zu produktiv bin, als dass ich die Muße hätte, dass auf ein Linux zu übertragen.

Spring

• In diversen Kundenprojekten als DI Container eingesetzt
• ?Der kleine Bruder von OSGi?
• Aspekte
  • Profile
  • AOP
  • XML- und Annotationsbasierte Konfiguration
  • Data-Integration
  • Integration-Testing

J2EE

• Aufgrund der Kundenanforderungen in den Projekten hatte ich bis auf das Projekt bei der Talanx nie den Bedarf für einen vollen J2EE Server; ein Tomcat + Spring + ggf. JPA/JMS reichte aus.
  • Bei der Talanx wurde das Thema EJB aber weitestgehend in einem hauseigenen Framework versteckt und die Entwicklungsarbeiten war i.d.R. so weit davon entfernt, so dass dies nur wenig zum Tragen kam

JPA

• Hibernate 6
• Mapping der Entities auf DB Schema bzw. Generierung des Schemas aus den Entities heraus.
• Custom und Embedded Types
• Inheritance Mapping
• Interceptors

Flyway

• Nutzung zur Migration von Daten in DBs sowohl Standalone als auch integriert in Spring-Boot

Eclipse Scout

• Bislang nur ein paar Implementierungen und Anpassungen von Maskenteilen

JSF 2

• Im Rahmen meiner Kernrolle des Teamleiters und Architekten im VW Projekt in 2012 habe ich mich zunächst theoretisch mit den Grundlagen befasst und dann bei Problemstellungen auch praktisch Lösungen entwickelt und umgesetzt. 
• Insofern besitze ich ein gutes Grundverständnis der Frameworks (Phasen, Komponenten, Zusammenspiel aller Teile) vor allem auf der Server-Seite

Vaadin

• Mit Vaadin bin ich im TUI Projekt mit in Berührung gekommen und ist analog zu JSF ein Komponentenbasiertes Web-Framework. 
• Im Rahmen der Tätigkeiten habe ich mich in ein paar Aspekte einarbeiten können, was erstaunlich leicht ging. 

OpenAPI Sepcification (OAS) /Swagger

• Hauptsächlich im Rahmen von API First, also erst OAS schreiben und daraus Java POJOs generieren inkl. Konfiguration und Anpassung nach den Bedürfnissen des Projektes.
• Gelegentlich auch Generierung der OAS/Swagger UI aus dem bestehende Programm Code bei älterem Code.

REST(ful)

• Design und Nutzung von APIs, bevorzugt im Zusammenhang mit OpenAPI/Swagger
• Nutzung von:
  • definierten HTTP Status Codes
  • ggf. auch ProblemDetail für Error Responses
• Kein HATEOAS

JSON

• Inzwischen in einigen Projekten genutzt, meist mit Jackson o.Ä.
• Im Vergleich zu XML und YAML fehlt mir hier immer wieder, dass es keine Kommentare gibt
• Insofern OK für reinen Datatransport in der Applikation

XML

• Neben dem normalen lesen/schreiben von XML Dokumenten verstehe ich darunter auch vor allem die Aspekte:
  • Validierung
  • Generierung via JAXB

XML Schema Design

• Habe in diversen Projekten XML Schemata entworfen, hauptsächlich mit XML Spy.
• Im Grunde braucht man die gleichen Skills wie bei OO und DB Design
• Features
  • (multiple) Namespaces
  • Ableitungen
  • Groups
  • Ref. Constraints

XSLT

• Einfache Transformationen
• Es muss bewusst sein: funktionales Paradigma

Kubernetes

• Normale Nutzung als Entwickler, d.h.
  • Deployments via Helm Charts und argoCD
  • Leichte Administration im Rahmen des Betriebes der Installierten Anwendungen mit kubectl zur Problembehebung , Debugging etc

Tomcat 7,8

• Grundlegende Administrations-Kenntnisse zum Aufsetzen für die Entwicklung
  • Applikations-Kontexte
  • Ports
  • Bibliotheks-Management
  • Rechte (LDAP Integration)
• SSL
• Seit Spring Boot ist der Webserver idR integriert

OSGi

• Im Rahmen von SMILA/eccenca benötigt
• Implementierung Equinox
• Diese Welt ist riesig, weshalb ich mir hier nur Level 5 gebe.
  • Dependency Management
  • OSGi Console
  • Declarative Services
• Build (extrem aufwändig

Solr/Lucene/Elastic Search

• Hauptsächlich im Rahmen der Produktentwicklung der Brox GmbH als auch in diversen Kunden-Projekten eingesetzt.
• Aspekte:
  • Importieren der Daten in den Index (~ETL)
  • Design der Indizierung-Schritte und des Indexes, damit vernünftig gefunden werden kann
  • Abbildung von Berechtigungs-Strukturen bei der Suche
• Integration von 3rd-Party Komponenten wie Thesauri und Wortstamm-Analyse/Reduktion

JWT, OIDC, OAuth2

• Intensiv an einer IAM Lösung auf Basis von Keycloak gearbeitet die alle diese Elemente beinhaltet

Datenbank Design

• DB Design ist eine eigene Disziplin und wenn auch eng verwandt mit OOD, so ist es doch hinreichend unterschiedlich dazu, um nicht ohne weiteres die Prinzipien von der einen in die andere Welt übertagen zu können: Es geht in der DB immer um Mengen und deren Relationen und nicht um Objekt-Graphen.
• Aspekte
  • Indexe
  • Constraints
  • Trigger
  • Locking
  • Schemata
  • Tabelspaces

SQL

•  Kein Projekt ohne auch eine DB zu haben und daher war auch immer SQL im Spiel, mal mehr mal weniger.
• Wichtig hierbei ist das Denken in Mengen und Mengen-Operationen und nicht in einzelnen Schrittfolgen (Deklarative vs. Imperative Programmierung)
• Vor allem in den DWH Projekten 2004-2007 habe ich enorm an Können gewonnen

ETL

• Kam in reiner Form in den DWH Projekten 2004-2007 vor als auch im Projekt Engpasstool ab 2012
• Aufgrund meiner Affinität zu Datenbanken und deren Operationen auf Mengen haben sich mir die hier nötigen Prinzipien und Handwerkszeuge schnell erschlossen und habe dem Thema ETL zunächst keine weitere Bedeutung zugemessen, weil in irgendeiner Form das immer in Projekten vorkommt ? besonders in Konzernen.
• Inzwischen habe ich gelernt, dass eine performante und vor allem wartbare (d.h. betrifft vor allem auch Fehlerdiagnose im Betrieb) von enormen Wert ist und derartige Schnittstellen zu designen auch erfahrene Entwickler vor eine große Herausforderung stellt.

Microsoft SQL Server

• Bezogen auf das MS spezifische Produkt:
  • Administration von DBs für Entwicklungszwecke
  • Rechte
  • Backup/Restore
• T-SQL
  • Hauptsächlich um Abläufe zu automatisieren oder zum Debugging
  • Highlight: Umsetzung einer FSM im Rahmen eines DWH Projektes
• Tools
  • SQL Server Manager
  • Query Analyzer

Oracle Database

• Geringe Administrative Kenntnisse
• PL/SQL
  • Aufwändigere STPs im Rahmen des Projektes Engpasstool ab 2012 für den ETL Prozess
• Tools
  • Oracle SQL Developer
  • SQLPLUS

PostgreSQL

• Einfache Administrative Kenntnisse:
  • aufsetzen des Servers, import/export von DBs/Daten
• Reine Nutzung als SQL DB via Standard-SQL