PostgreSQL

Z Wikipédie

Tento článok nie je úplný. Pomôžte Wikipédii vylepšiť ho. Jeho obsah má byť prekladom en:PostgreSQL

PostgreSQL je voľne šíriteľný objektovo-relačný databázový systém (systém riadenia báz dát), uvoľnený pod flexibilnou licenciou BSD. Ponúka alternatívu k ostatným voľne šíriteľným databázovým systémom (ako sú MySQL, Firebird, MaxDB a iné), ako aj k prioprietárnym (akými sú napr. Oracle, DB2 od IBM či Microsoft SQL Server). Podľa mnohých databázových odborníkov je v súčasnosti PostgreSQL najvyspelejší a najsofistikovanejší voľne šíriteľný systém riadenia báz dát.

Samotní vývojári čítajú slovo PostgreSQL ako "postgreskjúel" (ukážka, 5.6k MP3).

Obsah

1 História
2 Popis
3 Features
4 Shortcomings
5 See also
6 External links
7 Newsgroups and mailing lists discussions

[úprava] História

PostgreSQL prešiel dlhým vývojom, začínajúc ako projekt Ingres na univerzite Berkeley. Vedúci projektu, Michael Stonebraker, odišiel z Berkeley v roku 1982, aby sa pokúsil presadiť Ingres na komerčnom trhu, ale nakoniec sa vrátil na akademickú pôdu. Po návrate do Berkeley v roku 1985 Stonebraker začal projekt post-Ingres, v ktorom chcel riešiť problémy vtedajších databázových systémov, ktoré sa stále vo väčšej miere ukazovali už od začiatku osemdesiatych rokov dvadsiateho storočia. Základy zdrojových kódov projektov Postgres a Ingres sú (a od začiatku boli) úplne oddelené.

Výsledný projekt, pomenovaný ako Postgres, mal ako cieľ uviesť za čo najmenšej námahy úplnú podporu pre typy tak, aby bolo možné nielen definovať nové typy, ale aj aby bolo možné plne popísať vzťahy – dovtedy často využívanú schopnosť, ale o ktorú sa musel starať používateľ. V systéme Postgres samotná databáza "chápala" vzťahy a mohla získavať informácie z tabuliek v relácii prirodzeným spôsobom použitím "pravidiel".

Od svojho počiatku v roku 1986 tím napísal mnoho článkov, ktoré popisujú základy systému a v roku 1988 sa podarilo vytvoriť prototyp systému, ktorý bežal a uspokojivo fungoval. Tím uvoľnil verziu 1 malému počtu používateľov v júni 1989, za ktorou nasledovala verzia 2 s nanovo napísaným systémom pravidiel v júni 1990. Verzia 3 z roku 1991 mala opäť prepísaný systém pravidiel, ale súčasne pridala podporu pre viacero správcov ukladania a mala aj zdokonalený procesor dotazov. Už v roku 1993 mal databázový systém Postgres obrovský počet používateľov, ktorých požiadavky začali zaplavovať projekt a ľudí na ňom pracujúcich. Po uvoľnení verzie 4 -- ktorá bola mienená hlavne ako upratanie -- projekt skončil.

Aj keď oficiálne projekt Postgres skončil, licencia BSD, pod ktorou bol uvoľnený, umožňovala vývojárom získať kópie zdrojových kódov a vývíjať ho ďalej. V roku 1994 dvaja doktorandskí študenti Univerzity Berkeley, Andrew Yu a Jolly Chen, pridali procesor jazyka SQL, ktorým nahradili pôvodný QUEL, čím vytvorili Postgres95. Celý zdrojový kód bol opäť zverejnený na internete. Rok 1996 sa niesol v znamení zmeny mena: z projektu Postgres95 sa stal PostgreSQL, čím bol naznačený dôraz v zmene použitého dotazovacieho jazyka.

Prvé uvoľnenie systému PostgreSQL bolo označené verziou 6.0. Odvtedy skupina databázových vývojárov a dobrovoľníkov z celého sveta, komunikujúcich prostredníctvom siete internet, sa stará o tento softvér. Od verzie 6.0 sa objavilo niekoľko ďalších verzií s množstvom rôznych vylepšení; súčasná verzia (august 2004) má označenie 7.4, pričom verzia 8.0 je vo fáze beta testovania.

