On Thu, 15 Nov 2001, Julien Escario wrote:
> On m'a dit que Marc ne jurait que par postgre/Perl, j'aimerais savoir pkoi.
Pr�cisons:
quand j'ai fait mes �tudes en informatique, j'ai eu un cours sur les
Syst�mes de gestion de base de donn�es (SGBD), assez th�orique et assez
barbant je pr�cise. Mais ce cours m'a donn� une vue d'ensemble sur la
th�orie de la mod�lisation, sur les divers types de SGBD, comme p.ex. le
cas particulier des SBGD/R (relationels), objets, etc, ainsi que des
caract�ristiques d'implantations. On a aussi trait� assez en profondeur
(du moins pour un cours g�n�ral) des probl�mes de garanties d'int�grit�,
de protocoles � trois phases, etc.
Ensuite je n'ai plus jamais fait de bases de donn�es, pendant 4-5 ans.
En 1998, vu que tout le monde parlait alors d'interfa�age de bases de
donn�es avec WWW, j'ai pris une voie �trange:
- j'ai pris Perl (et C) comme langages
(raison: je connaissais bien C, et Perl de nom.
Perl est un langage UNIX par excellence que j'ai
rencontr� d�j� il y a de nombreuses ann�es, sans vraiment
utiliser tout son potentiel l�. Une des raisons qui m'ont
fait choisir Perl, ce sont les tableaux associatifs,
qui me manquaient depuis que j'avais go�t� au langage
exp�rimental Newton).
- j'ai pris pour Perl: DBI comme interface (pas de mysql_connect() ou
autres b�tises, tout se passe de la m�me fa�on pour toutes les bases
de donn�es/syst�mes de gestion de table, gr�ce � une couche
d'abstraction)
- j'ai un peu regard� et � l'�poque, la seule base de donn�es libre
ou open source qui supportait au moins certaines caract�ristiques
ACID �tait PostgreSQL.
En 2001, ce double-choix Perl + PostgreSQL est � mon avis pleinement
justifi�:
- Perl n'est pas forc�ment toujours aussi efficace que d'autres langages
(en temps de d�veloppement et en temps d'ex�cution), mais il a l'avantage
de permettre *certaines* v�rifications (use strict; -w), et de permettre
un style de programmation s�r. De plus c'est un langage universel, non
confin� au WWW. Son apprentissage permet ensuite de d�velopper sur
plusieurs plateformes (y compris non UNIX), en particulier des scripts
pour l'automatisation de t�ches.
- PostgreSQL supporte d�sormais la totalit� des r�gles ACID et poss�de une
performance meilleure que MySQL notamment pour les cas complexes, ceux que
j'impl�mente vu que je designe mes syst�mes en fonction de �a.
Rappelons les r�gles ACID: (j'esp�re ne pas dire trop de b�tises, le cours
est loin)
Atomicity
Consistency
Isolation
Durability
Je ne parlerai pas des transactions ici, car ce concept est recouvert par
ACID.
Ajoutons que PostgreSQL supporte les triggers et les fonctions. Par
exemple:
CREATE TABLE exercice (id SERIAL NOT NULL, -- interne � la base de donn�es
societe INT4 REFERENCES societe NOT NULL,
debut DATE DEFAULT CURRENT_DATE NOT NULL,
fin DATE NOT NULL,
cloture BOOLEAN DEFAULT 'f' NOT NULL,
devise VARCHAR(3) DEFAULT 'CHF' NOT NULL,
libelle TEXT NOT NULL, -- libell�
UNIQUE(libelle, societe),
UNIQUE(id), PRIMARY KEY(id));
CREATE FUNCTION f_exercice_cloture ()
RETURNS opaque
AS 'BEGIN
IF OLD.cloture THEN
RAISE EXCEPTION ''exercice is CLOTURE, you cannot change it.'';
END IF;
RETURN new;
END;'
LANGUAGE 'plpgsql';
CREATE TRIGGER t_exercice_cloture
BEFORE DELETE OR UPDATE
ON exercice
FOR EACH ROW
EXECUTE PROCEDURE f_exercice_cloture ();
Gr�ce � ce trigger/cette fonction (qui sont stock�es dans la base de
donn�es, ie qui tournent sur le serveur) on peut d�tecter � temps des bugs
dans les scripts en Perl/PHP/C/lisp/etc qui tenteraient par erreur de
modifier/supprimer un exercice qui serait cl�tur�.
De plus, gr�ce aux r�f�rences, il est impossible (par d�faut) de supprimer
une societe encore r�f�renc�e par un exercice.
Dans cet exemple il n'y a pas de contraintes d'int�grit� complexes, mais
en voici un exemple:
CREATE TABLE file (id SERIAL NOT NULL,
creation_time TIMESTAMP
NOT NULL DEFAULT CURRENT_TIMESTAMP,
last_access_time TIMESTAMP, -- read some data
file_name VARCHAR(100) NOT NULL, -- see servers_defs.h
client_name VARCHAR(30) NOT NULL, -- from auth
server_name VARCHAR(30) NOT NULL, -- from auth
complete BOOL NOT NULL DEFAULT 'f',
part_count INT4,
UNIQUE(client_name, server_name, file_name),
UNIQUE(id), PRIMARY KEY(id),
CHECK ((complete AND (part_count IS NOT NULL))
OR (NOT complete)));
Il est interdit de cr�er un fichier qui serait consid�r� comme termin�
mais dont le nombre de parties serait inconnu.
Maintenant, il est tr�s possible que MySQL -- notamment la version
propri�taire et payante distribu�e par InnoDB -- supporte toutes ces
fonctionnalit�s.
--
http://www-internal.alphanet.ch/linux-leman/ avant de poser
une question. Ouais, pour se d�sabonner aussi.
