Wir haben unsere eigene Datenbank geprüft – das kam heraus

Ein Tool, dessen Verkaufsargument „wir speichern deine Daten dauerhaft“ lautet, hat eine Bringschuld: Die Daten müssen auch richtig sein. Wir haben unsere größte Tabelle deshalb einmal komplett auseinandergenommen – die, in der die Performance-Daten aller Properties liegen. 12,1 Millionen Zeilen, 4,2 Gigabyte.

Das Ergebnis war unangenehmer als erhofft und weniger schlimm als befürchtet. Beides steht hier.

Befund 1: Eine fehlende Regel, auf die sich alles verließ

Beim nächtlichen Abgleich schreibt das Tool neue Daten mit der Anweisung „falls es diesen Datensatz schon gibt, aktualisiere ihn, statt einen zweiten anzulegen“. Diese Anweisung funktioniert allerdings nur, wenn in der Datenbank hinterlegt ist, was „derselbe Datensatz“ überhaupt heißt.

Genau diese Definition fehlte. Der Schutz vor Doppelungen war seit jeher wirkungslos – nicht falsch programmiert, sondern ohne Fundament. Zusätzlich überlappten sich beim historischen Import die Blöcke jeweils um einen Tag. Die Zutaten für doppelte Zeilen waren also vorhanden.

Befund 2: Doppelte Zeilen – und was sie bedeutet hätten

Die Prüfung über den kompletten Bestand ergab: keine relevanten Doppelungen bei den Tagessummen. Die Zahlen, die du im Dashboard siehst, waren korrekt.

Das war Glück, kein Verdienst. Hätte es sie gegeben, wären Klicks und Impressionen zu hoch ausgewiesen worden – und zwar in genau der Richtung, die niemandem auffällt, weil zu gute Zahlen selten hinterfragt werden. Die fehlende Eindeutigkeitsregel ist inzwischen gesetzt; ab jetzt kann eine Doppelung technisch nicht mehr entstehen.

Befund 3: Zwei Indizes, die niemand brauchte

Indizes beschleunigen Abfragen und kosten dafür Speicher und Schreibzeit. Zwei von ihnen waren durch andere vollständig abgedeckt – sie kosteten also, ohne etwas beizutragen. Ersetzt durch zwei passendere: 763 MB frei, und die Abfragen, auf denen Dashboard und Performance-Seite aufbauen, laufen messbar schneller.

Befund 4: Ein Schema, das nicht mehr zur Wirklichkeit passte

Über die Zeit war die dokumentierte Struktur von der tatsächlichen abgewichen – ein Feld kannte einen Wert nicht, den die Anwendung durchgehend benutzt. In der laufenden Installation ging das gut, bei einer Neuinstallation wäre es sofort gebrochen. Solche Abweichungen sind tückisch, weil sie erst auffallen, wenn jemand von vorne anfängt.

Warum wir das veröffentlichen

Weil die Alternative wäre, es nicht zu tun. Ein Anbieter, dessen Produkt das Aufheben von Daten ist, sollte nicht nur erzählen, dass er speichert, sondern auch, dass er nachsieht. Wir haben das im Februar schon einmal so gehandhabt, als ein Sicherheits-Audit Ergebnisse brachte, die man lieber für sich behält.

Was sich für dich ändert: nichts, außer der Ladezeit. Es musste kein Datensatz korrigiert werden. Die Umstellungen liefen im laufenden Betrieb, ohne Sperren.

Was daraus folgt

• Regeln gehören in die Datenbank, nicht nur in den Code. Eine Anwendung, die Doppelungen verhindern will, braucht die Definition von „doppelt“ dort, wo die Daten liegen.
• Strukturänderungen zählen erst, wenn sie dokumentiert sind. Ein Eingriff direkt an der laufenden Datenbank, der nicht in den Migrationsdateien landet, ist eine Zeitbombe für die nächste Installation.
• Nachzählen statt annehmen. Wir sind vom schlimmsten Fall ausgegangen und haben dann gemessen. Das ist die richtige Reihenfolge – nicht umgekehrt.

Alle Änderungen dieser Woche stehen im Changelog August 2026.

Häufige Fragen

Waren meine angezeigten Zahlen falsch?

Nach der Prüfung des gesamten Bestands: nein. Die Voraussetzungen für fehlerhafte Summen waren vorhanden, eingetreten sind sie nicht.

Kann so etwas wieder passieren?

Die konkrete Lücke nicht mehr – die Eindeutigkeitsregel liegt jetzt in der Datenbank und gilt unabhängig davon, welcher Programmteil schreibt.

Muss ich etwas tun?

Nein. Die Umstellung ist abgeschlossen und lief im laufenden Betrieb.