Napriek tomu, že licencia dovoľuje komercionalizáciu systému Postgres, nikdy sa zdrojový kód nevyvíjal komerčne tak rapídne ako napr. Ingres, čo je prekvapujúci fakt v porovnaní s výhodami, ktoré Postgres ponúka. Najväčší posun nastal, keď Paula Hawthorn (pôvodná členka tímu Ingres, ktorá prešla k Postgres) a Michael Stonebraker založili Illustra Information Technologies na komercionalizáciu systému Postgres.

[úprava] Popis

Povrchný pohľad na PostgreSQL môže naznačovať veľkú podobnosť s ostatnými relačnými databázovými systémami. PostgreSQL používa dotazovací jazyk SQL pre výber a modifikáciu údajov. Dáta sú reprezentované ako množina tabuliek, ktoré spájajú cudzie kľúče. Jedna z charakteristík oproti jeho (hlavne voľne šíriteľným) konkurentom je programovateľnosť: PostgreSQL umožňuje oveľa jednoduchšiu tvorbu aplikácií z reálneho sveta využívajúcich údaje z databázy.

Relačné databázy ukladajú údaje jednoduchých dátových typov v "plochých tabuľkách", čo vyžaduje, aby používateľ vytvoril takú formu údajov, akú potrebuje, prostredníctvom dotazovacieho jazyka. Toto je v protiklade s tým, ako sa väčšinou údaje používajú hlavne v jazykoch vyššej úrovne s bohatými dátovými typmi (záznamami a objektami).

Konverzia údajov zo sveta relačných databáz do objektovo-orientovaného programovania prináša ťažkosti, pretože tieto svety majú veľmi rozdielnu organizáciu dát. Tento problém sa niekedy nazýva ako impedančná nezhoda. Zobrazovanie z jedného modelu do druhého môže neraz zabrať až 40% celého času určeného na vývoj projektu. Na riešenie bolo vyvinutých veľa postupov, ktoré sa typicky označujú ako objektovo-relačné mapovanie, ale väčšina z nich je náročná a má vlastné problémy, čo spôsobuje slabý výkon alebo nutnosť prístupu k údajom z jediného jazyka, ktoré mapovanie podporuje.

PostgreSQL sa vie vysporiadať s mnohými problémami na úrovni databázy. PostgreSQL dovoľuje používateľovi definovať nové typy založené na normálnych SQL typoch, čo dovoľuje databáze používať komplexné dáta. Napríklad, môžete definovať typ adresa, ktorý pozostáva z niekoľkých reťazcov, napr. pre číslo ulice, mesto a krajinu. Z tohto pohľadu je možné vytvoriť tabuľku obsahujúcu všetky polia potrebné pre adresu v jednom riadku.

PostgreSQL taktiež dovoľuje využívať dedičnosť typov, jeden z dôležitých konceptov objektovo-orientovaného programovania. Napríklad, je možné definovať typ PSČ a vzápätí vytvoriť americké_PSČ a slovenské_PSČ, obe založené na pôvodnom type. Adresy v databáze tak môžu byť bude v americkom alebo slovenskom formáte a špecializované pravidlá sa postarajú o validáciu správnej formy. V skorých verziách PostgreSQL vyžadovala implementácia nových typov písanie kódu v C a jeho následnú kompiláciu a pričlenenie k databázovému serveru, vo verzii 7.4 sa celá procedúra značne zjednodušila a je teraz možné vytvárať nové typy priamo v SQL pomocou CREATE DOMAIN príkazu.

Programovanie databázy samotnej je jednoduché prostredníctvom použitia konceptu funkcíí. Väčšina SQL systémov dovoľuje používateľom napísať tzv. uložené procedúry (en:stored procedures), bloky kódu SQL väčšinou predkompilovaných na serveri, ktoré potom môžu volať ostatné SQL príkazy. Avšak väčšina používateľov zvyknutých na imperatívne programovacie jazyky (ako sú napr. C/C++, Pascal či Basic) má problémy myslieť a vyjadrovať sa vo vyššom jazyku SQL, zvlášť, keď je potrebné vytvoriť komplexnejšiu logiku.

The programming of the database itself can profit greatly from the use of functions. Most SQL systems allow users to write a stored procedure, a block of SQL code that other SQL statements can call. However SQL itself remains unsuitable as a programming language, and SQL users can experience great difficulty in constructing complex logic. Worse, SQL itself does not support many of the most basic operations in a programming language, like branching and looping. Instead each vendor has written their own extensions to the SQL language to add these features, and such extensions do not necessarily operate across database platforms.

In PostgreSQL programmers can write such logic in any one of a considerable set of supported languages.

