Beiträge von DanielIT

Hallo zusammen, zum Bestellbeispiel noch eine Ergänzung aus meiner Erfahrung: wenn bei euch Rechnung und Lieferschein wirklich immer beide ohne Bedingung laufen und nur die Sonderfreigabe optional dazukommt, könnte man das auch sauber mit AND + XOR kombinieren, statt alles in ein OR zu packen. Also: AND-Split für Rechnung/Lieferschein (die laufen fix parallel), und zusätzlich ein separates XOR, das entscheidet, ob der Sonderfreigabe-Pfad überhaupt existiert. Viele Klausuren akzeptieren beide Lösungen, aber in manchen Lehrbüchern wird das OR-Gateway bewusst vermieden, weil es beim Zusammenführen (Join) tückisch ist – das OR-Join muss nämlich "wissen", wie viele Pfade beim Split tatsächlich aktiviert wurden, sonst wartet es ewig oder synchronisiert falsch. Das ist in der Praxis eine der häufigsten Fehlerquellen bei BPMN-Klausuren.

Für die schnelle Erkennung im Prozesstext achte ich immer auf folgende Signalwörter:

• "entweder... oder", "je nachdem" → XOR
• "gleichzeitig", "parallel dazu", "unabhängig davon" → AND
• "zusätzlich, falls", "kann auch", "optional zusätzlich" → OR

Und als Merksatz für die Klausur: Wenn du dir unsicher bist zwischen AND und OR, frag dich, ob es einen Fall gibt, in dem nur ein einziger der Pfade läuft. Wenn ja, ist es garantiert kein AND mehr, sondern OR oder sogar XOR.

Hallo Anna, das Problem kenne ich noch gut aus meinem ersten Projekt – man denkt am Anfang "ist doch eh nur eine Handvoll Datensätze" und am Ende ist alles vermischt. Für den Rahmen eines Semesterprojekts braucht ihr wirklich keine komplette Serverlandschaft, mehrere Datenbankinstanzen plus saubere Konfigurationstrennung reichen völlig aus.

So würde ich es aufbauen:

• Pro Umgebung eine eigene Datenbank – z. B. projekt_dev, projekt_test, projekt_prod. Über Docker ist das schnell erledigt, ihr könnt auch einfach mehrere Container oder bei lokalen DBs mehrere Schemas anlegen.
• Die Connection-Strings landen nicht hartcodiert im Code, sondern in Umgebungsvariablen (z. B. über eine .env-Datei, die nicht ins Repository eingecheckt wird). So lädt eure Anwendung je nach Umgebung automatisch die passende Verbindung.
• Für das Produktivsystem nur noch Migrationsskripte laufen lassen (z. B. mit einem Migrationstool eurer Wahl), keine manuellen Testinserts mehr.

Typischer Fehler, den wir auch gemacht haben: Testdaten "mal eben schnell" direkt per SQL in die Produktiv-DB schreiben, weil es gerade praktisch war. Das rächt sich garantiert. Merksatz, den ich mir seitdem gebe: Produktivdaten werden nie manuell angefasst, sondern nur über Anwendung oder Migration verändert.

Mit dieser Minimal-Lösung – getrennte DBs plus Env-Variablen – habt ihr schon 90 % des Nutzens einer "echten" Umgebungstrennung, ohne dass ihr dafür extra Server aufsetzen müsst.

Hallo Anna, die Faustregel, die mir in unserem Studium mal wirklich geholfen hat: Lastenheft = Was, Pflichtenheft = Wie. Das Lastenheft beschreibt aus Sicht des Auftraggebers die Anforderungen und Ziele, ohne dass dort schon eine technische Lösung vorgegeben wird. Der Auftraggeber kennt im Idealfall seine fachlichen Prozesse, aber nicht, wie eine Datenbank aufgebaut sein muss. Deine Datenbankstruktur gehört deshalb tatsächlich eher ins Pflichtenheft.

Beispiel, das ich mir dazu immer merke:

• Lastenheft: "Kundendaten sollen zentral erfasst und für mehrere Abteilungen einsehbar sein, Reaktionszeit bei Abfragen unter 2 Sekunden."
• Pflichtenheft: "Umsetzung über eine relationale Datenbank mit Tabellen Kunde, Adresse, Ansprechpartner, Zugriff über REST-Schnittstelle, Indexierung auf Kundennummer zur Performanceoptimierung."

