Einrichten von PostgreSQL unter Linux - leinhos- · PDF fileEinrichten von PostgreSQL unter Linux (Berufliche Tätigkeitsbeschreibung) Benjamin Schwarz 5. Februar 2011 ... 9 5 Anwendungsbeispiele

Einrichten von PostgreSQL unter Linux

(Berufliche Tätigkeitsbeschreibung)Benjamin Schwarz

5. Februar 2011

Technische Facharbeit

Berufsbildende Schule 1 Gewerbe und Technik MainzKlasse BS FI09a

Ausbildender BetriebNet4U E.Herzberg + L.Jewell GbR

Inhalt1 Einleitung...............................................................................................................32 Grundlagen............................................................................................................33 Installation..............................................................................................................44 Konfiguration..........................................................................................................4

4.1 Konfigurations-Dateien..............................................................................44.1.1 postgresql.conf..................................................................................54.1.2 pg_hba.conf......................................................................................74.1.3 ~/.psqlrc.............................................................................................8

4.2 Kommandozeile........................................................................................95 Anwendungsbeispiele..........................................................................................106 Zeit und Kostenplan.............................................................................................12

6.1 Existierendes Projekt erweitern...............................................................126.2 Einbindung in ein neues Projekt..............................................................12

7 Zusammenfassung...............................................................................................138 Abbildungsquellen................................................................................................159 Textquellen...........................................................................................................1510 Abkürzungsverzeichnis......................................................................................1611 Anhang...............................................................................................................16

Einrichten von PostgreSQL unter Linux / Benjamin Schwarz Seite 2

1 Einleitung

Dieses Dokument soll Linux Administratoren dabei helfen, einen

PostgreSQL-Server einzurichten. Außerdem werden die möglichen Einsatzszena-

rien einer Datenbank definiert. Grundkenntnisse über die Paketverwaltung der je-

weiligen Linux-Distribution sollten vorhanden sein. Vorkenntnisse zum SQL-Syntax

wären auch hilfreich.

Zunächst werden die Grundlagen der Thematik angeschnitten, um ein gewisses

Basiswissen aufzubauen. Danach folgen Anweisungen und Hilfestellung zur Instal-

lation, Konfiguration und Benutzung der PostgreSQL Server- und Client Software.

Zum Schluss werden noch konkrete Anwendungsbeispiele aufgezeigt und zwei

fiktive Zeit- und Kostenpläne dargestellt.

2 Grundlagen

In der elektronischen Datenverarbeitung dreht sich alles um Daten, Dateien und

Verzeichnisse. Meist geht es darum, Daten an einem bestimmten Platz abzulegen,

um sie später möglichst effizient wieder abzurufen. Genau zu diesem Zweck wur-

den Datenbanksysteme entwickelt. In ihnen wird definiert, wie Daten angeordnet

werden, und es wird über verschiedene Schnittstellen ermöglicht, Daten zu schrei-

ben und zu lesen.

PostgreSQL ist ein Open-Source-Datenbanksystem, das, richtig eingesetzt, viele

tausend Datensätze für viele Benutzer gleichzeitig verfügbar macht. PostgreSQL ist

flexibel, zuverlässig, plattformunabhängig, kostenlos und bietet außerdem viele Ei-

genschaften, die sonst nur in kommerziellen Datenbanksystemen verfügbar sind.

Deshalb ist PostgreSQL in den meisten Fällen mehr als ausreichend, um allen An-

forderungen zu genügen. Da solche Systeme grundlegend sehr komplex aufgebaut

sind, wie zum Beispiel der Umfang der SQL-Syntax, kann dieses kurze Dokument

nur einen Einblick in die ganze Vielfalt bieten.


3 Installation

Zuerst müssen die verschiedenen Anwendungen und Bibliotheken installiert wer-

den. Dies lässt sich bei den meisten Linux-Distributionen bequem über den Paket-

manager erledigen. In Ausnahmefällen kann auch eine Installation über ein Binary

