Beiträge von Tobi89

Moin Anna, zu deiner Frage: Ja, proprietäre Datenbank- oder Storage-Dienste alleine reichen schon aus, um von Lock-in zu sprechen. Du musst nicht warten, bis zusätzlich noch APIs oder Automatisierung dazukommen - das verstärkt es nur.

Für deine Fallstudie würde ich folgende Kategorien durchgehen, das ist in der Praxis auch der übliche Blick:

• Proprietäre APIs: Wenn die Anwendung direkt gegen anbieterspezifische Schnittstellen programmiert ist (nicht gegen offene Standards), ist ein Wechsel teuer, weil du Code umschreiben musst.
• Datenformate: Manche Managed-Services speichern Daten in proprietären Formaten oder mit anbieterspezifischen Metadaten. Export ist dann oft möglich, aber mit Aufwand und Qualitätsverlust verbunden.
• Automatisierung/Infrastructure-as-Code: Wenn Deployment-Skripte auf anbieterspezifischen Tools basieren, musst du die auch neu bauen.
• Vertragliche Bindung: Laufzeiten, Ausstiegsklauseln, Kosten für Datenausgang (Egress-Fees) - das wird gern unterschätzt.
• Know-how der Mitarbeiter: Oft ignoriert, aber wenn dein Team nur mit einem Anbieter-Ökosystem vertraut ist, ist das auch eine Form von Lock-in.

Mein Tipp: Geh den Text durch und markiere, wo explizit Dienste mit Eigennamen genannt werden (nicht nur "Datenbank", sondern "verwalteter Datenbankdienst XY"). Das ist meist der Fingerzeig, dass proprietär gearbeitet wurde. Viel Erfolg!

Daniels Antwort trifft es schon ziemlich gut, ich ergänz noch den Punkt Seed-Daten, den finde ich mindestens genauso wichtig wie die Trennung selbst.

Bei uns läuft das so: Migrations-Skripte bauen nur die Struktur auf (Tabellen, Indizes, Constraints), und separat davon gibt es Seed-Skripte, die Testdaten einspielen. Die beiden Dinge sollte man strikt trennen. Vorteil: Ihr könnt eure Dev- oder Test-DB jederzeit komplett wegschmeißen und per Skript neu aufbauen – Struktur rein, dann Seed-Daten rein, fertig. Kein manuelles Rumgefummel mehr, keine Altlasten.

Praktisch sieht das bei uns meistens so aus:

• ein Ordner "migrations" mit durchnummerierten Skripten (Schema-Änderungen, versioniert)
• ein Ordner "seeds" mit Testdaten, die nur in Dev/Test ausgeführt werden, niemals in Prod
• ein kleines Setup-Skript oder Makefile-Target, das beides nacheinander anstößt

Für die Produktivumgebung gibt's dann nur die Migrationen, nie die Seeds. Das verhindert genau euer Problem, dass Testdaten und echte Daten sich vermischen.

Merksatz: Struktur kommt aus Migrationen, Inhalte zum Testen kommen aus Seeds – und beide Quellen laufen nie gemeinsam gegen die Produktiv-DB. Typischer Anfängerfehler ist, Seed-Daten einfach als "Teil der Migration" mit reinzuschreiben, das rächt sich spätestens beim Deployment.

Daniels Faustregel "Was vs. Wie" ist echt der beste Merksatz dafür, den ich kenne. Ich ergänze mal mit einem Beispiel aus einem kleinen Projekt bei uns, wo genau diese Abgrenzung lange gewackelt hat.

Lastenheft stand sinngemäß: "Mitarbeiter sollen Material- und Lagerbestände abteilungsübergreifend einsehen können, Bestandsänderungen müssen nachvollziehbar sein (wer, wann, was)." Das war's. Keine Technik, keine Begriffe wie Tabelle oder Datenbank.