Das Lastenheft bleibt also auf der Ebene von Zielen und Anforderungen, das Pflichtenheft geht auf konkrete technische Umsetzung runter – inklusive Architektur, Schnittstellen, eingesetzter Technologien. Ein typischer Fehler ist tatsächlich, dass man im Lastenheft schon in Lösungen denkt statt in Anforderungen. Wenn du merkst, dass du Begriffe wie "Tabelle", "API" oder "Server" schreibst, bist du eigentlich schon im Pflichtenheft gelandet.

Wie detailliert das Pflichtenheft sein muss, hängt vom Projekt ab – bei einer Projektarbeit würde ich aber ruhig bis auf Schnittstellen- und grobe Datenstruktur-Ebene gehen, das zeigt, dass du das Konzept verstanden hast.

Sitze gerade an meinem Projektantrag für ein WI-Modul und muss die Softwarearchitektur begründen, nicht nur umsetzen. Geplant ist eine kleine Anwendung (ungefähr 3-4 fachliche Bereiche, z. B. Nutzerverwaltung, Bestellung, Produktkatalog), die am Ende auch nur von mir alleine entwickelt und präsentiert wird.

Jetzt überlege ich, ob ich das Ganze als Microservices-Architektur aufziehe, weil das Thema gerade in der Vorlesung drankam und sich in der Doku bestimmt gut macht. Andererseits lese ich überall, dass Microservices ihren Mehrwert eigentlich erst bei großen Teams und unabhängig deploybaren Komponenten ausspielen – bei mir wäre das aber overengineered, oder?

• Macht es didaktisch überhaupt Sinn, Microservices für ein Ein-Personen-Projekt zu wählen, nur um die Architektur zu zeigen?
• Wie würdet ihr die Entscheidung Monolith vs. Microservices in so einem Kontext fachlich sauber begründen, ohne dass es nach „ich wollte halt den Hype-Begriff benutzen“ klingt?
• Gibt es vielleicht einen Mittelweg (z. B. modularer Monolith), den man in so einer Projektarbeit gut argumentieren kann?

Würde mich über eure Einschätzung freuen, gerade auch im Hinblick darauf, was in der Bewertung meist besser ankommt.

Hi Anna, zu deiner Kernfrage "anonym = raus aus der DSGVO" kann ich aus einem ähnlichen Projekt bei uns im Studium berichten: Das ist der Punkt, an dem die meisten stolpern, weil "anonym" und "pseudonym" ständig durcheinandergeworfen werden, technisch aber ein großer Unterschied ist.

• Pseudonymisierung: Du ersetzt den Namen durch einen Code (z. B. Teilnehmer_017), hältst aber irgendwo eine Zuordnungstabelle vor. Das fällt weiterhin unter die DSGVO, weil die Re-Identifizierung grundsätzlich möglich ist – auch wenn du selbst nie draufschaust.
• Anonymisierung: Es gibt keinerlei Möglichkeit mehr, mit vertretbarem Aufwand auf die Person zurückzuschließen – auch nicht durch Kombination mit anderen Daten. Erst dann greift die DSGVO tatsächlich nicht mehr.

Genau da liegt bei Umfragen die Falle: Wenn du z. B. Studiengang, Semester und Alter gleichzeitig abfragst, kann das bei kleinen Gruppen (50-80 Leute) schon wieder re-identifizierend wirken ("die eine Person aus dem 7. Semester BWL mit 35 Jahren"). Das nennt man auch Re-Identifikationsrisiko durch Kombination von Quasi-Identifikatoren. Also: freie Textfelder vermeiden, grobe statt feine Kategorien nutzen (z. B. Altersgruppen statt genauem Alter), und technische Metadaten wie IP-Adressen beim Tool wirklich abschalten, nicht nur "nicht anzeigen lassen".

Zur Einwilligung: Ein klar formulierter Hinweistext mit Opt-in direkt vor Beginn reicht in der Praxis für studentische Projekte meist aus, wichtig ist nur Transparenz über Zweck, Speicherdauer und Freiwilligkeit.

Hallo Anna, der Grundgedanke ist tatsächlich ein bisschen mehr als nur "ER ist für Datenbanken, UML für Software". Der eigentliche Unterschied liegt in der Denkweise dahinter.

Beim ER-Modell denkst du strikt aus der Datensicht: Welche Entitäten gibt es, welche Attribute haben sie, wie hängen sie zusammen. Es gibt dort bewusst kein Konzept für Verhalten oder Methoden, weil ER-Diagramme historisch für den konzeptionellen Datenbankentwurf entwickelt wurden. Am Ende überführst du das Ganze ja meistens in Tabellen mit Primär- und Fremdschlüsseln.