erfolgen, das direkt von der Hersteller Webseite [1] - siehe Kapitel 9 - bezogen wer-

den kann. Auf der Webseite sind auch technische Dokumente vorhanden, die bei

der Installation von Nutzen sein können, und im Zweifelsfall können Fragen direkt

online im Forum oder via IRC gestellt werden. Viel interessanter ist aber der Quell-

text, der ebenfalls über die Webseite bezogen werden kann, um die Software auf

dem Zielsystem selber zu kompilieren. Dies hat mehrere Vorteile und ermöglicht es,

auch selbst Änderungen an der Software vorzunehmen. Hilfestellung zur Einrich-

tung einer Umgebung zum Kompilieren und zum Kompilierprozess selber gibt es

auf der Webseite der Cybertec Schönig & Schönig GmbH [2].

4 Konfiguration

Nachdem die Installation der Server-/Client-Software erfolgt ist, müssen vor den

ersten Tests noch verschiedene Einstellungen vorgenommen werden, vor allem da

der Server ohne vorherige Konfiguration unbrauchbar ist.

4.1 Konfigurations-Dateien

Es gibt zwei Hauptkonfigurationsdateien, zum einen die eigentliche Konfigurations-

datei postgresql.conf, zum anderen die pg_hba.conf, in welcher die Zugriffsberech-

tigungen eingerichtet werden. Beide Dateien befinden sich meist im Verzeichnis

/var/lib/postgresql; dies kann aber je nach Linux-Distribution abweichen.

Die Datei .psqlrc kann sowohl auf Systembasis als auch für jeden Benutzer einzeln

vorhanden sein. Alle Befehle, die in dieser Datei aufgelistet sind, werden bei Start

der Client-Anwendung ausgeführt. So lassen sich persönliche Einstellungen ein-

fach speichern.


4.1.1 postgresql.conf

In jeder Zeile dieser Datei kann eine Option stehen. Die Syntax ist übersichtlich

(s. Abb. 1) Zeilen, die mit einem # anfangen, sind Kommentare, alle anderen Zeilen

müssen das Format option = wert haben - genau genommen kann das Gleich-

heitszeichen weggelassen werden - um eine gültige Syntax zu erzeugen.

Abb. 1: postgresql.conf Syntax im Editor nano

Alle folgenden Optionen sollten in jeder postgresql.conf vorhanden sein, damit der

Server funktionsfähig ist:

listen_addresses weist den Server an, nur von bestimmten Adressen Verbin-

dungen anzunehmen. Der Wert * bedeutet, der Server soll Verbindungen von allen

Adressen entgegennehmen. Im Normalfall wird jedoch der Wert localhost gesetzt,

damit der Server nur mit einer oder mehreren lokal laufenden Anwendungen kom-

munizieren kann.

port gibt an, auf welchem Port der Server auf Verbindungen warten soll. Der Stan-

dardwert ist 5432 und sollte zum Verständnis auch beibehalten werden. Diese Opti-

on ist vor allem hilfreich, wenn mehrere PostgreSQL Server auf einem Rechner lau-

fen sollen.

max_connections sagt aus, wie viele Verbindungen der Server maximal gleichzei-

tig zulässt. Der Wert richtet sich in erster Linie nach den Mitteln, welche die Hard-

ware zur Verfügung stellt; vor allem die Übertragungsrate zu externen Rechnern

begrenzt die Anzahl. Mit einer 10 MBit-Anbindung ist es meist auch bei größeren

Datensätzen möglich hunderte Benutzer gleichzeitig zu bedienen, vorausgesetzt,

die restliche Hardware spielt mit. Der Hersteller schlägt als Richtwert 100 vor.


shared_buffers hat erheblichen Einfluss auf die Performance des Servers. Er gibt

an, wieviel Speicher - Buffer - der Server für sich reserviert, um Daten zwischen-

speichern zu können. Wenn der Rechner nur für die Datenbank zuständig ist, sollte

fast der gesamte physikalische Speicher dem Server zugeordnet werden, sprich bei

