Zwei Modelle der Datenänderung

1. Aufteilung der Änderungen: Entitäten und Bulk

Wenn ein Entwickler gerade anfängt, scheint es, dass das Ändern von Daten immer dasselbe ist: „Objekt gefunden, Feld geändert, gespeichert“. Aber in der realen Backend-Entwicklung tauchen schnell Massenoperationen auf: „bei allen Artikeln einer Kategorie den Status deaktivieren“, „alles Alte löschen“, „Rabatte auf null setzen“, „Bestellungen im Fehlerzustand schließen“. Auf der Ergebnisebene sieht das ähnlich aus, aber auf der Mechanikebene sind es zwei verschiedene Welten.

Stellen Sie sich vor, Sie betreiben unseren mini-shop und erhalten die Aufgabe: „Ab heute sollen Artikel der Kategorie CLEARANCE (Ausverkauf) inaktiv werden“. Sie können jeden Artikel ehrlich als Objekt laden und aktualisieren. Oder Sie können der Datenbank sagen: „setze den gewünschten Wert für alle Zeilen, die die Bedingung erfüllen“. Beide Methoden sind legitim, aber sie sehen im Code anders aus, werden in SQL anders ausgeführt und verhalten sich in der Anwendung anders.

Minigeschichte aus mini-shop: „Artikel müssen deaktiviert werden“

Lassen Sie uns das Gespräch auf das Projekt beziehen, damit es keine Vorlesung im luftleeren Raum ist. Wir haben Product, es hat status (z. B. ACTIVE und INACTIVE), und es gibt eine Beziehung zur Kategorie. Die Geschäftsoperation klingt einfach: „Ein Teil der Artikel soll INACTIVE werden“. Die Frage ist nicht, ob wir das tun können, sondern wie genau wir es tun: über den objektorientierten Weg (Entitäten) oder über den Massenweg (Bulk).

Für den Kontext erinnern wir uns an ein sehr kleines Fragment des Status-Enums (höchstwahrscheinlich haben Sie es bereits, aber lassen Sie es ein „Anker“ sein):

package com.example.shopdatajpa.catalog.entity;

// Status eines Produkts im Katalog mini-shop
public enum ProductStatus {
    ACTIVE,   // Artikel ist aktiv und verfügbar
    INACTIVE  // Artikel ist deaktiviert/versteckt
}

Die Statusänderung ist ein großartiges Lernbeispiel, weil es einfach zu verstehen ist, aber dennoch in kommerziellem Code vorkommt. Schon an dieser Einfachheit sieht man: Die beiden Ansätze ergeben eine unterschiedliche Codeform und eine unterschiedliche Ergebnisform.

2. Entitätsbasiert: Arbeiten mit Objekten

Zuerst analysieren wir den „klassischen“ Weg, der intuitiv verständlich ist: Wir arbeiten mit Entitäten als Objekten. Wir laden sie, ändern Felder, löschen, speichern. Dieser Weg ist dem Umgang mit normalen Java-Objekten sehr ähnlich – und genau deshalb ist er für Anfänger so angenehm. Aber es ist wichtig, seinen Preis zu verstehen: Wenn es viele Objekte gibt, wird auch die Arbeit viel.

Beim entitätsbasierten Ansatz ist der Hauptdarsteller die konkrete Entität. Wir denken nicht in „Bedingungen“, sondern in „diesem Artikel“, „dieser Bestellung“. Das stimmt oft mit dem überein, wie das Geschäft denkt: „aktualisiere diesen Artikel“, „storniere diese Bestellung“, „benenne diese Kategorie um“. Und in solchen Fällen ist der objektorientierte Weg normalerweise der lesbarste.

Ein Objekt: finden, ändern, speichern

Das einfachste und „menschlichste“ Szenario: den Status eines bestimmten Artikels anhand der id ändern. Hier widerspricht niemand – der objektorientierte Weg ist sehr transparent. Wir lesen eine Entität, ändern das Feld und speichern.

import com.example.shopdatajpa.catalog.entity.Product;
import com.example.shopdatajpa.catalog.entity.ProductStatus;

public void deactivateOne(Product product) {
    // Ändere den Zustand des konkreten Objekts im Speicher
    product.setStatus(ProductStatus.INACTIVE);

    // Normalerweise wird danach durch repository gespeichert,
    // damit die Änderung die Datenbank erreicht
}

In einem echten Service würde das ungefähr so aussehen (kurz und knackig):

import com.example.shopdatajpa.catalog.entity.Product;
import com.example.shopdatajpa.catalog.entity.ProductStatus;

