Tach!
Promise kann ich Dir nicht erklären, das raff' ich nicht in meiner derzeitigen Verfassung. Aber was eine Callback-Funktion ist, schon:
Eine solche bietet sich immer an, wenn sich damit die Datenerfassung von der Datenverarbeitung/Datenausgabe zweckmäßig trennen lässt. Beispiel SQL, Abfrage => Ausgabe:
Dem Abfrageprozess wird eine Referenz auf die Callbackfunktion übergeben. Jedesmal wenn der Abfrageprozess eine neue Zeile liefert, wird mit den Daten der jeweiligen Zeile die Callbackfunktion aufgerufen. Letzere schreibt dann die Zeile bspw. nach stdout oder in eine Datei.
Die Zweckmäßigkeit wird sofort klar, ist eine gepufferte Ausgabe. Des Weiteren muss der Abfrageprozess nicht auf den Ausgabeprozess warten, ja es kann durchaus vorkommen, das der Abfrageprozess längst beendet ist und der Ausgabeprozess noch läuft, die Prozesse werden entkoppelt.
Eine Zweckmäßigkeit kann nur beurteilt werden, wenn man sie anhand der Aufgabenstellung untersucht. Du hast hier lediglich eine Möglichkeit beschrieben, die für sich genommen weder zweck- noch unzweckmäßig ist. Eine klassische Kombination aus Query und Fetch-Schleife mit darin befindlicher Ausgabe kann genauso zweck- oder unzweckmäßig sein - je nach Anforderung.
Außerdem ist das, was du beschreibst, keineswegs eine gepufferte Ausgabe, wenn die Ausgabe sofort für jeden Datensatz ausgeführt wird. Was macht denn, während die Callback-Funktion die Ausgabe erledigt, die Abfrage? Natürlich nichts. Deren Verarbeitung ist angehalten, bis der Callback beendet ist, weil die CPU mit diesem geschäftigt ist. Es sei denn, die Callback-Funktion wird in einem eigenen Thread ausgeführt. Aber auch dann sehe ich nicht, wo da was gepuffert sein soll. Die Ausgabe wäre in dem Fall lediglich parallelisiert, ohne dass da ein Puffer im Spiel ist.
Gepuffert wäre die Angelegenheit, wenn du ein Array mit den abgefragten Datensätzen erzeugst und dieses erst anschließend dem Ausgabeteil übergibst. Das Array wäre dann der Puffer.
dedlfix.