4 GB Ram ungefähr 3,5 GB für die shared_buffers und der Rest für das Betriebs-

system selbst. Der Wert kann mit einer Maßeinheit für Datenmengen

(KB, MB, GB, ..) enden, um bessere Lesbarkeit zu ermöglichen.

logging_collector weist den Server an, Logdateien zu erstellen. Um überhaupt zu

sehen, ob der Server korrekt anläuft, sollte der Wert hier auf on stehen. Außerdem

sollte noch definiert werden, wo die Logdateien gespeichert werden sollen. Das

geht mit der Option log_directory, deren Wert einen absoluten Pfad zu einem Ver-

zeichnis enthält.

autovacuum sollte im Normalfall den Wert on haben, damit der Server automa-

tisch nicht mehr gebrauchte Ressourcen freigibt und interne Statistiken erstellt wer-

den können, welche maßgeblich zur Verbesserung der Zugriffsgeschwindigkeit bei-

tragen. Je nach Größe der Datenbank sollten die anderen Parameter, die sich auf

autovacuum auswirken, angepasst werden, denn dieser Prozess kann, falsch ein-

gestellt, den Betrieb über längere Zeit einschränken.

timezone muss zwingend angegeben werden, damit der Server mit Tabellen umge-

hen kann, die Datentypen enthalten, welche datumsbezogen sind, wie zum Beispiel

ein einfacher Zeitstempel. Der Wert der Wahl für neue Datenbanken ist hier UTC.

Sollten jedoch Daten aus einem anderen System übernommen werden, müssen

entweder die Daten oder der timezone Wert an die jeweilige Zeitzone angepasst

werden. Tipps dazu gibt es in der offiziellen Dokumentation [3].

Alle wichtigen Einstellungen die zur ersten Inbetriebnahme des Servers notwendig

sind (s. Abb. 2) sollten nun vorhanden sein. Nun muss nur noch der Zugang ermög-

licht werden, damit ein Client sich verbinden kann.


Abb. 2: Minimale postgresql.conf

4.1.2 pg_hba.conf

Diese Datei sagt an, welche Rechner die Erlaubnis haben, sich zu verbinden, wel-

che PostgreSQL-Benutzernamen sie verwenden dürfen und auf welche Datenban-

ken der Zugriff erlaubt ist. Die Syntax ist hier auch wieder einfach zu verstehen:

host/localhost DATABASE USER CIDR-ADDRESS METHOD [OPTIONS]

Eine Zeile enthält jeweils einen solchen Eintrag mit richtigen Werten, die wie folgt

aufgeschlüsselt werden:

DATABASE kann die Werte all für alle Datenbanken, sameuser für alle Datenban-

ken, die diesem Benutzer zugeordnet sind, samerole für alle Benutzer innerhalb ei-

ner Gruppe enthalten. Alternativ kann auch der Name einer Datenbank angegeben

werden.

USER kann wiederum all für alle Benutzer enthalten, ansonsten können hier durch

Komma getrennt Benutzernamen und Gruppen angegeben werden.

CIDR-ADDRESS enthält eine Adresse inklusive CIDR-Maske, von wo aus es er-

laubt ist, eine Verbindung aufzubauen. Um diesen Wert zu bestimmen, muss man

sich ein wenig mit IP-Adressen und Subnetzen auskennen. Eine genaue Beschrei-

bung ist auf der Webseite der Internet Engineering Task Force [4] vorhanden.

METHOD ist die Authentifizierungsmethode. Folgende Werte sind möglich: trust

bedeutet Verbindungen ohne Authentifizierung erlauben, reject besagt, dass von

dieser Adresse keine Verbindungen möglich sind, md5, pam und cert bedeuten je-

weils, dass der Rechner sich über die angegebene Methode authentifizieren muss.


OPTIONS ist optional und wird nur bei manchen Authentifizierungsmethoden ange-

geben, um weitere Einzelheiten zur Methode festzulegen. Im Kapitel

"Client Authentication" der PostgreSQL-Dokumentation sind alle Details darüber