public void deactivateOne(Long productId) {
    // Entität aus der Datenbank laden (oder Fehler werfen, wenn nicht gefunden)
    Product product = productRepository.findById(productId).orElseThrow();

    // Feld der Entität ändern
    product.setStatus(ProductStatus.INACTIVE);

    // Änderungen speichern (in JPA führt dies zu einem UPDATE)
    productRepository.save(product);
}

Hier ist ein wichtiger Gedanke: Das Ergebnis der Operation für unseren Code ist das aktualisierte Objekt (genauer gesagt das Objekt mit dem neuen Zustand im Speicher). Wir können sofort zusätzliche Prüfungen durchführen, den konkreten Artikelnamen protokollieren, individuelle Logik anwenden. Das bedeutet, der Code „hält die Entität in den Händen“ und kann damit machen, was er will.

Viele Objekte: Schleife über Entitäten

Jetzt erschweren wir die Aufgabe: alle Artikel einer bestimmten Kategorie deaktivieren. Die erste Reaktion eines Anfängers ist oft: „Okay, ich finde die Liste, iteriere mit einer Schleife und speichere jeden.“ Das ist eine funktionierende Variante, und sie ändert tatsächlich viele Daten. Aber es ist wichtig, die Dinge beim Namen zu nennen: Das ist immer noch der objektorientierte Weg. Es sind nur mehr Objekte geworden.

import com.example.shopdatajpa.catalog.entity.Product;
import com.example.shopdatajpa.catalog.entity.ProductStatus;

import java.util.List;

public void deactivateAllInCategory(Long categoryId) {
    // Zuerst alle Artikel der Kategorie in den Speicher laden (List<Product>)
    List<Product> items = productRepository.findByCategoryId(categoryId);

    // Dann iterieren wie über normale Objekte
    for (Product product : items) {
        // Feld jeder Entität einzeln ändern
        product.setStatus(ProductStatus.INACTIVE);

        // Und jede Entität speichern (oft bedeutet das viele Operationen auf ORM/SQL-Ebene)
        productRepository.save(product);
    }
}

Wenn Sie diesen Code sehen und denken „sieht kurz aus“, ist das normal. Anfänger bewerten die Komplexität oft anhand der Methodenlänge. Aber die tatsächlichen Kosten liegen nicht in den Java-Zeilen, sondern darin, was Sie mit der Datenbank machen: Sie laden zuerst die Liste (und ziehen damit Daten in den Speicher), dann senden Sie potenziell viele UPDATEs (oder zumindest viele Aktionen im ORM, die zu vielen SQLs führen). Auch wenn das keine Katastrophe ist, ist es ein anderes Arbeitsmodell.

Und hier taucht die erste wichtige Weggabelung auf: Wollen wir wirklich jeden Artikel als Objekt durchgehen, weil jeder Artikel individuelle Logik hat? Oder wollen wir einen einzigen massiven Schritt „allen den Status setzen“ ausführen?

Vorteile und Kosten des entitätsbasierten Ansatzes

Jetzt ist es wichtig, den Vergleich nicht zu „Bulk ist immer besser“ zu machen. Nein. Der entitätsbasierte Ansatz ist wertvoll, weil er natürlich die Logik „für jedes Objekt seine eigene Regel“ unterstützt. Zum Beispiel deaktivieren Sie einen Artikel, überspringen einen anderen, deaktivieren einen dritten und schreiben ein Log mit Grund, versetzen einen vierten in einen anderen Status. Sobald Verzweigung und Individualität auftauchen, wird der objektorientierte Weg lesbar und sicher.

Die Kosten zeigen sich in Massenszenarien: Sie müssen zuerst die Entitäten materialisieren, sie im Speicher halten, potenziell viele einzelne Änderungen vornehmen. Das ist nicht „schlecht“, es ist einfach ein anderes Modell. Und wenn Sie es nicht vom Bulk-Ansatz unterscheiden, werden Sie Erwartungen verwechseln: „ich habe eine Schleife geschrieben – also ist das Bulk“. Nein, Bulk bedeutet, dass Sie nicht in Objekten denken, sondern in einer Bedingung und einer einzigen Abfrage.

3. Bulk: Eine Abfrage nach Bedingung