Beim UML-Klassendiagramm denkst du objektorientiert. Eine Klasse hat nicht nur Attribute, sondern auch Methoden, also Verhalten. Zusätzlich kennt UML Konzepte wie Vererbung, Interfaces, Sichtbarkeiten (public/private) oder Aggregation vs. Komposition, die im klassischen ER-Modell so nicht vorgesehen sind. Das heißt: Ein Klassendiagramm beschreibt nicht nur, wie Daten strukturiert sind, sondern auch, wie Objekte sich zur Laufzeit verhalten und miteinander interagieren.

In der Praxis läuft es oft so:

• Fachliche/konzeptionelle Modellierung der Datenbank → ER-Diagramm
• Design der Anwendungslogik/Softwarearchitektur → UML-Klassendiagramm

Bei kleinen, rein datenlastigen Systemen reicht oft ER allein. Sobald aber Programmlogik eine größere Rolle spielt, würde ich wirklich beides getrennt betrachten, weil sie unterschiedliche Fragen beantworten. Insofern ist eure Übung schon sehr praxisnah, auch wenn es sich bei einfachen Beispielen wie Kunde/Bestellung/Produkt optisch ähnlich anfühlt.

Hallo Markus, dein Verständnis ist im Kern schon richtig, nur würde ich es noch etwas sauberer als Schichtenmodell aufziehen, dann fällt die Zuordnung in der Klausur leichter. Stell dir folgende Schichten vor, von unten nach oben:

• Netzwerk/Hardware
• Virtualisierung
• Betriebssystem
• Middleware/Laufzeitumgebung
• Daten
• Anwendung

Je nach Modell verschiebt sich die Grenze, ab der der Kunde zuständig ist, immer weiter nach oben:

• IaaS: Anbieter liefert nur Hardware/Virtualisierung (Rechenleistung, Speicher, Netzwerk). Alles ab Betriebssystem aufwärts macht der Kunde selbst. Beispiel: Du mietest einen virtuellen Server und installierst dir Linux und deine eigene Webanwendung selbst drauf.
• PaaS: Anbieter übernimmt zusätzlich Betriebssystem und Laufzeitumgebung (z. B. eine vorkonfigurierte Umgebung für Java oder Python). Der Kunde liefert nur noch seinen Anwendungscode und die Daten. Beispiel: Du lädst deinen Programmcode hoch, um Updates, Patches und Skalierung des Unterbaus kümmert sich der Anbieter.
• SaaS: komplett fertige Anwendung inklusive Daten, Kunde nutzt sie nur über Browser/App. Beispiel: ein Office-Paket oder CRM-System aus der Cloud, bei dem du dich nur noch einloggst.

Als Eselsbrücke hat mir geholfen: Je weiter oben das "aaS" ansetzt (Infrastructure, Platform, Software), desto weniger Technikverantwortung bleibt beim Kunden, dafür sinkt aber auch die Kontrolle/Flexibilität. In der Klausur würde ich bei solchen Fragen immer explizit die Schichtgrenze benennen, das zeigt dem Korrektor, dass du das Prinzip verstanden hast und nicht nur die drei Begriffe auswendig gelernt hast.

Hallo Markus, das Thema kenne ich gut, bei uns in der Wirtschaftsinformatik taucht Clean Code ständig in den Programmier- und Softwareentwicklungsmodulen auf. Deine Beobachtung mit der Pause trifft den Kern eigentlich schon ziemlich genau.

Ich mache das mittlerweile fast wie ein Experiment mit mir selbst: Wenn ich ein Projekt abgebe und es nach 3-4 Wochen wegen Korrektur oder Rückfragen nochmal aufmachen muss, merke ich sofort, ob ich sauber gearbeitet habe oder nicht. Bei schlecht benannten Variablen wie temp2 oder x brauche ich teilweise 20 Minuten, um den eigenen Gedankengang zu rekonstruieren. Bei sprechenden Namen und kleinen, klar abgegrenzten Funktionen reicht ein kurzer Blick.

Ein paar Erfahrungswerte von mir:

• Sprechende Namen kosten kaum Mehraufwand, wenn man sie sich direkt beim Schreiben überlegt statt hinterher umzubenennen.
• Kleine Funktionen zahlen sich vor allem beim Debuggen aus, weil man Fehler viel schneller eingrenzen kann.
• Ein kurzer Kommentar über komplexeren Logikblöcken ersetzt oft 10 Minuten Grübeln beim zweiten Lesen.