aufgeführt.

Sollte einer der Werte Leerzeichen, Kommas oder andere Sonderzeichen enthal-

ten, muss der Wert in Anführungszeichen stehen. Änderungen der Datei können

während der Laufzeit zum Server übermittelt werden, indem man dem Prozess das

SIGHUP Signal sendet.

Nachdem die Einstellungen es erlauben zumindest vom lokalen Rechner zuzugrei-

fen (s. Abb. 3), kann der Server gestartet werden, Datenbanken können während

der Laufzeit bearbeitet werden.

Abb. 3: pg_hba.conf mit einfachen Regeln

4.1.3 .psqlrc

Wie bereits erwähnt, bietet diese Datei die Möglichkeit, persönliche Einstellungen

für jeden Benutzer anzulegen. Dazu wird einfach im Benutzerverzeichnis eine neue

.psqlrc angelegt, die beim nächsten Aufruf des Clients abgearbeitet wird.

Jede Zeile in der Datei enthält einen sogenannten Meta-Befehl. Eine Übersicht aller

Befehle gibt es in der Dokumentation. Viele Befehle sind jedoch schlecht dokumen-

tiert, weshalb es sich lohnt, andere Quellen im Internet zu suchen, wie zum Beispiel

auf der Mailingliste pgsql-hackers [5] oder der renommierten Webseite

if-not-true-then-false.com [6].


Viele Benutzer ärgert es, dass in der Verlaufsdatei immer wieder die selben Befehle

stehen, da sie mehrfach ausgeführt wurden. Dieses Verhalten kann man mit der

Anweisung \set HISTCONTROL igonoredups (s. Abb. 4) abschalten.

Abb. 4: Einfaches Beispiel einer .psqlrc

4.2 Kommandozeile

Nachdem der Server eingerichtet wurde, kann nun endlich ein Testlauf erfolgen. Zu-

erst wird der Server gestartet und überprüft, ob er erfolgreich angelaufen ist - am

besten die Logdateien im Auge behalten - danach kann versucht werden, eine ein-

fache Verbindung zum Server herzustellen. Dies erfolgt über die Befehlszeile mit

dem Befehl:

psql -h<Hostname des Rechners> -p<Port des Servers> -W -U<Benutzerna-

me> <Name der Datenbank>

Eine erfolgreiche Verbindung eröffnet den Zugang zur psql internen Befehlszeile

(s. Abb. 5), über die der Server nun mit SQL-Syntax oder Meta-Befehlen ange-

steuert werden kann. Zum Beenden der Verbindung wird der Befehl quit eingege-

ben.

Abb. 5: Verbindung zu einem lokal laufenden PostgreSQL-Server


Im Fehlerfall gibt der Client meist sehr genaue Angaben, warum der Verbindungs-

aufbau fehlgeschlagen ist (s. Abb. 6) und weist meist auch auf offensichtliche Ein-

gabefehler hin.

Abb. 6: Fehlgeschlagene Verbindung mit Fehlermeldung

5 Anwendungsbeispiele

Es gibt viele gute Gründe, eine Datenbank einem anderen System vorzuziehen,

einige nicht ganz offensichtliche Fälle werden in diesem Kapitel dargestellt.

Nehmen wir zum Beispiel einmal an, in einem Projekt wird die Anforderung gestellt,

ein Chat-System zwischen mehreren Benutzern zu implementieren. Der Verlauf

aller bisherigen Sitzungen soll gespeichert werden, um die letzten n Zeilen beim

nächsten Anmelden wieder anzuzeigen, damit der Benutzer sieht, wo er das letzte

Mal aufgehört hat. Für ein solches Chat-System könnte man natürlich einen Server

entwickeln, der alle Anforderungen erfüllt, oder aber man greift auf eine Datenbank

zurück, um zumindest einen Teil der Anforderungen - ohne eine Zeile Code zu

schreiben - bereits zu erfüllen. PostgreSQL könnte hier aber den Hauptteil der Ar-