Jetzt kommen wir zum zweiten Modell – und es ruft bei Anfängern normalerweise leichte Skepsis hervor. Denn anstatt des gewohnten „gib mir die Objekte“ sagen wir zur Datenbank: „ändere die Daten nach dieser Bedingung“, und als Antwort erhalten wir nicht eine Liste von Entitäten, sondern eine Zahl der betroffenen Zeilen. Auf psychologischer Ebene fühlt sich das an wie „nicht objektorientiert“, aber aus Sicht der Datenbanken ist das eine sehr natürliche Arbeitsweise.

Der Bulk-Ansatz bedeutet, Sie denken so: „Ich brauche nicht jeden Artikel als Objekt. Ich brauche eine Operation über eine Menge von Zeilen.“ Das heißt, Sie beschreiben ein Kriterium und eine Aktion, die gleichmäßig auf alle passenden Daten angewendet wird. Genau deshalb eignet sich Bulk so gut für Szenarien wie „massenhaft deaktivieren“, „massenhaft löschen“, „massenhaft ein Feld aktualisieren“.

Bulk-Update: allen Zeilen einen Wert setzen

Stellen wir uns vor, wir möchten die Artikel einer Kategorie mit einem einzigen SQL deaktivieren. Auf Datenbankebene sieht das ziemlich banal aus:

-- Massenaktualisierung: ein UPDATE nach Bedingung
update product
set status = 'INACTIVE'
where category_id = 5;

Das wesentliche Detail: Es ist ein UPDATE. Keine Schleife von Updates, nicht „zuerst auswählen, dann aktualisieren“. Einfach eine Abfrage, die sofort die gewünschte Menge von Zeilen ändert.

Auf der Ebene des Java-Codes (vorerst ohne technische Implementierungsdetails) sieht die Logik so aus: Wir rufen eine Methode auf, die die Anzahl der geänderten Zeilen zurückgibt.

public int deactivateProductsInCategory(Long categoryId) {
    // Starte die Bulk-Operation und erhalte genau das, was sie "ehrlich" zurückgibt: Anzahl der Zeilen
    int changed = productRepository.deactivateByCategoryId(categoryId);

    // Normalerweise geht das in Logging/Metriken, nicht in die Geschäftslogik
    System.out.println("Deactivated rows = " + changed); // z.B.: Deactivated rows = 42

    return changed;
}

Beachten Sie, wie sich das Denken ändert. Hier brauchen wir kein List<Product>. Wir müssen kein for machen. Wir „arbeiten nicht mit Artikeln“. Wir „führen eine Massenoperation nach Kriterium aus“. Und das natürliche Ergebnis einer solchen Aktion ist die Anzahl der Zeilen, die tatsächlich geändert wurden.

Wichtig: wie genau eine solche Methode im Repository deklariert wird, wird die nächste natürliche Frage sein. Unser jetziges Ziel ist es, die Bedeutung zu erfassen und sie vom objektorientierten Ansatz zu unterscheiden.

Bulk-Löschung: alles nach Bedingung löschen

Bulk-Delete – genau die gleiche Idee, nur dass wir statt eines Feldes Zeilen löschen. Auf SQL-Ebene ist das wieder eine Abfrage:

-- Massenlöschung: ein DELETE nach Bedingung
delete from product
where status = 'INACTIVE';

Auf Code-Ebene möchten Sie normalerweise wieder die Anzahl der gelöschten Zeilen erhalten. Denn das ist das einzig Ehrliche, das eine Bulk-Operation ohne zusätzliche Lesevorgänge zurückgeben kann.

public int deleteAllInactiveProducts() {
    // Bei Bulk-Delete ist das Ergebnis die Anzahl der gelöschten Zeilen
    int deleted = productRepository.deleteInactiveInBulk();

    // Nützlich, um zumindest die Tatsache der Massenlöschung zu protokollieren
    System.out.println("Deleted rows = " + deleted); // z.B.: Deleted rows = 120

    return deleted;
}

Beachten Sie, wie sehr sich das vom Löschen über productRepository.delete(product) unterscheidet. Dort haben Sie ein Objekt und löschen ein konkretes Objekt. Hier haben Sie eine Bedingung und löschen einen Datensatz.

Rückgabe: Anzahl der Zeilen bei Bulk

Für Anfänger ist das oft ein Punkt der Verärgerung: „Warum kann ich nicht sofort eine Liste der aktualisierten Artikel erhalten?“. Sie können, aber das wird eine andere Operation sein: Sie müssen nach dem Bulk-Update noch einmal einen SELECT ausführen, um die aktuellen Daten zu erhalten. Und das ist eigentlich normal: Bulk und Lesen sind unterschiedliche Aktionen.

