Vorrausschauendes Fahren bezeichnet jenen Verhaltensgrundsatz im Straßenverkehr, bei dem man potentielle Gefahren frühzeitig erkennt und somit reagieren kann bevor Gefahr besteht. Dazu gibt es sogar einen Wikipedia-Artikel . Vorrausschauendes Laden lehnt sich an das Fahren an, hierzu gibt es keinen Wikipedia-Artikel - natürlich nicht. Gemeint ist hierbei eine Technik zur Leistungsoptimierung (von Webseite).

Optimiert wird dabei die Anzahl der Datenbankabfragen und die Idee ist, dass eine große Abfrage schneller / besser / effizienter ist als viele kleine. Im Beispiel eine Weblogs könnte eine kleine Abfrage lauten: "Gib mit den neuesten Artikel". Sollen nun die fünf neuesten Artikel dargestellt werden sind vier weitere kleine Abfragen notwendig: "Gib mit den zweit-neuesten Artikel", ...  Eine größere Abfrage würde diese Aufgabe auf einmal erledigen: "Gib mir die fünf neuesten Artikel" und ist - obwohl netto die selbe Datenmenge transportiert wird - performanter und somit den kleinen Abfragen vorzuziehen. Das ist einfach.

Komplizierter wird es, wenn die Artikel-Tabelle Fremdschlüssel - wie z.B. die Benutzer-Id des Autors - enthält. Die naheliegende Lösung wäre, die große Abfrage mit einem Join auf die Benutzertabelle zu erweitern. Eine einfache und performante Lösung. Nachteil der Lösung der genau abgestimmten Datenbankabfragen ist allerdings, dass die Datenbank-Schicht etwas alles über die Ausprägung der Präsentations-Schicht wissen muss! Es ergeben sich also andere (optimierte) Datenbankabfragen, je nachdem ob der Vorname, die E-Mail-Adresse, das Avatar-Bild oder gar keine Informationen über den Autors mit dem Artikel angezeigt werden. Da diese Herangehensweise zwar zu optimale Datenbankabfragen, gleichzeitig aber auch zu super schwer wartbarem Code führt, möchte ich eine objektorientierte Lösung dieses Dilemas vorstellen: vorrausschauendes Laden,

Beim vorrausschauenden Laden gibt es keine Joins. Stattdessen merkt sich das System alle Fremdschlüssel, die von der Datenbank geladen werden. Im Beispiele enthält die Arkikeltabelle die Benutzer-Ids als Fremdschlüssel. Werden nun an anderer Stelle die Daten des Benutzers mit Id X geladen, kann das System gleich alle Benutzerdatensätze laden, die es sich vorher gemerkt hat. Das System sieht also voraus, dass alle (germerkten) Benutzerdaten gebraucht werden. Mit dieser Methode wird ein optimierter Join durch zwei einfache Abfragen ersetzt. Das ist zwar aus Sicht der Datenbank nicht optimal, kommt dem aber sehr nahe.

Der Hauptvorteil dieser Methode ist, dass dadurch ein modulare Aufbau mit großer Performance möglich wird. So entscheidet im obigen Beispiel erst die Präsentations-Schicht (die HTML-Templates) ob zu diesem Artikel der Vorname des Autors angezeigt wird und lädt diesen bei Bedarf (von der Datenbank) nach.

Dieses System hat sich in der Praxis bereits in vielen Fällen bewährt. Jetzt habe ich das vorrausschauenden Laden selbst als Komponente implementiert, so dass dieser Mechanismus noch in vielen anderen Stellen eingesetzt werden kann.