beit erledigen, denn nicht nur das Speichern und wieder Auslesen des Verlaufs

wäre einfach zu realisieren, auch das Übertragen der einzelnen Nachrichten zwi-

schen den Benutzern könnte man über die sogenannten LISTEN- und NOTIFY-Be-

fehle in die Tat umsetzen. Mit LISTEN wird der Client angewiesen, auf Benachrich-

tigungen bzw. NOTIFY-Befehle zu warten, die zu jeder Zeit von einem anderen Be-

nutzer ausgelöst werden können. Somit könnte durch die Kombination beider Be-

fehle eine indirekte Verbindung zwischen zwei oder mehr Benutzern hergestellt

werden, um Nachrichten zu übermitteln.

In einem anderen Projekt ist bereits ein PostgreSQL-Datenbankserver vorhanden.

Dieser soll nun ein möglichst aktuelles Abbild der gesamten Datenbank auf zwei

andere Server spiegeln.


Diese Aufgabe wurde bisher mit einem einfachen Skript, welches alle 30 Minuten

ein Abbild erstellt und zu einem anderen Rechner überträgt, realisiert. PostgreSQL

bietet hierzu die Funktion "Hot Standby" an - erst ab Version 9.0 - die es ermöglicht,

dass mehrere PostgreSQL-Server sich nahezu zeitgleich reproduzieren. Dabei ist

ein Server immer der Master und alle anderen sind Slaves. Der Master erlaubt Voll-

zugriff auf die Datenbank, wohingegen die Slaves im Standby-Modus laufen und

nur lesenden Zugriff erlauben. Wird der Master jetzt aus irgendeinem Grund vom

Netz getrennt, kann jeder Slave sofort zum neuen Master werden. Somit hat man

nicht nur eine Backup-Funktion der Datenbank, sondern kann relativ schnell den

Betrieb auf einem anderen Server wieder aufnehmen, indem man im Optimalfall

kurz einen DNS-Eintrag ändert. Die Ausfallzeiten von 30 Minuten werden hier in je-

dem Fall deutlich reduziert.

Ein weiteres Projekt wird von einem Navigationsgeräte-Hersteller in Auftrag gege-

ben. Es sollen mehrere tausend Benutzer gleichzeitig die Möglichkeit haben, über

ihr Mobiltelefon Staumeldungen abzugeben. Natürlich bietet sich für die Verwaltung

der vielen Datensätze eine Datenbank an. Dennoch sind meist noch mehrere ande-

re Programme zwischen der Anwender-Software und dem Datenbankserver zwi-

schengeschaltet, die manchmal unnötig Ressourcen verschwenden, da man auch

direkt von der Anwender-Software aus mit SQL-Transaktionen zum Server arbeiten

kann. PostgreSQL bietet hierzu die verschiedensten API an, unter anderem für die

Programmiersprachen C, C++, Python, PHP, und Java, wovon einige Erweiterun-

gen auch von externen Entwicklern beigesteuert wurden. Die Mobiltelefon-Softwa-

re könnte beispielsweise mittels einer Java-Anwendung direkt mit dem Datenbank-

server kommunizieren, um eine Staumeldung abzugeben. Die Software des Navi-

gationsgerätes könnte theoretisch genau das selbe Prinzip nutzen, um die Daten

wieder auszulesen, doch wird mit Sicherheit zumindest ein Programm auf der Ser-

verseite überprüfen wollen, ob die Daten überhaupt angezeigt werden sollen.


6 Zeit und Kostenplan

In diesem Kapitel wird anhand von zwei Beispielen gezeigt, welches Zeitfenster nö-

tig ist und welche Kosten einkalkuliert werden müssen, um jeweils ein existierendes

Projekt mit PostgreSQL zu erweitern und um ein neues Projekt von Anfang an mit

Hilfe von PostgreSQL aufzubauen.

6.1 Existierendes Projekt erweitern

Eine Erweiterung mit einem Datenbanksystem ist unter anderem nützlich um dyna-

