Re: Ku

From: Peter Wullinger <some-mail-drop(at)gmx(dot)net>
To: Dirk Olbertz <olbertz(dot)dirk(at)gmx(dot)de>
Cc: pgsql-de-allgemein(at)postgresql(dot)org
Subject: Re: Ku
Date: 2004-09-26 06:49:53
Message-ID: 20040926064953.GA2230@peter.home.wul
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-de-allgemein

In epistula a Dirk Olbertz, die horaque Sat, Sep 25, 2004 at 07:25:08PM -0400:
> 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.
>

Ne, das ist nicht peinlich, das ist normal ;-).

Sollte mich heute jemand nach Quine-McKluskey (Minimierungsverfahren für
boolsche Ausdrücke) fragen, hätte ich jetzt erst mal größere Probleme.

[snip]

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

Das nicht, nein. Das liegt allerdings wohl hauptsächlich daran, daß die
Datenbank keine Möglichkeit außer der Verbindung zum Server hat, einen
Client zu identifizieren. So etwas wie eine benutzer-sichtbare
Transaktionsnummer gibt es also nicht.

[snip]

>
> 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.

Liest sich für mich, als wäre das eine Art "CURSOR-Ersatz" ohne
entsprechende SQL-Unterstützung. Ich kenn' mich jetzt da nicht aus,
aber ich denke, diese Funktionen sind nur über die MySQL-eigenen
Bibliotheken nutzbar und nicht über Datenbank-unabhängige
Schnittstellen wie ODBC.

Aber da meine Kenntnisse von MySQL sich auf "wie starte ich den
Datenbank-Server" begrenzen, ist das keine zuverlässige Aussage.

[snip]

> 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.

Richtig. Für häufig benutzte Queries hat PostgreSQL inzwischen
auch noch einen weiteren Leckerbissen:

http://www.postgresql.org/docs/7.4/static/sql-prepare.html
http://www.postgresql.org/docs/7.4/static/sql-execute.html

Pre-Compiled Queries ...

Gruß,
Peter
--
Jetzt sind die guten alten Zeiten, nach denen wir uns
in zehn Jahren zurücksehnen.
-- Sir Peter Ustinov

In response to

Responses

Browse pgsql-de-allgemein by date

  From Date Subject
Next Message Martin Fleck 2004-09-26 19:10:09 Strukturproblem mit Hierarchie
Previous Message Dirk Olbertz 2004-09-25 23:25:08 Re: Kurze (technische) Übersicht über PostgreSQL gesucht