Quellen-Inventur vor dem Parsen
Eine neue Datenquelle zuerst vollständig auflisten – welche Felder gibt es, wie oft sind sie belegt – und erst danach gezielt auslesen.
Eine neue Datenquelle zuerst vollständig auflisten – welche Felder gibt es, wie oft sind sie belegt – und erst danach gezielt auslesen.
Wer eine neue Datenquelle anzapft, hat meist schon eine Vorstellung davon, was er braucht: Name, Adresse, Webseite. Also wird die Quelle genau danach durchsucht – und genau das wird gefunden. Was sie sonst noch enthält, erfährt niemand.
Die Umkehrung kostet einen einzigen Befehl: erst erheben, welche Felder es überhaupt gibt, mit Häufigkeit, als Tabelle. Dann entscheiden, was davon gebraucht wird.
Im Kanuvereine-Datensatz wurden die Detailseiten des Verbandes von Anfang an geladen und lagen die ganze Zeit lokal vor. Ausgelesen wurden die erwarteten Felder. Sieben Wochen später ergab eine Inventur, dass dieselben Seiten führen:
Das Gewässer für 523 Vereine. Die Flussseite mit Kilometerangabe für 350. Die Vereinsaktivität für 1.079, die Disziplinen für 676 – und eine Auszeichnung, die genau die Frage beantwortet, ob dort gezeltet werden darf.
Das Gewässer ist das Kernfeld des Projekts. Um es abzuleiten, wurden sieben Gigabyte Kartendaten geladen und eine eigene Zuordnungslogik gebaut. Eine unabhängige Gegenprobe für die Hälfte aller Fälle lag die ganze Zeit ungenutzt auf der Platte.
Der Fehler fällt nicht auf. Es stürzt nichts ab, keine Prüfung schlägt an, das Ergebnis sieht vollständig aus – es ist nur kleiner, als es sein müsste. Aufwand wird an einer Stelle investiert, an der die Quelle die Antwort längst mitliefert.
Es ist derselbe Denkfehler, den auch die anderen Methoden dieser Sammlung adressieren, nur eine Stufe früher: die eigene Erwartung bestätigen, statt die Wirklichkeit anzusehen. Prüfskripte fangen ab, was falsch ist. Die Inventur fängt ab, was fehlt.