Zur Bewertung: Bei uns wird das in den Rubrics meistens explizit unter "Code-Qualität" oder "Wartbarkeit" gelistet, also kein Nice-to-have, sondern ein fester Punkteblock. Insofern lohnt sich der Aufwand doppelt: für die Note und für dein zukünftiges Ich, das in sechs Wochen vor dem eigenen Code sitzt und sich fragt, was da eigentlich passiert.

Sitze gerade an meinem Hochschulprojekt (Code + Doku) und nutze dafür Git mit einem Remote-Repo. Jetzt frage ich mich aber, ob ich damit eigentlich schon ausreichend abgesichert bin oder ob das ein Trugschluss ist.

Mein Gedankengang: Ich habe ja eine lokale Kopie und eine Remote-Kopie, also quasi zwei Stände. Aber ist das wirklich ein Backup im klassischen Sinne? Mir kommt da ein unangenehmes Szenario in den Kopf:

• Meine Festplatte stirbt (lokales Repo weg)
• Der Remote-Anbieter hat zeitgleich einen Ausfall, ich werde gehackt, oder ich lösche aus Versehen das Repo dort (z. B. durch einen falschen force-push oder ein falsch gesetztes Recht)

Dann stehe ich komplett ohne Projekt da, oder? Git synchronisiert ja im Grunde nur Zustände, ersetzt aber keine unabhängige Sicherungskopie, so wie ich das verstehe. Oder liege ich da falsch und es gibt Mechanismen, die mir das nicht bewusst sind (reflog, irgendwelche Caches)?

Macht ihr euch da zusätzlich Gedanken zu und sichert euer Projekt noch separat, z. B. auf einer externen Platte oder einem Cloud-Speicher? Oder ist das übertrieben und Git-Remote reicht in der Praxis locker aus?

Sitze gerade in meinem Praktikum an einer Anwendung mit einer ziemlich großen Tabelle (mehrere Millionen Zeilen) und sollte die Performance von ein paar Abfragen verbessern. Klassischer Fall, dachte ich mir: Index auf die Spalten setzen, die oft in WHERE-Klauseln auftauchen, fertig. Hat auch super funktioniert, die SELECT-Abfragen waren danach spürbar schneller.

Jetzt habe ich aber gemerkt, dass die INSERT- und UPDATE-Vorgänge auf genau dieser Tabelle merklich langsamer geworden sind, seit ich mehrere Indizes gesetzt habe. Macht ja irgendwie auch Sinn, weil die Indizes bei jeder Schreiboperation mitgepflegt werden müssen, aber so richtig ein Gefühl dafür, wo die Grenze liegt, habe ich noch nicht.

Konkrete Fragen an euch:

• Gibt es eine Faustregel, wie viele Indizes pro Tabelle noch okay sind, bevor es sich negativ bemerkbar macht?
• Wie geht ihr vor, um vorher abzuschätzen, ob sich ein Index überhaupt lohnt (Verhältnis Lesezugriffe zu Schreibzugriffe)?
• Gibt es Tools oder Vorgehensweisen, mit denen man das systematisch analysiert, statt einfach auszuprobieren?

Bin für jeden Praxistipp dankbar, gerade weil das in der Theorie im Studium immer recht oberflächlich behandelt wurde.

Hallo Anna, das Thema hatte ich im letzten Semester auch bei einem Praxisprojekt und kann deine Verwirrung gut nachvollziehen – in der Theorie klingt Normalisierung erstmal "immer gut", in der Praxis sieht das oft anders aus.

Der Kerngedanke: Normalisierung optimiert für konsistente Schreiboperationen, Denormalisierung optimiert für schnelle Leseoperationen. Das klassische Beispiel sind Reporting- und Analytics-Systeme (Stichwort Data Warehouse, Star-Schema). Dort willst du nicht bei jeder Abfrage über fünf, sechs Tabellen joinen, sondern hast z. B. eine große Faktentabelle mit redundant gespeicherten Attributen aus den Dimensionstabellen. Das spart massig Joins, und genau Joins sind bei großen Datenmengen oft der Performance-Killer.

Typische Szenarien, die mir noch einfallen:

• Caching von berechneten Werten, z. B. eine Spalte "Gesamtsumme_Bestellung", damit nicht bei jedem Seitenaufruf aggregiert werden muss
• Historisierung: wenn sich z. B. ein Kundenname ändern darf, aber alte Rechnungen den Namen zum Zeitpunkt der Bestellung zeigen sollen, speichert man ihn bewusst redundant mit ab
• Systeme mit sehr viel mehr Lese- als Schreibzugriffen (z. B. Produktkataloge im E-Commerce)

Nachteile neben den komplexeren Updates: höherer Speicherbedarf, Gefahr von inkonsistenten Daten, wenn Updates vergessen werden, und du brauchst oft zusätzliche Logik (Trigger, Batch-Jobs), um die Redundanzen synchron zu halten. Merksatz, den ich mir gemerkt habe: "Normalisieren für OLTP, denormalisieren für OLAP" – das deckt schon einen Großteil der Praxisfälle ab.

Hallo Anna, das Thema hatte ich auch erst in der Theorie und später im Werkstudentenjob konkret erlebt. Zu deinem Beispiel mit der nicht umsetzbaren Anforderung: Das ist tatsächlich erstmal eine fachliche Frage, also PO-Territorium. Das Team meldet im Daily oder notfalls sofort, dass die Anforderung technisch nicht wie beschrieben umsetzbar ist, und der PO entscheidet dann, ob die Anforderung angepasst, vertagt oder aus dem Sprint genommen wird. Er kennt ja den fachlichen Kontext und die Prioritäten im Product Backlog am besten.

Die Priorisierung selbst ist bei uns immer strikt PO-Sache gewesen. Das Team darf natürlich Einwände bringen, etwa technische Abhängigkeiten aufzeigen, aber die finale Entscheidung, was oben im Backlog steht, liegt beim PO. Der Scrum Master mischt sich da inhaltlich nicht ein, sondern sorgt eher dafür, dass der Prozess dahinter funktioniert, also zum Beispiel dass Refinement-Termine stattfinden, in denen genau solche Konflikte besprochen werden können, bevor sie im Sprint eskalieren.

Mein Merksatz dazu: Der PO verantwortet das Ergebnis des Backlogs, der Scrum Master verantwortet, dass der Weg dorthin reibungslos läuft. Überschneidungen gibt es trotzdem, gerade wenn der Scrum Master merkt, dass Priorisierungskonflikte im Team an mangelnder Kommunikation liegen. Dann moderiert er, entscheidet aber nicht inhaltlich.

Hallo Markus, das Prinzip klickt bei den meisten erst, wenn man sich den Gegenentwurf anschaut, also die klassische Session-basierte Anmeldung.

Stell dir vor, du loggst dich auf einer Webseite ein. Bei einer zustandsbehafteten Lösung merkt sich der Server: "Aha, dieser Nutzer ist jetzt eingeloggt" und legt dafür eine Session im Arbeitsspeicher an. Jede weitere Anfrage von dir wird dann diesem gespeicherten Zustand zugeordnet, meist über eine Session-ID im Cookie.

Bei REST läuft das anders: Beim Login schickst du deine Zugangsdaten, der Server prüft sie und gibt dir ein Token zurück (z. B. ein JWT). Dieses Token schickst du ab jetzt bei jeder Anfrage im Header mit. Der Server muss sich also nichts merken, sondern prüft bei jeder einzelnen Anfrage erneut anhand des Tokens, wer du bist und ob du berechtigt bist. Der Zustand "eingeloggt" steckt quasi im Token selbst, nicht im Server.

Der Vorteil zeigt sich bei Skalierung: Wenn du mehrere Server hinter einem Load Balancer hast, ist es egal, welcher Server deine Anfrage bearbeitet, weil keiner von ihnen einen internen Zustand über dich vorhalten muss. Bei Session-basierten Systemen müsste entweder immer derselbe Server dich bedienen (Sticky Sessions) oder die Session-Infos müssten zwischen allen Servern synchron gehalten werden, was zusätzlichen Aufwand und Fehleranfälligkeit bedeutet.

Merksatz: Zustandslosigkeit heißt nicht "der Client speichert nichts", sondern "der Server merkt sich nichts zwischen zwei Anfragen". Der Preis dafür ist tatsächlich etwas mehr Datenverkehr pro Request, aber der Gewinn an Ausfallsicherheit und horizontaler Skalierbarkeit überwiegt in der Praxis deutlich.

Um das Ablesen aus Code noch etwas greifbarer zu machen, hier ein kleines Beispiel, wie man an einer Funktion direkt erkennt, welche Klasse vorliegt:

• Zwei verschachtelte Schleifen über dieselbe Liste, z. B. um Duplikate zu finden, indem jedes Element mit jedem anderen verglichen wird → die äußere Schleife läuft n-mal, die innere ebenfalls n-mal, also O(n²). Das erkennt man daran, dass die Laufzahl der inneren Schleife von n abhängt und nicht konstant ist.
• Eine einzelne Schleife über die Liste, bei der pro Element nur ein Hash-Set-Lookup passiert (contains/add), ist O(n), weil der Lookup selbst im Schnitt O(1) kostet.
• Eine Schleife, die vorher sortiert (z. B. über eine Standard-Sortierfunktion) und danach einmal linear durchläuft, landet bei O(n log n), weil sich Sortieren und Durchlauf addieren und der größere Term (n log n) das Ergebnis bestimmt.

Wenn ihr in der Übung unsicher seid, hilft es, jede Schleife einzeln zu zählen und sich zu fragen: „Hängt die Anzahl der Durchläufe von n ab, und wenn ja, wie?“ Bei geschachtelten Schleifen multipliziert sich das, bei aufeinanderfolgenden Blöcken addiert sich das (und der dominante Term gewinnt). Wer das an ein bis zwei eigenen Codebeispielen einmal wirklich durchgezählt hat, tut sich in der Klausur deutlich leichter als beim reinen Auswendiglernen der Tabelle.

Hallo Anna, das Problem kenne ich noch aus meiner eigenen Fallstudie – die Theorie sitzt, aber die Anwendung auf ein konkretes Beispiel ist der eigentliche Knackpunkt. Ich würde das Ganze an ein paar harten Kriterien festmachen, die du dann jeweils kurz für dein Auftragsverwaltungssystem durchgehst:

• Anforderungsstabilität: Sind die Anforderungen zu Projektbeginn vollständig und stabil beschreibbar, oder ändern sie sich erfahrungsgemäß während der Umsetzung? Bei dir deutet die Beteiligung mehrerer Abteilungen eher auf Änderungsbedarf hin – das spricht für Scrum.
• Verfügbarkeit und Rolle des Auftraggebers: Wasserfall funktioniert gut, wenn der Kunde am Anfang ein Lastenheft abgibt und dann erst wieder bei der Abnahme auftaucht. Scrum setzt voraus, dass ein Product Owner regelmäßig verfügbar ist und Feedback gibt. Frag dich also: Kann/will dein Auftraggeber kontinuierlich eingebunden werden?
• Risiko und Komplexität: Je mehr Schnittstellen zu bestehenden Systemen, desto sinnvoller ist es, früh in kleinen Increments zu testen statt erst am Ende ein fertiges System zu liefern.
• Unternehmenskultur: Ist das Unternehmen an feste Meilensteine und Dokumentation gewöhnt (klassisches Projektcontrolling), oder gibt es schon Erfahrung mit iterativem Arbeiten?

Für die Hausarbeit würde ich diese vier Punkte tabellarisch gegenüberstellen und dann begründen, warum in deinem Fall z. B. die Mischung aus stabilem Kernprozess (Auftragsverwaltung) und unsicheren Detailanforderungen (Abteilungsspezifika) für ein hybrides Vorgehen oder zumindest für Scrum mit klar definiertem Product Backlog spricht. Das wirkt deutlich fundierter als eine reine Pro-Contra-Liste.

Ein Praxisbeispiel, weil genau das im Job ständig passiert: Dubletten in einer Kundenliste finden.

• Naiv: jeden Eintrag mit jedem anderen vergleichen → zwei verschachtelte Schleifen → O(n²). Mit 500 Testdaten merkt man nichts, mit 2 Millionen Kunden im Produktivsystem läuft der Job über Nacht.
• Sortieren, dann Nachbarn vergleichen: Sortieren kostet O(n log n), der Durchlauf danach O(n) → insgesamt O(n log n).
• Mit Hash-Set: jeden Eintrag einmal nachschlagen/einfügen, im Schnitt O(1) → insgesamt O(n), dafür mehr Speicher.

Das zeigt auch den typischen Trade-off: Zeit gegen Speicher. Und es zeigt, warum die Wahl der Datenstruktur oft wichtiger ist als Mikrooptimierung im Code.