Im Bulk-Modell ist das Wichtigste, das Sie sofort erfahren können, „wie viele Zeilen die Datenbank tatsächlich betroffen hat“. Manchmal wird das nur für Logs benötigt. Manchmal für eine Geschäftsentscheidung. Wenn Sie erwarten, genau einen Artikel zu deaktivieren, aber es wurden 0 deaktiviert, ist das ein Grund zum Nachdenken (vielleicht wurde der Artikel nicht gefunden oder war bereits INACTIVE). Wenn Sie erwartet haben, 1000 zu deaktivieren, aber es wurden 12 deaktiviert – auch ein Grund.

Hier ein minimales „Kontroll“-Beispiel:

public void deactivateAllActiveBefore(Long categoryId) {
    // Bulk-Methode gibt den Zähler der betroffenen Zeilen zurück
    int changed = productRepository.bulkDeactivate(categoryId);

    // Wenn nichts geändert wurde – das ist ein separates (und nützliches) Signal
    if (changed == 0) {
        System.out.println("Nothing to deactivate"); // Nothing to deactivate
    }
}

Auch hier: Die Implementierung von bulkDeactivate schreiben wir hier noch nicht. Wir lernen jetzt, das Ergebnis richtig zu erwarten.

4. Vergleich der Ansätze an einem Beispiel

Jetzt fassen wir alles in einem Bild zusammen und festigen das Wichtigste: Beide Ansätze können zum gleichen „Geschäftsergebnis“ führen (z.B. Artikel wurden INACTIVE), aber sie unterscheiden sich grundlegend in der Codeform und darin, was als „natürliches Ergebnis“ der Operation gilt. Wenn Sie das nicht unterscheiden, werden Sie seltsame Dinge tun: von Bulk „aktualisierte Objekte“ erwarten oder versuchen, Bulk über for und save() zu implementieren.

Damit das Gehirn das nicht als „verschwommenes Gefühl“ behält, ist es bequemer, den Vergleich in einer Tabelle zu betrachten. Die Tabelle ist kein Spickzettel für die Prüfung, sondern eine Möglichkeit, schnell zu sehen, wo die Ansätze genau auseinandergehen.

Das Wichtigste hier ist nicht einmal „was schneller ist“, sondern „was die Absicht ehrlicher widerspiegelt“. Code ist Kommunikation. Wenn Sie eine Schleife über Artikel schreiben, teilen Sie dem Leser mit: „Es ist mir wichtig, jedes Objekt durchzugehen“. Wenn Sie eine Bulk-Methode schreiben, teilen Sie mit: „Es ist mir wichtig, schnell eine Änderung auf eine Menge von Zeilen anzuwenden“.

Ausführungsschema: vom Java-Code bis SQL

Um den Gedanken endgültig „festzunageln“, zeichnen wir zwei Minischemata. Das ist nützlich, denn viele Fehler in JPA beginnen genau damit, dass der Entwickler nicht vorstellt, wie viele tatsächliche Schritte zwischen den Java-Codezeilen und der Datenbank stattfinden.

Entitätsbasiert (viele Objekte):

flowchart TD
    A["Java: findBy..."] --> B["Erhaltene List<Product>"]
    B --> C["for durch jeden Product"]
    C --> D["setStatus / delete"]
    D --> E["save / delete"]
    E --> F["SQL: Serie von UPDATE/DELETE"]

Bulk (eine Abfrage):

flowchart TD
    A["Java: bulkUpdate(criteria)"] --> B["SQL: ein UPDATE/DELETE nach Bedingung"]
    B --> C["Ergebnis: changedRows"]

Sieht fast lächerlich einfach aus – und das ist ein gutes Zeichen. Bulk wird gerade wegen seiner Geradlinigkeit geschätzt: eine Abfrage, ein klares Kriterium, ein messbarer Effekt.

Die Entscheidung geht normalerweise nicht um „Schönheit“, sondern um den Sinn der Operation. Wenn Sie jeden Artikel durchgehen und für jeden eine separate Entscheidung treffen müssen, zum Beispiel nur diejenigen deaktivieren, deren Name mit "TEMP-" beginnt, und die anderen lassen, dann wird Bulk unnatürlich. Bulk mag Regeln der Art „alle gleich“. Er mag nicht „jeder anders“, weil Sie dann anfangen, komplexe Logik in eine Abfrage zu packen, und das wird schnell entweder zu SQL-Akrobatik oder zu Code, den niemand pflegen will.