Im Pflichtenheft kam dann das eigentliche "Wie": relationale Datenbank mit Tabellen Artikel, Lagerbestand, Bewegungshistorie, Benutzer. Die Nachvollziehbarkeit wurde über eine separate Logging-Tabelle mit Fremdschlüssel auf Artikel und Benutzer plus Zeitstempel gelöst. Zusätzlich stand drin, über welche Schnittstelle (bei uns war's ein internes Webformular über ODBC) zugegriffen wird.

Der Punkt, den Anna vielleicht noch hilft: Wenn du im Lastenheft anfängst, Feldnamen oder konkrete Tabellenbeziehungen zu nennen, bist du zu tief. Der Auftraggeber will ja eigentlich nur sagen "ich will nachvollziehen können, wer was geändert hat" – wie du das technisch baust (Historientabelle, Trigger, Audit-Log), ist dann dein Job im Pflichtenheft. Genau da zeigt sich auch, ob man die fachliche Anforderung sauber in ein Datenmodell übersetzen kann – das ist eigentlich die Kernkompetenz, die bei sowas bewertet wird.

Kann mich Anna nur anschließen, und aus der Praxis-Ecke (BWL/IT-Schnittstelle) kommt da noch ein Argument dazu: bei Microservices zahlst du massiv Infrastruktur-Overhead drauf, den du bei 3-4 Bereichen nie wieder reinholst. Du brauchst dann ja plötzlich API-Gateway, evtl. Message Broker für async Kommunikation, mehrere Datenbanken, Container-Orchestrierung, verteiltes Logging/Tracing – und das alles, um am Ende Dinge zu debuggen, die in einem Monolithen ein simpler Funktionsaufruf wären.

Für ein Ein-Personen-Projekt würde ich da ganz klar zum (modularen) Monolithen raten. Merksatz, den ich mir dafür gemerkt habe: "Start with a monolith, split when you feel the pain" – die Pain-Points (Skalierung einzelner Teile, getrennte Teams, unterschiedliche Deployment-Zyklen) entstehen bei dir schlicht nicht.

Typischer Fehler in solchen Projektarbeiten: Leute bauen Microservices, kommunizieren dann aber doch wieder synchron per REST zwischen allen Services wie in einem Monolithen – nur jetzt über Netzwerk, mit allen Nachteilen (Latenz, Fehleranfälligkeit) und keinem der Vorteile (keine echte Entkopplung, kein unabhängiges Deployment, weil ja eh alles zusammen released wird).

Dein modularer Monolith mit klar getrennten Modulen pro fachlichem Bereich (Nutzerverwaltung, Bestellung, Produktkatalog) und sauberen Interfaces dazwischen ist genau der richtige Reifegrad. Du kannst in der Doku sogar erwähnen, dass diese Struktur bei Bedarf später relativ leicht in echte Microservices überführt werden könnte – das zeigt Weitblick, ohne dass du es jetzt schon umsetzen musst.

Daniel hat das mit Pseudonymisierung vs. Anonymisierung schon sauber erklärt, das ist echt der Knackpunkt. Ich ergänz mal die Löschfrist-Seite, weil da bei uns im Modul auch viele Leute unsicher waren.

Es gibt keine feste gesetzliche Frist wie "nach 30 Tagen löschen", sondern das Prinzip der Speicherbegrenzung: Du darfst Daten nur so lange vorhalten, wie es für den Zweck nötig ist. Für ein Studienprojekt heißt das praktisch: Rohdaten bis zur Abgabe/Bewertung aufheben, danach zeitnah löschen – nicht "vorsichtshalber" noch ein Jahr liegen lassen, falls der Prof nochmal nachfragt. Ich schreib mir da immer ein konkretes Datum in die Projektdoku, z. B. "Löschung der Rohdaten spätestens 4 Wochen nach Notenbekanntgabe", dann hat man auch einen Nachweis, dass man sich Gedanken gemacht hat.

Zur Einwilligung noch ein praktischer Tipp: In den Hinweistext unbedingt reinschreiben, dass die Teilnahme freiwillig ist und man jederzeit abbrechen kann, ohne Nachteile. Das wird in Klausuren und auch bei Gutachtern gern als Kriterium abgefragt, ob die Freiwilligkeit erkennbar war. Und speicher den Hinweistext selbst als Nachweis mit ab, nicht nur die Antworten – falls später mal jemand fragt, worüber die Teilnehmer informiert wurden.

Daniel hat das schon gut erklärt, ich ergänz mal aus der Praxis, wo ich das konkret trenne.

Wenn ich bei uns z.B. ein neues Berichtswesen oder eine reine Datenablage konzipiere (Stammdaten, Bewegungsdaten, Reporting), dann zeichne ich nur ER. Da interessiert mich: Wie sind die Tabellen normalisiert, wo sind die Fremdschlüssel, stimmen die Kardinalitäten. Methoden brauch ich da gar nicht, weil die Logik eh in SQL-Abfragen oder im BI-Tool passiert, nicht "in" den Daten selbst.

Sobald aber eine richtige Anwendung gebaut wird, also z.B. ein Bestellsystem mit Workflow (Bestellung anlegen, prüfen, stornieren, Rechnung erzeugen), reicht ER nicht mehr. Da will man ja auch festhalten: Wer darf was ändern, welche Methode löst welchen Zustandswechsel aus, gibt's Vererbung (z.B. "Geschäftskunde" und "Privatkunde" als Unterklassen von "Kunde" mit unterschiedlichem Verhalten). Das bekommt man mit reinem ER nicht sauber abgebildet, da fehlt einfach die Verhaltensebene. Typischer Ablauf in echten Projekten, die ich kenne: erst fachlich/ER grob klären, was an Daten überhaupt gebraucht wird, dann für die Implementierung der Anwendung das Klassendiagramm bauen, aus dem am Ende die Tabellen per ORM wieder generiert werden. Am Ende landet also vieles doch wieder in einer DB, nur der Weg dahin ist ein anderer.

Merksatz, den ich mir dazu gemerkt hab: ER fragt "was gibt es und wie hängt's zusammen", UML-Klasse fragt zusätzlich "was kann es tun".

Das Schichtenmodell von Daniel ist schon die beste Grundlage, die man dafür nehmen kann. Ich ergänze mal um ein paar Klausurbeispiele, die bei uns öfter dranhängen, weil Dozenten gerne konkrete Dienste nennen und dann fragen "was ist das für ein Modell":

• Virtueller Server/Storage zum Mieten ohne vorinstallierte Anwendung → IaaS
• Entwicklungsumgebung, bei der du nur deinen Code hochlädst und der Anbieter Skalierung/Patches der Laufzeitumgebung übernimmt → PaaS
• Webbasiertes Mailprogramm, Office-Anwendung oder CRM, wo du dich einfach einloggst → SaaS

Eselsbrücke, die bei mir hängengeblieben ist: Frag dich immer "Was müsste ich selbst installieren, wenn der Dienst ausfällt und ich neu aufsetzen müsste?" Bei IaaS praktisch alles außer Hardware, bei PaaS nur noch meine Anwendung, bei SaaS gar nichts, ich logg mich einfach woanders neu ein.

Typischer Fehler in Klausuren: Leute verwechseln PaaS und SaaS, weil bei beiden "man ja nichts administrieren muss". Der Unterschied ist aber, ob du noch eigenen Anwendungscode betreibst (PaaS) oder nur eine fertige Anwendung nutzt (SaaS). Wenn in der Aufgabe Begriffe wie "Laufzeitumgebung" oder "Deployment" auftauchen, ist das fast immer ein Hinweis auf PaaS.

Der Reißverschluss-Vergleich von Markus trifft's ziemlich gut, den merk ich mir. Von meiner Seite noch ein praktisches Beispiel, das mir aus dem Austausch mit Maschinenbau-Kommilitonen hängen geblieben ist: Transformationsmatrizen bei Bewegungen von Robotern oder Bauteilen.

Da hat man z.B. eine Rotationsmatrix R (3x3) und einen Punktvektor p (3x1), um den Punkt zu drehen. R·p geht, weil Spalten von R (3) = Zeilen von p (3). Ergebnis ist wieder 3x1, also ein transformierter Punkt. Soweit unspektakulär.

Interessant wird's, wenn man mehrere Transformationen hintereinander ausführt, z.B. erst drehen (R), dann verschieben/skalieren (T). Dann rechnet man T·R·p, und zwar in exakt dieser Reihenfolge, von rechts nach links gelesen als "erst R anwenden, dann T". Vertauscht man zu R·T·p, kommt bei nicht-kommutativen Transformationen (Rotation + Translation z.B.) ein komplett anderes Ergebnis raus, weil geometrisch "erst drehen, dann verschieben" etwas anderes ist als "erst verschieben, dann drehen".

Deshalb in der Klausur: Dimensionen checken reicht nicht, die Reihenfolge hat bei sowas auch eine inhaltliche Bedeutung, nicht nur eine rechnerische. Lohnt sich, sich das bildlich vorzustellen statt nur stur die Regel anzuwenden, dann bleibt's besser hängen.

Anna hat das schon super auf den Punkt gebracht mit Versionskontrolle vs. Backup. Kann ich nur unterschreiben, aus der Praxis-Ecke BWL/IT sehe ich das ständig, Leute verwechseln "ist irgendwo gespeichert" mit "ist gesichert".

Mein Setup für sowas ist eigentlich simpel und braucht keine großen Tools:

• Remote-Repo wie gehabt für die tägliche Arbeit
• Einmal pro Woche (bei wichtigen Projektphasen auch öfter) ein Bare-Clone des kompletten Repos ziehen, also git clone --mirror, nicht nur den Code auschecken. Dann hast du auch die komplette Historie, Branches, Tags mit drin
• Diesen Mirror dann als gepacktes Archiv (zip/tar) auf eine externe Platte UND zusätzlich in einen Cloud-Speicher, der nichts mit deinem Git-Anbieter zu tun hat

Der Punkt mit "unabhängiger Account" ist wichtig, den Anna auch schon erwähnt hat. Bringt dir wenig, wenn dein Backup am selben Login hängt wie dein Remote-Repo, falls genau der kompromittiert wird.

Klingt nach viel, ist aber bei so einem Mirror-Archiv Sache von 2 Minuten, wenn du dir ein kleines Script dafür baust. Bei einer Abschlussarbeit würde ich das definitiv machen, der Aufwand steht in keinem Verhältnis zum möglichen Schaden.

Moin, kann Anna nur zustimmen, die Execution-Pläne sind wirklich der Weg. Ergänzend aus der Praxis: typische Kandidaten, bei denen ein Index fast immer Sinn macht, sind Primärschlüssel (meist eh automatisch indiziert), Fremdschlüssel (vor allem wenn du viel joinst) und Spalten, die in WHERE oft mit = oder Bereichsabfragen (BETWEEN, >,

Guter Thread, Daniels OLTP/OLAP-Merksatz ist schon sehr treffend. Ich will aber noch mal betonen, wie tückisch die Inkonsistenz-Falle in der Praxis wirklich ist. Wenn du z.B. den Kundennamen redundant in 5 Tabellen speicherst und dann nur an 3 Stellen das Update-Skript anpasst, hast du irgendwann stille Dateninkonsistenzen, die keiner bemerkt, bis ein Report komische Zahlen auswirft. Das ist das eigentliche Risiko bei Denormalisierung – nicht die Performance, die stimmt ja meistens, sondern die Wartbarkeit über Jahre und mehrere Entwickler-Generationen hinweg.

In der Praxis gibt es da ein paar Kompromisse, die ich öfter gesehen habe:

• Materialized Views statt manuell denormalisierter Tabellen – die DB hält das selbst konsistent und du kannst sie zeitgesteuert oder bei Bedarf refreshen
• Trigger, die redundante Felder automatisch nachziehen, wenn sich die Quelle ändert (aber Vorsicht: Trigger können bei komplexer Logik selbst zur Fehlerquelle werden)
• ETL-Prozesse, die normalisierte OLTP-Daten regelmäßig in ein denormalisiertes Reporting-Schema überführen – sauber getrennt von den operativen Tabellen
• Event-driven Updates (z. B. über eine Message Queue), wenn's near-realtime sein muss

Mein Rat an Anna: Wenn du im Praktikum auf denormalisierte Tabellen stößt, frag konkret nach, wie die Konsistenz sichergestellt wird. Wenn die Antwort "das macht halt der Entwickler von Hand" ist, würde ich skeptisch werden – das ist erfahrungsgemäß die häufigste Quelle für Datenmüll in gewachsenen Systemen.

Daniels Merksatz trifft's gut, ich ergänz nochmal einen Punkt, der mir in der Praxis oft Kopfzerbrechen gemacht hat: die Abgrenzung Scrum Master vs. klassischer Teamlead. Das ist nämlich ein Denkfehler, den viele am Anfang machen, gerade wenn man aus klassischen Projektstrukturen kommt.

Ein Teamlead hat meistens disziplinarische oder zumindest fachlich-weisungsbefugte Verantwortung: er sagt, wer was macht, bewertet Leistung, greift bei Konflikten auch inhaltlich durch. Der Scrum Master hat das explizit nicht. Er ist kein Chef des Teams, sondern Prozess-Hüter und Moderator ohne Weisungsbefugnis. Wenn im Daily Chaos herrscht, sagt er nicht „macht das jetzt so", sondern fragt eher, woran es hakt und hilft, dass das Team selbst eine Lösung findet. Self-organizing Team ist da das Stichwort.

Typischer Fehler in der Praxis: Firmen besetzen die Scrum-Master-Rolle mit dem ehemaligen Teamlead und der fällt dann in alte Muster zurück, trifft inhaltliche Entscheidungen oder mischt sich in Priorisierung ein. Das konterkariert eigentlich das ganze Scrum-Konzept, weil die Verantwortung dann nicht mehr sauber getrennt ist.

Merksatz von mir: Scrum Master optimiert den Prozess, Teamlead optimiert (oft) Menschen und Ergebnisse direktiv. Deckt sich nicht automatisch.

Anna hat das eigentlich schon super erklärt, ich ergänz mal die Faustregel, mit der ich das in Excel-Schulungen immer erkläre (SVERWEIS/XVERWEIS-Denke hilft hier oft mehr als die Kreise): stell dir vor, die "führende" Tabelle ist die, deren Zeilen du auf jeden Fall im Ergebnis sehen willst, komplett, egal was die andere Seite liefert. Bei Left ist das die linke Tabelle, bei Right die rechte. Die andere Tabelle liefert nur "dazu", wenn sie was Passendes hat – findet sie nichts, kommt NULL statt echter Werte.

Praktischer Merksatz aus dem Alltag: "Die geführte Tabelle bettelt um Werte, kriegt sie aber nur, wenn's einen Treffer gibt." Kein Treffer = NULL, aber die Zeile selbst fliegt nicht raus.

Typischer Fehler, den ich bei Studierenden oft sehe: nach einem Left Join in der WHERE-Klausel auf die rechte Tabelle filtern (z. B. WHERE Betrag > 100). Damit killst du automatisch alle NULL-Zeilen und dein Left Join wird faktisch zum Inner Join. Wenn du NULLs explizit brauchst, muss der Filter in die ON-Bedingung, nicht ins WHERE.

Und zu Right Join: seh ich wie Anna, nutze ich in der Praxis so gut wie nie, weil man's fast immer sauberer als Left Join mit getauschter Reihenfolge schreiben kann. Für die Klausur trotzdem gut zu kennen.

Danke Daniel, super erklärt. Ich ergänz mal aus der Praxis-Perspektive, weil das Thema Skalierbarkeit oft zu theoretisch bleibt.

Der Vorteil zeigt sich vor allem, wenn ein Server ausfällt oder neu gestartet wird (z. B. bei Deployments). Bei Sticky Sessions verlieren alle Nutzer, die gerade auf diesem Server "hängen", ihre Session und müssen sich neu einloggen. Bei zustandslosen APIs merkt der Nutzer davon idealerweise gar nichts, weil die nächste Anfrage einfach von einem anderen Server im Cluster übernommen wird, ohne dass Session-Daten synchronisiert werden müssten.

Das macht auch Auto-Scaling in der Cloud viel einfacher: Server hochfahren, wenn Last steigt, wieder runterfahren, wenn sie sinkt, ohne sich Gedanken über Session-Replikation zu machen.

Nachteile in der Praxis:

• Jedes Token muss bei jeder Anfrage validiert werden, das kostet etwas Rechenzeit (meistens vernachlässigbar bei JWT, weil die Signatur lokal geprüft wird).
• Ein Token-Widerruf (z. B. bei Logout oder gesperrtem Account) ist tricky, weil der Server sich ja nichts merkt. Da braucht man dann meist eine Blacklist oder kurze Ablaufzeiten, was das "reine" Zustandslosigkeitsprinzip in der Praxis leicht aufweicht.

Für die Klausur würde ich mir merken: Zustandslosigkeit ist kein Selbstzweck, sondern eine bewusste Design-Entscheidung mit Trade-offs zwischen Einfachheit/Skalierbarkeit und etwas Zusatzaufwand pro Request.

Kann Daniels Punkte nur unterstreichen, besonders die Sache mit der Anforderungsstabilität. Ich hab mal ein Projekt begleitet, wo genau so eine Situation vorlag wie bei dir, Anna: Auftragsverwaltung als Kernprozess relativ klar, aber jede Abteilung wollte noch ihre Extras. Da wurde am Ende mit einem hybriden Modell gearbeitet, was für ne Hausarbeit auch ein spannender Ansatz sein kann, wenn du zeigen willst, dass du nicht nur Lehrbuchwissen abspulst.

Konkret lief das so: Die Grobplanung (Datenmodell, Kernprozesse, Schnittstellen zu ERP/Warenwirtschaft) wurde klassisch nach Wasserfall gemacht – Lastenheft, Architektur, Meilensteine, weil das Management feste Budgets und Termine wollte. Die eigentliche Umsetzung der einzelnen Module (v.a. die abteilungsspezifischen Auswertungen und Masken) lief dann in Scrum-Sprints mit Reviews alle zwei Wochen, wo die Fachabteilungen ihr Feedback einbringen konnten.

Für deine Fallstudie könntest du sowas als "Wasserfall für den stabilen Kern, Scrum für die variablen Anforderungen der Fachabteilungen" argumentieren. Wichtig ist nur, dass du sauber begründest, welcher Teil warum welchem Modell zugeordnet wird – sonst wirkt's wie ein fauler Kompromiss statt einer durchdachten Entscheidung. Merksatz aus der Praxis: Je näher am Kernsystem, desto stabiler die Anforderungen, je näher am Endnutzer/Fachbereich, desto mehr Änderungsbedarf.

Die O-Notation beschreibt nicht, wie schnell ein Programm ist, sondern wie die Laufzeit wächst, wenn die Eingabe größer wird. Deshalb fallen Konstanten weg: Ob eine Schleife 3 oder 5 Befehle pro Durchlauf hat, ändert am Wachstum nichts.

Warum das auch bei schnellen Computern zählt – Beispiel mit n = 1.000.000 Datensätzen und grob 10⁹ einfachen Operationen pro Sekunde:

• O(n log n): 1.000.000 · ca. 20 = 20 Millionen Schritte → etwa 0,02 Sekunden
• O(n²): 10¹² Schritte → rund 1.000 Sekunden, also über eine Viertelstunde

Und verdoppelst du n, wird O(n²) viermal so langsam, O(n log n) nur gut doppelt so langsam. Ein schnellerer Rechner verschiebt das Problem nur, das Wachstum bleibt.

Das System zum Ablesen:

1. Einzelne Anweisungen ohne Schleife: O(1).
2. Hintereinander stehende Teile: addieren, der größte Term gewinnt. O(n) + O(n²) = O(n²).
3. Verschachtelte Schleifen: multiplizieren. Äußere läuft n-mal, innere n-mal → O(n²).
4. Schleife, die den Bereich jedes Mal halbiert (z. B. i = i / 2 oder binäre Suche): O(log n). Frage dich: Wie oft kann ich n halbieren, bis 1 übrig ist? Genau log₂ n mal – bei einer Million sind das nur ca. 20.
5. Funktionsaufrufe nicht als 1 zählen, sondern die Kosten der Funktion einsetzen. Ein contains auf einer Liste in einer Schleife ist schon O(n) · O(n).

Merksatz: Nacheinander → addieren, ineinander → multiplizieren, halbieren → log.

Noch die Sicherheits- und die Cookie-Banner-Seite, weil das in Klausuren gern als Transferfrage kommt:

Warum ist die Session-ID so wertvoll?

Wer sie hat, ist für den Server du, ganz ohne Passwort (Session Hijacking). Deshalb setzt man beim Cookie Schutzattribute:

• HttpOnly: JavaScript kommt nicht an das Cookie ran. Das schützt vor dem Auslesen per eingeschleustem Skript (XSS).
• Secure: Das Cookie wird nur über HTTPS übertragen.
• SameSite: Der Browser schickt das Cookie bei Anfragen von fremden Seiten nicht (oder nur eingeschränkt) mit. Das hilft gegen CSRF, also wenn eine fremde Seite deinen Browser unbemerkt Aktionen in deinem Konto ausführen lässt.

Dazu kommen: neue Session-ID direkt nach dem Login, Timeout bei Inaktivität, und beim Logout die Session auf dem Server wirklich löschen, nicht nur das Cookie im Browser.

Und die Cookie-Banner?

Rechtlich geht es darum, ob etwas auf deinem Gerät gespeichert oder ausgelesen wird. Technisch unbedingt erforderliche Cookies, wie genau so ein Login-Session-Cookie oder der Warenkorb, brauchen keine Einwilligung. Einwilligungspflichtig sind z. B. Tracking- und Werbe-Cookies. Deshalb kannst du dich auch einloggen, wenn du im Banner alles ablehnst. Genau diese Unterscheidung „technisch notwendig vs. optional“ kennst du aus dem Marketing ja von der anderen Seite. 😉

Klassiker. 😄 Die gute Nachricht: Mit einem einfachen Feature-Branch-Workflow sind 90 % eurer Probleme weg.

1. main ist heilig: Da committet niemand direkt. In GitHub/GitLab kann man den Branch schützen, dann geht es technisch gar nicht mehr.
2. Pro Aufgabe ein Branch, nicht pro Person: z. B. feature/login, feature/warenkorb. Der Branch lebt nur so lange, bis die Aufgabe fertig ist – idealerweise ein paar Tage, nicht Wochen.
3. Vor dem Start immer den aktuellen Stand holen, also main pullen und davon abzweigen.
4. Fertig → Pull Request / Merge Request. Einer aus dem Team schaut drüber, dann wird in main gemergt.
5. Kleine Commits, oft integrieren. Je länger ein Branch weg ist, desto größer werden die Konflikte. Das ist der eigentliche Hebel.

Zu dem „einfach meine Version genommen“: Das passiert, wenn man einen Konflikt nicht liest, sondern wegklickt. Git überschreibt nicht von selbst, es zeigt dir beide Versionen an der Konfliktstelle markiert an. Der Konflikt muss inhaltlich gelöst werden – im Zweifel mit der Person zusammen, die die andere Änderung gemacht hat.

Gute Nachricht übrigens: Die überschriebene Arbeit ist sehr wahrscheinlich nicht weg. Solange die Commits existierten, findet ihr sie über git reflog bzw. in der History und könnt sie zurückholen.

Daniel hat das Technische abgedeckt, ich nehme den Beurteilungsteil – der bringt in der Klausur die Punkte, weil dort das „es kommt darauf an“ hingehört.

Container sind die bessere Wahl, wenn:

• die Anwendung zustandslos ist und du sie einfach mehrfach starten willst (Webdienste, Schnittstellen)
• du viele kleine Dienste betreibst (Microservices)
• du eine Build- und Auslieferungspipeline hast und bei jeder Änderung neu ausrollst
• Entwicklung, Test und Produktion identisch sein sollen – das Image, das getestet wurde, ist exakt das, was produktiv läuft. Damit stirbt das berühmte „Bei mir lief es doch“
• Dichte zählt: Auf einem Host laufen problemlos Dutzende Container, aber nur eine Handvoll VMs

Eine VM brauchst du weiterhin, wenn:

• ein anderes Betriebssystem nötig ist – ein Linux-Host kann keine Windows-Prozesse ausführen, dafür muss ein eigener Kernel her
• die Isolation stark sein muss, etwa bei fremden Mandanten auf derselben Hardware. Geteilter Kernel heißt: Eine Kernel-Lücke betrifft potenziell alle Container des Hosts – das ist die größere Angriffsfläche
• Altsoftware läuft, die eine bestimmte Systemumgebung erwartet, oder du eigene Kernel-Module bzw. spezielle Treiber brauchst
• zertifizierte, abgeschottete Umgebungen regulatorisch gefordert sind

Wichtig fürs Verständnis: In der Praxis ist das kein Entweder-oder. In der Cloud laufen Container fast immer innerhalb von VMs – die VM liefert die harte Trennung zwischen Kunden, der Container die schnelle Auslieferung der Anwendung. Schreib diesen Satz in die Klausur, dann ist der Beurteilungsteil beantwortet.

Noch drei Stolpersteine aus der Praxis:

1. Container sind vergänglich. Alles, was im Container geschrieben wird, ist beim Neustart weg. Daten gehören in Volumes oder in eine externe Datenbank. Eine Datenbank im Container ohne Volume ist ein garantierter Datenverlust.
2. Sicherheit ist Arbeit. Nicht als root im Container laufen, nur Images aus vertrauenswürdiger Quelle mit festem Versions-Tag, regelmäßig neu bauen. Ein Image ist eine Momentaufnahme – nach drei Monaten stecken bekannte Lücken darin, auch wenn scheinbar nichts passiert ist.
3. Betriebskomplexität. Bei drei Containern reicht die Kommandozeile, ab ein paar Dutzend brauchst du Orchestrierung – und die kostet Know-how. Die eingesparten Serverkosten holt der Betriebsaufwand schnell wieder rein. Das ist die betriebswirtschaftliche Seite der Antwort, die in einer WiInf-Klausur gern gesehen wird.

Kleiner Nachtrag aus der Praxis, weil das in Projekten regelmäßig schiefgeht: Wie migriert man eigentlich von einem alten Hashverfahren auf ein neues, wenn man die Passwörter ja gar nicht kennt?

Die übliche Lösung ist ein Rehash beim Login:

1. Der Nutzer meldet sich an, das System prüft das Passwort gegen den alten Hash.
2. Stimmt es, liegt das Klartextpasswort genau in diesem Moment ohnehin im Speicher.
3. Jetzt wird es mit dem neuen Verfahren (z. B. bcrypt oder Argon2) gehasht und der alte Wert überschrieben.

Damit das funktioniert, speichert man den Hash mit einem Präfix, der Algorithmus und Parameter enthält. Bei bcrypt steht das direkt am Anfang des Strings, etwa $2b$12$… – die 12 ist der Kostenfaktor. Deshalb die Datenbankspalte großzügig dimensionieren und nicht auf exakt 32 oder 64 Zeichen festnageln.

Für Konten, die sich jahrelang nicht anmelden, bleibt der alte Hash natürlich liegen. Dafür gibt es zwei Wege: den alten Hash in den neuen einwickeln (das neue Verfahren auf den alten Hashwert anwenden) oder die Konten nach einer Frist sperren und einen Passwort-Reset erzwingen.

Klausurtauglicher Merksatz: Man migriert nicht die Passwörter, sondern die Hashes – und zwar dann, wenn der Nutzer das Passwort sowieso gerade eingibt.