Für die Übung noch ein Hinweis: Achte darauf, ob nach Worst Case oder Durchschnitt gefragt ist. Quicksort ist im Schnitt O(n log n), im schlechtesten Fall aber O(n²). Das wird in Klausuren gern abgefragt.

Guter Einstieg, denn genau das ist der Widerspruch, den die Technik auflöst. HTTP selbst merkt sich nichts. Jede Anfrage ist für den Server erst mal neu. Also muss der Browser bei jeder Anfrage etwas mitschicken, woran der Server dich wiedererkennt.

Variante 1: Session + Cookie (serverseitiger Zustand)

1. Du loggst dich ein, der Server prüft das Passwort.
2. Der Server legt eine Session an, also einen Datensatz bei sich („Sitzung 8f3a… gehört zu Sophie, eingeloggt seit 18:02“).
3. Zurück an den Browser geht nur die Session-ID, gespeichert in einem Cookie.
4. Bei jedem weiteren Klick schickt der Browser das Cookie automatisch mit, und der Server schlägt die ID nach.

Das heißt: Das Cookie ist nur der Transportbehälter, die Session ist der Zustand auf dem Server. Nicht dasselbe.

Variante 2: Token, z. B. JWT (Zustand steckt im Token)

Hier speichert der Server nichts. Er gibt dir nach dem Login ein signiertes Token, in dem schon drinsteht, wer du bist und bis wann es gilt. Bei jeder Anfrage wird das Token mitgeschickt (oft im Authorization-Header), und der Server prüft nur die Signatur. Das ist praktisch bei APIs, Apps und verteilten Systemen, weil kein zentraler Session-Speicher nötig ist.

Der klassische Trade-off für die Klausur:

• Session: leicht widerrufbar (Server löscht die Session → sofort ausgeloggt), aber der Server muss Zustand halten.
• Token: skaliert gut und ist zustandslos, aber ein ausgestelltes Token bleibt bis zum Ablauf gültig. Deshalb gibt es kurze Laufzeiten plus Refresh-Token.

Merksatz: Session = Server merkt sich dich. Token = du trägst deinen Ausweis selbst mit. Das Cookie ist nur eine Möglichkeit, das eine oder andere mitzuschicken.

Zu Merge vs. Rebase, weil das im Skript meistens verwirrend erklärt ist:

• Merge führt zwei Entwicklungsstränge zusammen und erzeugt dafür einen eigenen Merge-Commit. Die History zeigt ehrlich, dass parallel gearbeitet wurde. Nichts wird umgeschrieben.
• Rebase nimmt deine Commits und setzt sie so auf den aktuellen Stand von main, als hättest du erst jetzt angefangen. Ergebnis: eine lineare, aufgeräumte History. Dafür werden deine Commits neu geschrieben (neue Hashes).

Daraus folgt die eine Regel, die man sich merken muss: Niemals Commits rebasen, die andere schon gepullt haben. Also: Rebase nur auf deinem eigenen, noch privaten Feature-Branch, um ihn vor dem Pull Request auf den neuesten main-Stand zu bringen. Alles, was geteilt ist → Merge.

Für euer Uniprojekt würde ich ehrlich sagen: Nehmt einfach Merge, das ist fehlertoleranter. Rebase ist Kosmetik für die History, kein Muss.

Und noch ein unterschätzter Konfliktgrund in gemischten Teams: Zeilenenden und Autoformatierung. Wenn einer auf Windows (CRLF) und einer auf Mac/Linux (LF) arbeitet oder jeder einen anderen Formatter nutzt, ändert sich scheinbar jede Zeile einer Datei – und schon kollidiert alles. Legt eine .gitattributes und eine gemeinsame Formatter-Konfiguration ins Repo, dann ist Ruhe.

Gute Frage, und die Antwort ist tatsächlich ein sauberer Einzeiler, den du dir merken kannst: Eine VM virtualisiert die Hardware, ein Container virtualisiert das Betriebssystem. Alles andere folgt daraus.

Virtuelle Maschine: Auf der echten Hardware läuft ein Hypervisor, der so tut, als gäbe es mehrere vollständige Rechner. Jede VM bekommt virtuelle CPU, virtuellen Arbeitsspeicher, virtuelle Festplatte und Netzwerkkarte – und darauf installierst du ein komplettes Gastbetriebssystem mit eigenem Kernel. Deine 8 GB und die Bootzeit sind genau das: Du startest einen ganzen Rechner, nur eben in Software.

Für die Klausur die übliche Unterteilung:

• Typ 1 (bare metal): Hypervisor läuft direkt auf der Hardware – Rechenzentrumsbetrieb, performanter
• Typ 2 (hosted): Hypervisor läuft als Programm in einem normalen Betriebssystem – das ist das, was du auf dem Laptop machst

Container: Hier gibt es kein zweites Betriebssystem. Alle Container auf einem Host teilen sich denselben Kernel und sind im Kern nur besonders gut abgeschottete Prozesse. Diese Abschottung leistet der Kernel selbst über zwei Mechanismen: Namespaces sorgen dafür, dass ein Container nur seine eigenen Prozesse, sein eigenes Dateisystem und sein eigenes Netzwerk sieht, und cgroups begrenzen, wie viel CPU und Arbeitsspeicher er verbrauchen darf.

Damit ist auch beantwortet, was ihm fehlt: das eigene Betriebssystem. Im Image stecken nur deine Anwendung, ihre Bibliotheken und ein paar Systemdateien – kein Kernel und nicht die vielen Dienste, die eine vollwertige Installation mitbringt. Daher MB statt GB und Sekunden statt Minuten, weil eben kein Bootvorgang stattfindet, sondern nur ein Prozess gestartet wird.

Zwei Begriffe, die gern verwechselt werden: Ein Image ist die unveränderliche Vorlage, ein Container die laufende Instanz davon – wie Klasse und Objekt in der objektorientierten Programmierung. Aus einem Image kannst du beliebig viele Container starten. Beschrieben wird das Image in einer Build-Datei (Basis-Image, Abhängigkeiten, Anwendung, Startbefehl), es besteht aus aufeinander aufbauenden Schichten und wird über eine Registry verteilt. Gemeinsame Schichten liegen auf dem Host nur einmal – noch ein Grund für den kleinen Fußabdruck.

Der Unterschied ist tatsächlich der Kern der Aufgabe, deshalb einmal sauber:

Verschlüsselung ist umkehrbar. Mit dem passenden Schlüssel wird aus dem Geheimtext wieder der Klartext. Das ist gewollt, wenn man die Daten später wieder lesen muss (E-Mail, Datei, Datenübertragung). Für Passwörter ist genau das das Problem: Der Schlüssel muss irgendwo liegen, meist auf demselben System. Wird der Server kompromittiert, hat der Angreifer im schlimmsten Fall Datenbank und Schlüssel – und damit alle Passwörter im Klartext.

Eine kryptografische Hashfunktion ist eine Einwegfunktion. Eigenschaften, die du in der Klausur nennen kannst:

• nicht (praktisch) umkehrbar – aus dem Hash lässt sich das Passwort nicht zurückrechnen
• deterministisch – gleiche Eingabe ergibt immer denselben Hash
• feste Ausgabelänge, egal wie lang die Eingabe ist
• Lawineneffekt – ein geändertes Zeichen ergibt einen völlig anderen Hash
• kollisionsresistent – zwei verschiedene Eingaben mit gleichem Hash zu finden, ist praktisch unmöglich

Wie funktioniert dann der Login? Das System muss das Passwort gar nicht kennen. Es hasht die Eingabe beim Login und vergleicht die Hashes. Stimmen sie überein, war das Passwort richtig. Deshalb schicken seriöse Dienste bei „Passwort vergessen“ auch einen Reset-Link und nicht dein altes Passwort – sie kennen es schlicht nicht.

Und das Salt? Deine Überlegung ist genau richtig: Ohne Salt hat „Sommer2026!“ bei jedem Nutzer denselben Hash. Ein Angreifer kann dann vorberechnete Tabellen (Rainbow Tables) nutzen und sieht außerdem sofort, welche Nutzer dasselbe Passwort haben.

Ein Salt ist ein zufälliger Wert pro Nutzer, der vor dem Hashen an das Passwort gehängt wird. Er steht tatsächlich im Klartext neben dem Hash – das ist kein Fehler, denn er muss nicht geheim sein. Seine Aufgabe ist nur, jeden Hash einzigartig zu machen:

• gleiche Passwörter → unterschiedliche Hashes
• vorberechnete Tabellen sind wertlos, weil sie für jedes Salt neu berechnet werden müssten
• der Angreifer muss jeden Nutzer einzeln angreifen statt alle auf einmal

Manche Systeme nutzen zusätzlich einen Pepper: einen geheimen Wert, der außerhalb der Datenbank liegt. Das ist aber ein Zusatz, nicht der Standardteil der Klausurantwort.