Wenn die Regel jedoch lautet „allen Artikeln der Kategorie X den Status Y setzen“ oder „allen Artikeln älter als Datum D den Status INACTIVE setzen“, wird der objektorientierte Weg überflüssig. Sie wollen nicht tausend Artikel im Speicher halten, nur um ein Feld gleich zu ändern. Hier sind Kriterium und Massenaktion das ehrliche Modell.

Und noch ein subtiler, aber wichtiger Punkt: Beim entitätsbasierten Ansatz können Sie oft direkt nach der Änderung mit dem Objekt weiterarbeiten. Beim Bulk-Ansatz sollten Sie im Idealfall akzeptieren, dass Sie „direkt mit der Datenbank nach Bedingung“ gearbeitet haben, nicht „mit Objekten“. Wenn Sie nach Bulk aktuelle Objekte benötigen, wird das ein separater Leseschritt sein. Von dieser Weggabelung hängen direkt die Art der Deklaration der modifying-query, das erwartete Ergebnis der Operation und die Frage ab, ob man nach der Operation bereits geladenen Entitäten vertrauen kann.

5. Typische Fehler bei der Wahl des Änderungsmodells

Fehler hier sind fast nie über Syntax. Sie sind über falsche Erwartungen. Und die gute Nachricht: Sobald Sie gelernt haben, sich die Frage zu stellen „arbeite ich gerade mit Objekten oder mit einem Kriterium?“, verschwindet die Hälfte der Probleme einfach.

Fehler Nr. 1: zu glauben, dass for + save() ein Bulk-Update ist.
Eine Schleife über eine Liste von Entitäten kann viele Daten ändern, aber es ist immer noch das objektorientierte Modell. Sie haben Objekte geladen, halten sie im Speicher, aktualisieren sie einzeln. Bulk ist „eine Abfrage nach Bedingung“, nicht „viele kleine Speicherungen“. Wenn Sie diese Modelle nicht unterscheiden, werden Sie die Kosten der Operation falsch einschätzen und die Semantik verwechseln.

Fehler Nr. 2: Bulk nur zu wählen, weil der Code kürzer ist.
Kurzer Code ist nicht immer der richtige Code. Wenn die Geschäftsregel erfordert, jedes Objekt separat zu verarbeiten, mehrere Bedingungen zu prüfen, ein Log zu erstellen oder einen Wert individuell zu berechnen, dann wird Bulk entweder sinnlos oder Sie verwandeln die Abfrage in ein Monster. In solchen Fällen ist der objektorientierte Weg die normale Wahl, auch wenn er länger ist.

Fehler Nr. 3: von einer Bulk-Operation „aktualisierte Objekte“ zu erwarten.
Im Bulk-Modell ist das natürliche Ergebnis die Anzahl der Zeilen. Wenn Sie Objekte benötigen, benötigen Sie eine separate Lektüre nach dem Bulk. Sobald Sie dies als Norm akzeptieren, verschwinden eine Menge seltsamer Erwartungen wie „warum sehe ich die neuen Werte nicht in der bereits vorhandenen Liste“. Wir werden das später tiefergehend behandeln, aber schon jetzt ist wichtig: Bulk ist nicht verpflichtet, Ihnen Entitäten zurückzugeben.

Fehler Nr. 4: Ansätze nur nach Geschäftsergebnis zu vergleichen und die Mechanik zu ignorieren.
„Na, und hier und dort wurde der Status INACTIVE“ – klingt wie ein Argument. Aber die Mechanik bestimmt die Konsequenzen: Anzahl SQLs, Anzahl geladener Objekte, Form des zurückgegebenen Ergebnisses, Wartbarkeit des Codes. Die Fähigkeit, die Mechanik zu sehen, ist das Erwachsenwerden als Backend-Entwickler. Man muss nicht sofort ein Hibernate-Jedi werden, aber die zwei Modelle der Datenänderung unterscheiden zu können, ist auf diesem Niveau bereits notwendig.

Fehler Nr. 5: zu vergessen, dass Bulk „veraltete“ Entitäten im Speicher hinterlassen kann.
Wenn Sie vor der Bulk-Operation bereits Product als Entitäten geladen haben (sie sind in den Persistenzkontext gelangt) und dann ein Bulk-UPDATE direkt auf die Tabelle machen, können im Speicher alte Feldwerte bleiben. In der Folge kann der Code „auf das Objekt schauen“ und eines sehen, während die Datenbank bereits etwas anderes speichert. Das wird durch Disziplin gelöst: nicht gedankenlos Bulk und Arbeit mit bereits geladenen Entitäten mischen, sowie Synchronisation/erneutes Lesen dort durchdenken, wo es wichtig ist.