Machbarkeitsstudie: Datenbankfreie Verwaltung von VG-WORT-Zählmarken mit PHP
Diese Machbarkeitsstudie untersucht, ob sich VG-WORT-Zählmarken auf einer PHP-basierten Website automatisiert, datenbankfrei und mit vertretbarem administrativem Aufwand verwalten lassen. Das entwickelte Verfahren verwendet ausschließlich das Dateisystem. Jede Zählmarke wird einem eigenen UUID-Verzeichnis zugeordnet. Die zugehörige PHP-Datei enthält sowohl die dauerhaften Eigenschaften der Zählmarke als auch die von der Anwendung ermittelten Zählerstände. Eine relationale Datenbank ist nicht erforderlich. Im Verlauf der Entwicklung wurden unter anderem die Auswahl verfügbarer Zählmarken, parallele Zugriffe, atomare Schreibvorgänge, Jahreswechsel, historische Zählerstände, die Begrenzung der Historie, die Prüfung unvollständig konfigurierter Datensätze sowie eine webbasierte Statistik- und Dashboarddarstellung umgesetzt. Die technische Machbarkeit des datenbankfreien Verwaltungsverfahrens konnte nachgewiesen werden. Ebenso konnte die automatisierte Einbindung einer Zählmarke in bestehende Artikel erfolgreich realisiert werden. Die Untersuchung ergab jedoch eine für den produktiven Einsatz entscheidende Einschränkung: Der lokal ermittelte Zählerstand entspricht nicht notwendigerweise dem für die Vergütung maßgeblichen Zählerstand des externen Systems. Ein maschinenlesbarer und belastbarer Abgleich dieser beiden Werte stand für die entwickelte Lösung nicht zur Verfügung. Damit ist die automatisierte Verwendung eines lokalen Zählers als verlässliche Entscheidungsgrundlage für den Wechsel einer Zählmarke nicht hinreichend belastbar. Die Machbarkeit des technischen Verfahrens ist somit gegeben; die Eignung als vollständig autonomes Abrechnungssystem ist nicht nachgewiesen.
◁ Startseite
1. Problemstellung
Ausgangspunkt der Untersuchung war die Frage, ob eine größere Anzahl von VG-WORT-Zählmarken automatisiert auf einer Website verwaltet und einzelnen Seitenaufrufen zugeordnet werden kann, ohne hierfür eine Datenbank einzusetzen.
Die Ausgangssituation bestand aus einer Website mit einer Vielzahl einzelner Artikel. Jeder Artikel besitzt eine UUID und ein eigenes Verzeichnis. Die Artikel selbst werden aus mehreren PHP-Dateien zusammengesetzt.
Gesucht wurde eine Lösung, bei der die Verwaltung der Zählmarken nicht in den eigentlichen Artikeln implementiert werden muss. Die Artikel sollten lediglich eine zentrale PHP-Datei einbinden.
Ziel war ein möglichst einfaches, transparentes und langfristig wartbares Verfahren, bei dem die Datenhaltung vollständig über das Dateisystem erfolgt und keine relationale Datenbank erforderlich ist.
Darüber hinaus sollte die Lösung auch bei einer größeren Anzahl vorhandener Zählmarken funktionieren und parallele Seitenaufrufe berücksichtigen.
2. Anfangskonzeption
Die erste Konzeption sah eine Sammlung einzelner UUID-Verzeichnisse vor. Jede UUID sollte einen eigenen Datensatz darstellen. Die Anwendung sollte bei einem Artikelaufruf eine geeignete UUID auswählen und den zugehörigen Zähler erhöhen.
Die wesentlichen Anforderungen waren:
- keine Datenbank;
- eine eigenständige Datenhaltung je UUID;
- automatische Auswahl einer verwendbaren UUID;
- Fortführung der Zähler über den Jahreswechsel;
- Speicherung historischer Jahreswerte;
- Begrenzung der historischen Daten;
- Schutz vor konkurrierenden Schreibzugriffen;
- zentrale Konfiguration;
- Integration in bestehende Artikel ohne Änderungen an der Artikelstruktur;
- Kontrollmöglichkeit über eine webbasierte Oberfläche.
Als Speicherformat wurde PHP-Code mit einem zurückgegebenen Array verwendet. Damit kann eine UUID-Datei unmittelbar mit require eingelesen werden.
Ein Datensatz kann beispielsweise folgende Form besitzen:
<?php
return array (
'zaehlmarke' => '...',
'vgwort_server' => '...',
'zaehler_jahr' => 2026,
'zaehler' => 123,
'zaehler_2025' => 456,
);3. Dateibasierte Datenhaltung
Jede verwaltete UUID wird in einem eigenen Verzeichnis unterhalb des zentralen Claim-Verzeichnisses gespeichert.
/claim/
/UUID-1/
index.php
/UUID-2/
index.php
/UUID-3/
index.php
/template/
index.php
config.php
claim.php
request.php
vgworttrackingcode.php
index.php
style.css
.lock
Die Datei index.php innerhalb eines UUID-Verzeichnisses fungiert dabei als Datensatz. Die Verwendung eines PHP-Arrays als Speicherformat ermöglicht es, die Daten ohne zusätzliche Parser oder Datenbanktreiber einzulesen.
Das Verfahren besitzt damit eine bewusst einfache Datenstruktur. Die Daten sind für einen Administrator unmittelbar lesbar und können bei Bedarf mit einem gewöhnlichen Editor untersucht werden.
Das Template enthält ausschließlich die für einen neuen Datensatz erforderlichen Stammdaten:
<?php
return array (
'zaehlmarke' => '',
'vgwort_server' => '',
);Laufzeitdaten wie Jahreszahl und Zähler werden erst durch die Anwendung erzeugt.
4. Auswahlalgorithmus
Die Auswahl einer Zählmarke wurde im Verlauf der Untersuchung gegenüber der ursprünglichen Vorstellung verändert.
Die anfängliche Logik hätte neue UUIDs mit einem Zählerstand von null bevorzugt behandelt. Bei einer großen Anzahl neu angelegter UUIDs hätte dies dazu geführt, dass zahlreiche Zählmarken nacheinander nur geringfügig verwendet werden.
Daher wurde die Auswahl dahingehend verändert, dass eine bereits verwendete UUID mit dem höchsten aktuellen Zählerstand bevorzugt wird, sofern sie noch innerhalb des konfigurierten lokalen Schwellwertes liegt.
Damit werden vorhandene Zählmarken zunächst möglichst weit verwendet, bevor eine weitere Zählmarke aktiviert wird.
Der Schwellwert wurde während der Entwicklungs- und Testphase bewusst auf einen niedrigen Wert gesetzt. Dadurch konnten Wechsel zwischen UUIDs mit wenigen Seitenaufrufen reproduziert und kontrolliert werden.
5. Atomare Verarbeitung
Ein wesentliches technisches Problem bestand in der Möglichkeit paralleler Seitenaufrufe.
Ohne Synchronisation könnten zwei Prozesse gleichzeitig denselben Datensatz lesen, denselben Zählerstand feststellen und anschließend denselben neuen Zählerstand schreiben. Dadurch würden Zählvorgänge verloren gehen.
Zur Synchronisation wurde eine zentrale Sperrdatei unterhalb des Claim-Verzeichnisses eingesetzt:
/claim/.lockVor der Auswahl und Aktualisierung einer UUID wird eine exklusive Dateisperre gesetzt. Erst nach Abschluss des Schreibvorgangs wird die Sperre aufgehoben.
Damit wird die Auswahl einer UUID einschließlich der anschließenden Zähleränderung als geschützter Vorgang behandelt.
Die Verwendung einer Datenbank war für die erforderliche Synchronisation nicht notwendig. Eine Dateisperre konnte die für diesen Anwendungsfall erforderliche Serialisierung der Schreibvorgänge herstellen.
6. Jahreswechsel und Historie
Die Zählerstände sollten nicht ausschließlich für das laufende Jahr gespeichert werden. Deshalb wurde beim Jahreswechsel der aktuelle Zählerstand unter dem entsprechenden Jahresnamen gespeichert.
Beispielsweise wird aus:
'zaehler_jahr' => 2025,
'zaehler' => 123,im folgenden Jahr:
'zaehler_jahr' => 2026,
'zaehler' => 0,
'zaehler_2025' => 123,Die Historie kann über die Konfiguration zeitlich begrenzt werden. Im untersuchten System wurde hierfür ein Zeitraum von zehn Jahren vorgesehen.
Dadurch wächst ein einzelner Datensatz nicht unbegrenzt an.
7. Trennung von Stammdaten und Laufzeitdaten
Im Verlauf der Entwicklung wurde eine klare Trennung zwischen unveränderlichen Stammdaten und von der Anwendung erzeugten Laufzeitdaten eingeführt.
Zu den Stammdaten gehören:
zaehlmarkevgwort_server
Diese Werte werden einer UUID dauerhaft zugeordnet und dürfen durch den Zählermechanismus nicht verändert werden.
Zu den Laufzeitdaten gehören:
zaehler_jahrzaehlerzaehler_YYYY
Diese Werte dürfen durch die Claim-Logik verändert oder ergänzt werden.
Die Trennung reduziert das Risiko, dass beim Fortschreiben eines Datensatzes versehentlich Informationen über die zugehörige Zählmarke verloren gehen.
8. Integration in die bestehende Website
Die Integration wurde bewusst von der Artikelstruktur entkoppelt.
Die Artikel verfügen bereits über eine gemeinsame Fußzeile. Dort wird eine zentrale PHP-Datei eingebunden:
<section class="claim-pixel">
<?php include $_SERVER['DOCUMENT_ROOT'] . '/claim/request.php'; ?>
</section>Dadurch muss ein einzelner Artikel keine Kenntnis über die Claim-Verwaltung besitzen.
Die eigentliche Ausgabe des Trackingcodes wurde zusätzlich in eine eigene Datei ausgelagert:
/claim/vgworttrackingcode.phpDamit sind Zählerverwaltung, Anforderung und konkrete HTML-Ausgabe voneinander getrennt.
9. Dashboard und statistische Auswertung
Zur Kontrolle des Systems wurde eine webbasierte Verwaltungsoberfläche entwickelt.
Das Dashboard stellt unter anderem folgende Informationen dar:
- Anzahl verfügbarer UUIDs;
- Prüfung der Zählmarken;
- UUIDs ohne Zählmarke;
- aktuelle Zählerstände;
- historische Zählerstände;
- Jahressummen über alle UUIDs;
- Warnzustände bei einer zu geringen Anzahl verfügbarer UUIDs.
Die Statistik wird unmittelbar aus den vorhandenen UUID-Dateien erzeugt. Eine zusätzliche Datenbank oder eine separat gepflegte Statistikdatei ist nicht erforderlich.
Damit dient das Dateisystem gleichzeitig als operative Datenhaltung und als Quelle für die statistische Auswertung.
10. Testverfahren
Die Entwicklung wurde schrittweise anhand konkreter Testdaten überprüft.
Für die ersten Tests wurde der lokale Schwellwert auf zehn gesetzt. Dadurch konnten Zustände wie eine nahezu ausgeschöpfte UUID und der Wechsel auf eine weitere UUID ohne eine große Anzahl realer Seitenaufrufe erzeugt werden.
Zusätzlich wurden neue UUID-Verzeichnisse während des laufenden Jahres angelegt und überprüft.
Ein weiterer Test bestand darin, eine UUID lediglich aus dem Template zu erzeugen. Dadurch konnte überprüft werden, ob das System Datensätze ohne Zählmarke korrekt erkennt und aus der aktiven Verwendung ausschließt.
Die Integration in einen realen Artikel wurde anschließend über die gemeinsame Fußzeile getestet. Bei einem Seitenaufruf wurde eine UUID ausgewählt, der zugehörige Zähler erhöht und die zugehörige Zählmarke für die Trackingausgabe bereitgestellt.
Die Testumgebung verwendete für den externen Server absichtlich einen nicht existierenden Hostnamen. Damit konnte die lokale Verarbeitung getestet werden, ohne unnötige Requests an einen realen externen Dienst zu erzeugen.
11. Ergebnis der technischen Machbarkeitsprüfung
Die technische Machbarkeit der entwickelten lokalen Verwaltung konnte nachgewiesen werden.
Insbesondere wurden folgende Punkte erfolgreich umgesetzt:
- datenbankfreie Speicherung;
- automatisierte Auswahl von UUIDs;
- automatisches Fortschreiben der Zähler;
- Jahreswechsel;
- historische Speicherung;
- zeitliche Begrenzung der Historie;
- atomare Verarbeitung konkurrierender Zugriffe;
- Einbindung in bestehende Artikel;
- separate Verwaltung von Zählmarke und Server;
- automatisierte Erzeugung des Trackingcodes;
- statistische Auswertung;
- webbasiertes Dashboard;
- Prüfung unvollständiger Datensätze.
Die Lösung konnte damit unter den Bedingungen des Versuchs vollständig ohne relationale Datenbank betrieben werden.
12. Festgestellte Systemgrenze
Die entscheidende Einschränkung wurde erst durch die Betrachtung des tatsächlichen Zählverhaltens sichtbar.
Der lokale Zähler zählt die Ausführung der eigenen Claim-Logik. Er stellt damit zunächst fest, wie oft die Website eine Zählmarke zur Verwendung ausgewählt beziehungsweise einen entsprechenden Trackingcode erzeugt hat.
Der externe Dienst ermittelt seinen eigenen Zählstand jedoch nach eigenen technischen und fachlichen Kriterien.
Beide Werte sind daher nicht zwingend identisch.
Ein lokaler Seitenaufruf ist nicht gleichbedeutend mit einer vom externen Dienst anerkannten Zählung.
Dies gilt auch dann, wenn der lokale Trackingcode technisch korrekt erzeugt und in das HTML der Seite eingebunden wird.
Beispielsweise kann ein Browser einen Seitenaufruf durchführen, während der nachfolgende Abruf des Trackingpixels ausbleibt oder vom externen System nicht als gültiger Zählvorgang berücksichtigt wird.
Umgekehrt kann die lokale Anwendung den Aufruf bereits gezählt haben, obwohl der externe Dienst diesen Vorgang nicht oder anders bewertet.
Die Differenz zwischen beiden Zählern ist daher nicht lediglich als kurzfristige technische Verzögerung zu betrachten. Sie kann sich über die Lebensdauer einer Zählmarke kumulieren.
13. Konsequenz für einen automatisierten Zählmarkenwechsel
Die ursprüngliche Überlegung bestand darin, eine Zählmarke nach Erreichen eines lokalen Schwellwertes, beispielsweise 1.600, automatisch durch eine andere Zählmarke zu ersetzen.
Diese Vorgehensweise setzt voraus, dass der lokale Zähler den für den Wechsel maßgeblichen externen Zähler hinreichend genau repräsentiert.
Diese Voraussetzung konnte nicht nachgewiesen werden.
Ein lokaler Stand von beispielsweise 1.600 kann mit einem erheblich niedrigeren externen Stand korrespondieren. Die Abweichung kann deutlich größer sein als ein lediglich technischer Sicherheitsabstand.
Eine pauschale Reduzierung des lokalen Schwellwertes würde das Problem nicht lösen. Sie würde lediglich die Wahrscheinlichkeit einer vorzeitigen Umschaltung verändern.
Ohne eine zuverlässige maschinenlesbare Rückmeldung des externen Systems über den maßgeblichen Zählerstand kann die Anwendung nicht feststellen, wann eine Zählmarke tatsächlich ihre relevante Grenze erreicht hat.
14. Bewertung
Die Machbarkeitsstudie ist hinsichtlich der selbst gesetzten technischen Ziele erfolgreich.
Es konnte ein funktionierendes, datenbankfreies Verwaltungssystem entwickelt werden, das Zählmarken, UUIDs, Zählerstände, Jahreswerte und statistische Informationen verwaltet und in eine bestehende PHP-Website integriert werden kann.
Die Untersuchung hat gleichzeitig gezeigt, dass die lokale Verwaltung nicht automatisch als Ersatz für den Zählmechanismus des externen Dienstes betrachtet werden darf.
Die wesentliche Grenze liegt nicht in PHP, im Dateisystem oder in der fehlenden Datenbank. Sie liegt in der fehlenden Möglichkeit, den lokalen Zählerstand zuverlässig und automatisiert mit dem extern maßgeblichen Zählerstand abzugleichen.
Damit ist die Lösung als autonomer Mechanismus zur zuverlässigen Bestimmung des für die Vergütung relevanten Zählmarkenwechsels nicht geeignet.
15. Schlussfolgerung
Die Untersuchung zeigt exemplarisch, dass eine technisch funktionierende Automatisierung nicht zwangsläufig zu einer fachlich belastbaren Automatisierung führt.
Die gesamte lokale Infrastruktur konnte ohne Datenbank realisiert werden. Die Verarbeitung ist nachvollziehbar, die Datenhaltung ist transparent und die Integration in bestehende Artikel ist mit einem einzigen zentralen Include möglich.
Die entscheidende Voraussetzung für eine autonome produktive Nutzung wäre jedoch ein verlässlicher maschinenlesbarer Abgleich mit dem externen Zählstand.
Da dieser Abgleich mit der untersuchten Architektur nicht hergestellt werden konnte, wird von einer produktiven Steuerung des Zählmarkenwechsels anhand des lokalen Zählers abgesehen.
Das Ergebnis ist somit kein vollständiges „Nein“ zur technischen Idee, sondern eine präzise Eingrenzung ihrer Einsatzfähigkeit:
Die datenbankfreie Verwaltung und technische Ausgabe von Zählmarken ist machbar. Die autonome Steuerung des Zählmarkenwechsels anhand eines ausschließlich lokal ermittelten Zählers ist ohne belastbaren maschinenlesbaren Abgleich mit dem externen Zählsystem nicht hinreichend zuverlässig.
16. Weiterverwendung der entwickelten Infrastruktur
Die Untersuchung hat neben der ursprünglichen Fragestellung eine allgemein verwendbare dateibasierte Infrastruktur hervorgebracht.
Die wesentlichen Komponenten sind nicht auf Zählmarken beschränkt. Insbesondere die UUID-basierte Datenhaltung, die atomare Verarbeitung, die zentrale Auswahl-Logik, die Historienverwaltung und das Dashboard können auch für andere Zwecke eingesetzt werden.
Damit muss die im Rahmen der Machbarkeitsstudie entwickelte Software nicht verworfen werden.
Eine mögliche Weiterverwendung besteht beispielsweise in der Verwaltung und zufälligen oder gewichteten Ausgabe redaktioneller Inhalte wie Zitate, Aphorismen oder kurze historische Texte.
In einem solchen Anwendungsfall entfällt die Abhängigkeit von einem externen Zählsystem. Der lokale Zähler beschreibt dann tatsächlich den von der eigenen Anwendung kontrollierten Vorgang und kann damit als belastbare Grundlage für Auswahl- und Statistikfunktionen dienen.
Die während der Machbarkeitsstudie entstandene Architektur kann auf diese Weise als allgemeines datenbankfreies Content-Rotationssystem weiterverwendet werden.