misch Inhalte bereitzustellen. Darum handelt es sich in diesem Beispiel um einen

Internetshop, der bisher ausschließlich mit HTML betrieben wurde.

Der Zeitplan könnte in etwa so aussehen:

Aktivität Geschätzte Dauer

Installation der PostgreSQL Software auf einem existierendenServer 2 Mannstunden

Entwurf der Datenbank Tabellen inkl. Einpflegen dervorhandenen Daten

8 Mannstunden

Umstellung von HTML auf PHP inkl. Implementierung einerSchnittstelle zur Datenbank (ca. 100 statische Seiten)

3 Manntage*

Summe 3 Manntage, 10 Mannstunden

* Ein Manntag entspricht 8 Stunden

Der dazugehörige Kostenplan ist relativ übersichtlich:

Beschreibung Geschätzte Kosten

Anwerben eines PHP Profis zur Umsetzung derUmstellung von HTML auf PHP (ca. 3 Manntage)

1680 Euro bei 70 Europro Personenstunde

Einarbeiten der eigenen Entwickler in PostgreSQL undUmsetzung der restlichen Implementierung (ca. 10Mannstunden ohne Einarbeitungszeit)


Summe 1820 Euro bei 84 Europro Personenstunde


6.2 Einbindung in ein neues Projekt

Natürlich bietet es sich bei vielen Projekten an, auf eine Datenbank zurückzugrei-

fen. Ein gutes Beispiel wäre eine Suchmaschine für Hotels. Durch das hohe Daten-

aufkommen vieler kleiner Datensätze zu statistischen Zwecken - dadurch machen

Suchmaschinen einen großen Teil ihres Umsatzes [7] - eignet sich eine Datenbank

wunderbar zur Datenverwaltung.

Aktivität Geschätzte Dauer

Bedarfsermittlung und Anschaffung der Hardware 16 Mannstunden

Ausarbeitung und Umsetzung der Internetpräsenz inkl.Entwicklung der Datenbank und deren Layout 28 Manntage

Installation der Server unter Linux inkl. Probebetrieb 2 Manntage

Summe 30 Manntage,16 Mannstunden

Natürlich gibt es viele mögliche Hardware Kombinationen und die Umsetzung kann

durchaus länger dauern. Dennoch lohnt es sich meist, in eigene Hardware zu in-

vestieren, nicht zuletzt, um volle Kontrolle über das Projekt zu haben.

Beschreibung Geschätzte Kosten

Hardware

Datenbankserver mit hochwertiger Hardware 3000 Euro

Front-End Server 1000 Euro

Miete, Stromkosten und Gebühren für den erzeugtenTraffic im Rechenzentrum.

350 Euro, fixe Kostenjeden Monat

Summe 4350 Euro (im ersten Monat)

Personal

Bedarfsermittlung der Hardware (ca. 16 Mannstunden) 224 Euro bei 14 Europro Personenstunde

Ausarbeitung und Umsetzung der Internetpräsenz (ca. 28Manntage)


Installation der Server durch externe Mitarbeiter (ca. 2Manntage)


Recherche eines passenden Rechenzentrums undInstallation der Server vor Ort (ca. 12 Mannstunden)


Summe 3972 Euro bei 72 Europro Personenstunde


7 Zusammenfassung

PostgreSQL ist für die Umsetzung vieler Anforderungen interessant. Wir haben ge-

lernt, das Datenbanksysteme nicht nur zum Verwalten von Daten sinnvoll sind, son-

dern das sie auch ganz andere Aufgaben erledigen können. Die Einarbeitungszeit

ist im Vergleich zum Nutzen verschwindend gering, und da eine Datenbank in den

verschiedensten Projekten ihren Platz hat, ist es durchaus ratsam sich frühzeitig

dafür zu entscheiden, ein solches System einzusetzen, um später wieder auf die

gesammelte Erfahrung zurückzugreifen. Die Installation und Konfiguration sollte un-

ter Zuhilfenahme dieses Dokumentes vereinfacht werden, ist aber keineswegs eine

