# Workflow-Vergleich: Softwarebestellung-System

## Ausgangssituation
- Schulen bestellen Software über Webformular
- Bestellung muss intern geprüft/genehmigt/ggf. korrigiert werden
- Nach Genehmigung: Übermittlung an iServ (als ausgefülltes PDF)

---

## Variante A: MIT Datenbank

### Workflow
1. **Schule füllt Webformular aus** → Absenden
2. **System speichert in DB** + erstellt Ticket per E-Mail
3. **Interne Bearbeitung:**
   - Status: "Neu" → "In Prüfung" → "Genehmigt"/"Abgelehnt"
   - **Korrekturen direkt in DB möglich** (Web-Interface)
   - Historisierung aller Änderungen
4. **Bei Genehmigung:** PDF-Generierung aus DB-Daten
5. **Versand an iServ** mit ausgefülltem PDF

### Vorteile ✅
- **Bearbeitbarkeit:** Korrekturen jederzeit über Admin-Interface
- **Nachvollziehbarkeit:** Änderungshistorie (Wer? Wann? Was?)
- **Statusverwaltung:** Klarer Bearbeitungsstatus pro Bestellung
- **Mehrfachnutzung:** Daten für Statistiken/Reports nutzbar
- **Suchfunktion:** Alte Bestellungen schnell findbar
- **Validierung:** Plausibilitätsprüfungen vor PDF-Erstellung
- **Wiedervorlagen:** Unvollständige Bestellungen nacharbeiten
- **Skalierbarkeit:** Bei wachsender Anzahl besser verwaltbar

### Nachteile ❌
- Höherer initialer Entwicklungsaufwand
- DB-Setup und -Wartung erforderlich
- Backups/Datenschutz muss geregelt werden

### Technischer Stack
```
Frontend:    HTML/CSS/JS (bestehendes Formular)
Backend:     PHP
Datenbank:   MySQL/MariaDB oder PostgreSQL
PDF:         TCPDF/FPDF/mPDF Library
E-Mail:      PHP mail() oder SMTP
```

---

## Variante B: OHNE Datenbank (Nur Dateisystem)

### Workflow
1. **Schule füllt Webformular aus** → Absenden
2. **System speichert als JSON-Datei** im Filesystem + Ticket per E-Mail
3. **Interne Bearbeitung:**
   - **Manuelle Bearbeitung der JSON-Datei** (Texteditor/Script)
   - Umbenennen der Datei für Status (z.B. `001_neu.json` → `001_genehmigt.json`)
4. **Bei Genehmigung:** PHP-Script liest JSON + generiert PDF
5. **Versand an iServ** mit ausgefülltem PDF

### Vorteile ✅
- Schneller zu implementieren
- Keine DB-Infrastruktur nötig
- Einfaches Backup (nur Dateien kopieren)
- Weniger Komplexität

### Nachteile ❌
- **Korrekturen umständlich:** JSON manuell editieren fehleranfällig
- **Keine Validierung:** Syntaxfehler in JSON möglich
- **Kein Web-Interface:** Änderungen nur per SSH/FTP
- **Keine Historie:** Alte Werte bei Änderung verloren
- **Konkurrenzprobleme:** Mehrere gleichzeitige Bearbeitungen kritisch
- **Keine Suche:** Bestellungen nur über Dateisystem durchsuchbar
- **Statusverwaltung primitiv:** Nur über Dateinamen/Ordner
- **Keine Rechtesteuerung:** Wer darf was ändern?

---

## Empfehlung: **MIT Datenbank**

### Begründung
1. **Korrektur-Anforderung ist zentral:** Ohne DB ist jede Korrektur fehleranfällig und zeitaufwendig
2. **Professionelles Arbeiten:** Web-Interface für Sachbearbeiter ohne Systemkenntnisse
3. **Zukunftssicher:** Bei steigender Bestellanzahl wird Filesystem-Lösung unmöglich wartbar
4. **Audit-Trail:** Bei öffentlichen Einrichtungen oft erforderlich (Wer genehmigte wann?)
5. **Mehrwert:** Statistiken ("Welche Software wird am häufigsten bestellt?") möglich

### Kompromiss (falls Chef skeptisch)
**Phase 1:** Minimale DB (nur Tabelle `bestellungen`)
- Validiert die Notwendigkeit im Produktivbetrieb
- Geringer initialer Aufwand
- Später erweiterbar

**Phase 2:** Bei Bedarf erweitern um:
- Benutzer-/Rechteverwaltung
- Änderungshistorie
- Statistik-Module

---

## Aufwandsschätzung

| Aufgabe | Mit DB | Ohne DB |
|---------|--------|---------|
| Initial-Entwicklung | 2-3 Tage | 1 Tag |
| Bearbeitung pro Bestellung | 2-5 Min | 10-20 Min |
| Wartung/Jahr | 1-2 Tage | 3-5 Tage |
| Fehlerrisiko bei Änderungen | Gering | Hoch |

**Fazit:** DB rechnet sich bereits nach ~20 Bestellungen!

---

## Kritischer Punkt: Was wenn Fehler auftreten?

### Ohne DB
- JSON-Datei korrupt → Bestellung verloren oder manuelles Debugging nötig
- Falsche Änderung → Alte Version weg (außer manuelle Backups)

### Mit DB
- Transaktionssicherheit
- Backup/Recovery-Strategien
- Validierung vor Speicherung
- Change-Log → Fehler rückgängig machbar