Skip site navigation (1) Skip section navigation (2)

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

From: Dirk Olbertz <olbertz(dot)dirk(at)gmx(dot)de>
To: pgsql-de-allgemein(at)postgresql(dot)org
Subject: Re: Kurze (technische) Übersicht über PostgreSQL gesucht
Date: 2004-09-25 23:25:08
Message-ID: 23EC0BFC-0F4A-11D9-A2C8-000D932A275A@gmx.de (view raw or flat)
Thread:
Lists: pgsql-de-allgemein
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

In response to

  • Re: Ku at 2004-09-25 16:31:18 from Peter Wullinger

Responses

  • Re: Ku at 2004-09-26 06:49:53 from Peter Wullinger

pgsql-de-allgemein by date

Next:From: Peter WullingerDate: 2004-09-26 06:49:53
Subject: Re: Ku
Previous:From: Peter WullingerDate: 2004-09-25 16:31:18
Subject: Re: Ku

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group