ausführliche Beschreibung aller möglichen Optionen, die zur Verfügung stehen.

Deshalb sollte eine weitere Schulung in Betracht gezogen werden, bevor die Instal-

lation durchgeführt wird.

Aus persönlicher Sicht kann ich nur sagen, dass Datenbanken mehr denn je zum

Standard in der elektronischen Datenverarbeitung werden, und es sich somit in al-

len Fällen lohnt, sich damit auseinanderzusetzen. Auch in Zukunft wird

PostgreSQL immer weiter an Bedeutung gewinnen und eignet sich somit hervorra-

gend als Ersatz für kostspielige Datenbanksysteme.


8 AbbildungsquellenTitelbild:

http://wiki.postgresql.org/wiki/Logo19.08.2011, 04:11

Abbildung 1: postgresql.conf Syntax im Editor nanoAbbildung 2: Minimale postgresql.confAbbildung 3: pg_hba.conf mit einfachen RegelnAbbildung 4: Einfaches Beispiel einer .psqlrcAbbildung 5: Verbindug zu einem lokal laufenden PostgreSQL ServerAbbildung 6: Fehlgeschlagene Verbindug mit Fehlermeldung

Jeweils selbst erstellt mit Adobe Photoshop CS3 Version 10.0

9 Textquellen [1] PostgreSQL: Linux packages

http://www.postgresql.org/download/linux#multibinary14.04.2011, 10:44

[2] Cybertec PostgreSQL: Source Code kompilierenhttp://www.cybertec.at/pgbook/node34.html14.04.2011, 11:22

[3] : PostgreSQL: Documentation: Manuals: PostgreSQL 8.0: Date/Time Typeshttp://www.postgresql.org/docs/8.0/static/datatype-datetime.html18.05.2011, 22:19

[4] : Internet Engineering Task Force: RFC 4632, CIDR Address Strategyhttp://tools.ietf.org/html/rfc463219.05.2011, 15:01

[5] : PostgreSQL mailing list archivehttp://postgresql.1045698.n5.nabble.com/19.05.2011, 17:53

[6] : If Not True Then False, Linuxhttp://www.if-not-true-then-false.com/category/linux/19.05.2011, 17:58

[7] : Suchmaschinen - Statistiken und Studienhttp://de.statista.com/themen/111/suchmaschinen/19.05.2011, 18:34


10 Abkürzungsverzeichnis

API - Application Programming Interface, eine Schnittstelle zur Anwendungspro-grammierung.

Binary - Eine ausführbare Datei, wie z.B. eine übliche Windows .exe Datei.

CIDR-Maske - Classless Inter Domain Routing, ein Schema, um Netzwerke zuadressieren.

DNS - Domain Name System, ein Dienst zur Beantwortung von Anfragen zur Na-mensauflösung.

Front-End - Begriff in der Schichteneinteilung, dabei ist typischerweise das Front-End näher am Benutzer, das Back-End näher am System.

IRC - Internet Relay Chat bezeichnet ein rein textbasiertes Chat-System.

Mailingliste - Eine vereinfachte Version eines Diskussions Forums, basierend aufE-Mails.

Paketmanager - Ein Programm, welches die komfortable Verwaltung von Softwareermöglicht.

SQL-Syntax - Datenbanksprache zur Definition, Abfrage und Manipulation von Da-ten in relationalen Datenbanken.

11 Anhang

Hilfreiche Links:

Ausführliches FAQ zu PostgreSQL:http://sql-info.de/postgresql/FAQ_german.html

PostgreSQL Usergroup Germany:http://www.pgug.de/

PostgreSQL: Das offizielle Handbuch als Download:http://www.postgresql.org/docs/books/pghandbuch.html.de


Documents

Einrichten von PostgreSQL unter Linux - leinhos- · PDF fileEinrichten von PostgreSQL unter Linux (Berufliche Tätigkeitsbeschreibung) Benjamin Schwarz 5. Februar 2011 ... 9 5 Anwendungsbeispiele