Deutsche Übersetzung von Ian Barwick (barwick@gmx.net).
!Letzte Aktualisierung der deutschen Übersetzung: Di., den 02.09.2003, 10:00 CET
Die aktuellste Version dieses Dokuments liegt auf der PostgreSQL Website:
Deutsche Übersetzung von Ian Barwick (barwick@gmx.net).
!Letzte Aktualisierung der deutschen Übersetzung: Fr., den 02.01.2004, 07:30 CET
Die aktuellste Version dieses Dokuments liegt auf der PostgreSQL Website:
Weitere Informationen zum Status von PostgreSQL auf der Microsoft-Plattform ! befinden sich unter http://techdocs.postgresql.org/guides/Windows (en.).
Eine Portierung für Novell Netware 6 gibt es unter http://forge.novell.com.
--- 220,226 ---- in der Vorbereitung.Weitere Informationen zum Status von PostgreSQL auf der Microsoft-Plattform ! befinden sich unter http://techdocs.postgresql.org/guides/Windows (en.) sowie http://momjian.postgresql.org/main/writings/pgsql/win32.html (en.).
Eine Portierung für Novell Netware 6 gibt es unter http://forge.novell.com.
*************** *** 273,281 ****http://www.PostgreSQL.org!
Es gibt außerdem einen IRC-Channel bei EFNet und bei OpenProjects, Channel ! #PostgreSQL. Der FAQ-Autor Bruce Momjian nutzt den Unix-Befehl: ! irc -c '#PostgreSQL' "$USER" irc.phoenix.net um daran teilzunehmen.
Eine Liste von Unternehmen, die Support für PostgreSQL auf kommerzieller Basis leisten, kann unter --- 273,282 ----
http://www.PostgreSQL.org!
Es gibt außerdem einen IRC-Channel bei EFNet und bei Freenode, Channel ! #PostgreSQL. Unter UNIX/Linux können Sie mit z.B. ! irc -c '#PostgreSQL' "$USER" irc.phoenix.net bzw. irc -c ! '#PostgreSQL' "$USER" irc.freenode.net. daran teilnehmen.
Eine Liste von Unternehmen, die Support für PostgreSQL auf kommerzieller Basis leisten, kann unter *************** *** 284,290 ****
Die neueste Version von PostgreSQL ist 7.3.4 .
Die Freigabe einer neuen Version erfolgt im Schnitt ca. dreimal pro Jahr.
--- 285,291 ----Die neueste Version von PostgreSQL ist 7.4.1 .
Die Freigabe einer neuen Version erfolgt im Schnitt ca. dreimal pro Jahr.
*************** *** 374,386 ****PostgreSQL weist eine Performanz auf, die mit der von kommerziellen und anderen Open-Source-Datenbanken vergleichbar ist. In ! manchen Bereichen ist es schneller, in anderen langsamen. Im ! Vergleich zu MySQL oder abgespeckten Datenbank-Systemen sind ! INSERT- und UPDATE-Anweisungen aufgrund des Transaktionsaufwands ! langsamer. MySQL hat allerdings keine der oben erwähnten ! Eigenschaften. PostgreSQL setzt auf Zuverlässigkeit und ! Funktionsumfang, obwohl selbstredend ständig an Performanz- ! Verbesserungen gearbeitet wird. Ein interessanter Vergleich zwischen PostgreSQL und MySQL befindet sich unter dieser URL: http://openacs.org/philosophy/why-not-mysql.html
PostgreSQL weist eine Performanz auf, die mit der von kommerziellen und anderen Open-Source-Datenbanken vergleichbar ist. In ! manchen Bereichen ist es schneller, in anderen langsamer.
!Im Vergleich zu MySQL oder abgespeckten Datenbank-Systemen ! ist PostgreSQL in Lastsituationen - z.B. bei zeitgleichen ! Zugriffen durch mehrere Nutzer, komplexen Abfragen oder gleichzeitigen ! Lese- und Schreibzugriffen schneller. MySQL ist nur bei einfacheren ! SELECT-Abfragen mit wenigen Nutzern schneller. MySQL hat allerdings ! wenige der oben erwähnten Eigenschaften. PostgreSQL setzt auf ! Zuverlässigkeit und Funktionsumfang, dabei wird selbstredend ständig ! an Performanz-Verbesserungen gearbeitet. Ein interessanter Vergleich zwischen PostgreSQL und MySQL befindet sich unter dieser URL: http://openacs.org/philosophy/why-not-mysql.html
Es gibt mehrere grafische Schnittstellen für PostgreSQL, darunter PgAccess ( http://www.pgaccess.org), ! PgAdmin II (http://www.pgadmin.org, ! nur für Win32), RHDB Admin (http://sources.redhat.com/rhdb/ ) und Rekall ( http://www.thekompany.com/products/rekall/, proprietär). Es gibt --- 482,489 ----
Es gibt mehrere grafische Schnittstellen für PostgreSQL, darunter PgAccess ( http://www.pgaccess.org), ! PgAdmin III (http://www.pgadmin.org, RHDB Admin (http://sources.redhat.com/rhdb/ ) und Rekall ( http://www.thekompany.com/products/rekall/, proprietär). Es gibt *************** *** 785,791 ****
Maximale Größe eine Datenbank? unbeschränkt (es existieren
Datenbanken mit 4TB)
! Maximale Größe einer Tabelle? 16 TB
Maximale Größe einer Zeile? 1,6 TB
Maximale Größe einer Spalte? 1 GB
Maximale Anzahl von Zeilen in einer Tabelle?
--- 787,793 ----
Maximale Größe eine Datenbank? unbeschränkt (es existieren
Datenbanken mit 4TB)
! Maximale Größe einer Tabelle? 32 TB
Maximale Größe einer Zeile? 1,6 TB
Maximale Größe einer Spalte? 1 GB
Maximale Anzahl von Zeilen in einer Tabelle?
***************
*** 799,805 ****
verfügbaren Platten- und Speicherressourcen eingeschränkt sind.
Extreme Größen können zu Leistungseinbußen führen.
! Die maximale Tabellengröße von 16 TB benötigt keine Large-File-Unterstützung
im Betriebssystem. Große Tabellen werden in Dateien mit einer Größe von
1 GB aufgeteilt, wodurch etwaige dateisystem-bedingte Beschränkungen nicht
relevant sind.
--- 801,807 ----
verfügbaren Platten- und Speicherressourcen eingeschränkt sind.
Extreme Größen können zu Leistungseinbußen führen.
! Die maximale Tabellengröße von 32 TB benötigt keine Large-File-Unterstützung
im Betriebssystem. Große Tabellen werden in Dateien mit einer Größe von
1 GB aufgeteilt, wodurch etwaige dateisystem-bedingte Beschränkungen nicht
relevant sind.
***************
*** 1012,1018 ****
Werts?
PostgreSQL bietet einen SERIAL-Datentyp. Dieser erzeugt automatisch
! eine Sequenz und einen Index auf die angegebene Spalte. Zum Beispiel:
CREATE TABLE person (
id SERIAL,
--- 1014,1020 ----
Werts?
PostgreSQL bietet einen SERIAL-Datentyp. Dieser erzeugt automatisch
! eine Sequenz auf die angegebene Spalte. Zum Beispiel:
CREATE TABLE person (
id SERIAL,
***************
*** 1025,1031 ****
id INT4 NOT NULL DEFAULT nextval('person_id_seq'),
name TEXT
);
- CREATE UNIQUE INDEX person_id_key ON person ( id );
umgewandelt.
Die create_sequence Man-Page liefert weitere Informationen über Sequenzen.
--- 1027,1032 ----
***************
*** 1180,1187 ****
4.22) Warum sind meine Unterabfragen (subqueries), die IN verwenden,
so langsam?
! Derzeit werden Unterabfragen mit der äusseren Abfrage verbunden, indem
! für jede Reihe der äusseren Query die Ergebnisse der Unterabfrage
sequentiell geprüft werden. Um dies zu vermeiden, kann man IN durch
EXISTS ersetzen, z.B.:
--- 1181,1188 ----
4.22) Warum sind meine Unterabfragen (subqueries), die IN verwenden,
so langsam?
! In Versionen vor 7.4 werden Unterabfragen mit der äusseren Abfrage verbunden,
! in dem für jede Reihe der äusseren Query die Ergebnisse der Unterabfrage
sequentiell geprüft werden. Um dies zu vermeiden, kann man IN durch
EXISTS ersetzen, z.B.:
***************
*** 1196,1203 ****
WHERE EXISTS (SELECT spalte2 FROM tabelle_2 WHERE spalte1 = spalte2)
Damit diese Abfrage effizient durchgeführt wird, sollte für 'spalte2'
! ein Index angelegt worden sein. Die Einschränkung von Abfragen mit IN
! wird in der nächsten PostgreSQL-Version (7.4) behoben werden.
4.23) Wie führe ich einen OUTER JOIN durch?
--- 1197,1206 ----
WHERE EXISTS (SELECT spalte2 FROM tabelle_2 WHERE spalte1 = spalte2)
Damit diese Abfrage effizient durchgeführt wird, sollte für 'spalte2'
! ein Index angelegt worden sein. Ab PostgreSQL 7.4 IN verwendet
! die gleichen Methoden wie die normale Tabellenverknüpfung und ist daher soger
! EXISTS vorzuziehen.
!
4.23) Wie führe ich einen OUTER JOIN durch?
***************
*** 1355,1362 ****
entgegen, verweise jedoch auf die Mailing-Listen als schnelle und zuverlässige
Anlaufstellen.
- Diese Übersetzung basiert teilweise auf einer früheren Übersetzung von Karsten
- Schulz (schulz@linux-systemhaus.de).