Re: Kurze (technische) Übersicht über PostgreSQL gesucht

Hallo,

Am 25.09.2004 um 12:31 schrieb Peter Wullinger:
> Hört sich für mich nach "Grundlagenvorlesung relationale Datenbanken"
> an, die Dinge, die du ansprichst sind eigentlich nicht
> PostgreSQL-spezifisch, sondern gehören zum SQL Standard. MySQL ist
> allerdings nicht unbedingt dafür bekannt, sich an den Standard zu
> halten.

Das ist jetzt zwar peinlich für mich, aber die Vorlesung
"Informationssysteme" habe ich vor knapp 6 Jahren durchaus besucht. Die
Begriffe der Transaktion, Atomizität, etc. sind mir also zumindest
theoretisch bekannt. Ich danke Dir aber trotzdem nochmal für die
Auffrischung und die Bestätigung, dass Transaktionen bei
Select-Statements keinen Sinn machen. Ich habe mir noch zusätzlich die
entsprechenden Kapitel in der Dokumentation durchgelesen.

> Transaktionen sind auch für Programmierer interessant, den
> die erleichtern die Implementierung von unabhängigen Updates:
> Führt man mehrere Aktualisierungen hintereinander durch, kann
> es sein, daß eine davon fehlschlägt. Ohne Transaktionsunterstützung
> muß man sich dann selbst darum kümmern, die vorhergehenden Operationen
> rückgängig zu machen (unter Berücksichtigung, daß andere Prozesse
> auch auf dieselben Daten zugreifen können). Mit Transkationen reicht
> ein einfaces "ROLLBACK;".

Hierzu noch eine Frage: Ist es möglich, Transaktionen über mehrere
Sessions hinweg zu halten? Mit Sessions meine ich Datenbankverbindungen
eines Programmes.

> Zu Cursors:
>
> Das muß man sich so vorstellen, als würde man eine Abfrage als
> "Datenstrom" erstellen. Innerhalb dieses Datenstroms kann
> man dann einen Zeiger (CURSOR) plazieren.
>
> Ich weiß nicht, auf welche Funktionalität du bei MySQL da anspielst,
> aber wenn ich richtig rate, meinst du den "LIMIT"-Clause für den
> SELECT-Befehl (gibt es auch in PostgreSQL).

Ich hatte da eher auf den Unterschied zwischen mysql_fetch_result und
mysql_store_result angespielt. Dabei bin ich mir jetzt unischer, ob das
nur eine Interface-spezifische Eigenschaft ist, oder grundsätzlich bei
MySQL unterschieden wird. Bei der einen Operation wird nämlich sofort
das gesamte Ergebnis des Select-Statements an den Client übertragen und
dort wird dann durch die Ergebnismenge iteriert und bei der anderen
wird immer nur eine einzelne Zeile aus dem Ergebnis übertragen.

> FETCH NEXT FROM <cursor_name>;
>
> schreiben. Das erspart der Datenbank das Aufstellen des Query-Planes
> (Die Abfrage ist ja schon bekannt) und einen Großteil der anderen
> Operationen. Die Datenbank muß nur noch wissen, wie sie in einem
> bekannten Datensatz"strom" eine Zeile vorwärts kommt.

Ich zitiere mal die Dokumentation: " Rather than executing a whole
query at once, it is possible to set up a cursor that encapsulates the
query, and then read the query result a few rows at a time. One reason
for doing this is to avoid memory overrun when the result contains a
large number of rows. "

Also bekomme ich bei einem normalen Aufruf eines Select-Statements die
Daten komplett, mittels der Cursor kann ich aber auch bei sehr großen
Ergebnismengen flexibel sein. Das gefällt mir, weil es nicht auf der
Ebene der Datenbankabstraktion meiner Applikation gemacht werden muss,
sondern dort, wo die Anfrage anfällt und wo dann eher bekannt ist, wie
groß die Rückgabemengen sein können.

Viele Grüße,
Dirk