A built-in language called PL/PgSQL resembles Oracle's stored procedure language PL/SQL, and is particularly convenient when dealing with query-intensive procedures.
Wrappers for popular scripting languages such as Perl, Python, Tcl, and Ruby allow harnessing their strengths in string processing and in linking to extensive libraries of outside functions.
Procedures requiring the high performance provided by compiling complex logic into machine code can utilise C or C++.
On the more esoteric side, a handler for the R statistical language allows database queries to take advantage of its rich set of statistical functions.

The programmer can insert the code into the server as a function, a small wrapper that makes the code resemble a stored procedure. In this way SQL code can call (for instance) C code and vice-versa.

Performance improves because the database engine invokes all the logic at one time in one place, reducing the number of round trips between client and server.
Reliability improves due to the centralisation of data verification code in one place, on the server, without relying on synchronising logic in multiple client applications, perhaps even in multiple programming languages.
By adding useful abstractions to the server, client code can become much shorter and simpler.

These advantages add up to making PostgreSQL arguably the most advanced database system from a programming perspective, which helps to explain the success of Illustra. Using PostgreSQL can dramatically reduce overall programming time on many projects, with its advantages growing with project complexity.

[úprava] Features

Some features of PostgreSQL rarely found in other relational databases include:

User-defined types
User-defined operators
Availability of multiple stored procedure languages, including C, SQL, Perl, Python, Tcl, Ruby, Parrot, shell script, or the native PL/PgSQL
Support for geographic objects via PostGIS
Concurrency managed via a Multi-Version Concurrency Control (MVCC) design, which ensures excellent performance even under heavy concurrent access circumstances
Table inheritance
Rules -- a way of implementing server-side logic that allows the application developer to modify the "query tree" of an incoming query
Expressional indexes -- indexes created on the output of expressions, rather than on a single column
Partial indexes -- indexes based on a portion of a table. These can save disk space and improve performance if only part of the table actually requires an index

In addition, PostgreSQL supports almost all the constructs expected from an enterprise-level database, including:

Referential integrity constraints including foreign key constraints, column constraints, and row checks
Triggers
Views
Outer joins
Sub-selects
Transactions
Strong compliance with the SQL standard (SQL92, SQL1999)
Encrypted connections via SSL
Binary and textual large-object storage
Online backup
Domains

[úprava] Shortcomings

One can loosely separate the shortcomings PostgreSQL into:

a lack of some advanced features
architectural features which have unfortunate side effects

PostgreSQL has lacked a good replication solution; third-party packages exist which address this, however. Systems use replication in situations where a single database server cannot keep up with query workloads and/or where a requirement exists to minimise database downtime.

Perceived deficiencies of lesser importance include point-in-time recovery and nested transactions. (PostgreSQL 8.0 will contain support for point-in-time recovery and nested transactions).

PostgreSQL currently lacks the ability to automatically infer the rules needed to make views support updates; presently, application developers need to define these rules themselves.

In the second group of concerns one should note the need for periodic VACUUMing. Due to MVCC, when a transaction updates or deletes a row, the old version of the row remains in the database, since another transaction may still have that data in use, or the transaction which modified it may rollback. This provides the substantial benefit that the database does not usually need to lock whole rows, even though one transaction may need a consistent view of the database state while others concurrently update data. The process of VACUUMing marks (as stale) that data which the DBMS definitely no longer requires. Old versions of PostgreSQL required an exclusive lock on a table to perform the VACUUM, but recent versions can perform VACUUMing concurrently with normal database access. This substantially reduces the impact of VACUUMing on other database activity. Nevertheless, good practice still demands the scheduling of VACUUMing during periods of low database load. Failure to VACUUM regularly may result in wasteful use of disk space (since one cannot re-use stale row versions until a VACUUM has taken place) and performance degradation (because queries must skip stale row versions during execution). In addition, one must VACUUM the entire database at least once every billion transactions, or else no new transactions can run.

Standard aggregate functions, such as COUNT, also perform unusually poorly compared to some other database systems in cases where the query aggregates the entire table. Specifically, some other databases will make use of indexes or system metadata to process a query such as SELECT COUNT(*) FROM table; efficiently. Since index entries do not contain MVCC information, PostgreSQL cannot improve performance by merely reading the index; it must also examine the tuples themselves to verify which ones are visible to the currently-running transaction.

Also, considerable demand exists for a native port to the Microsoft Windows environment. PostgreSQL can run under Windows using the Cygwin Unix emulation library, but offers less than optimal performance and suffers from a complicated installation procedure. The 8.0 release, currently in beta, includes a native Win32 port.