Vous n'êtes pas identifié(e).
Rebonjour,
Tout le monde ici fait des papiers élogieux sur PostGreSQL et c'est bien normal. Il est normal que la communauté PostGreSQL fasse ressortir les bienfaits de PG. Pour autant PostgreSQL est loin d'être parfait.
Il est donc aussi normal de le comparer et j'ai personnellement choisit de dire de manière systématique ce qui me paraissait moins bon dans PostGreSQL en comparaison à d'autres SGBDR afin que chacun puisse faire un choix non biaisé en lisant les très nombreux articles de la communauté (Guillaume Lelarge, Bruce Momjan, Michael Stonebarker... et bien d'autres !) tous en faveur de PostgreSQL, et les rares miens en sa défaveur, afin d'avoir une vision claire des choses. Notez que je spécifie toujours dans mes études les articles sur lesquels je me base et les livres de référence qui m'ont servit à puiser les informations que je donne... Bref je n'invente rien ! Et mes tests le prouve...
J'aurais pu être beaucoup plus méchant en postant par exemple quelques extraits croustillants des forums et listes d'abonnement postgresql (par exemple pgsql-general@postgresql.org) dans lesquels les DBA sont confrontés à quelques un des problèmes que je cite, comme par exemple les blocage et deadlocks engendrés par la combinaison MVCC / VACUUM...
Je ne suis pas payé par un quelconque éditeur de SGBDR et mon seul revenu est le fruit du travail au sein de ma propre entreprise. Et même si j'ai l'étiquette de MVP Microsoft, c'est une distinction honorifique qui vient du fait que je publie régulièrement des articles et des études sur Microsoft SQL Server, et ce titre m'est donné par mes pairs pour un an seulement et renouvelé maintenant par vote depuis plus de 10 ans du fait de mes publications sur le sujet...
A quand d'ailleurs une communauté de "pairs" PostGreSQL pour honorer ses membres les plus compétents ? (Il y a des chances que je n'en fasse jamais partit tant la polémique est vive à chaque fois que je poste... ;-)
Il m'arrive aussi de conseiller PostGreSQL en remplacement de MySQL, SQL Server ou Oracle, dans des missions en clientèle et pour certains cas et bien sûr l'inverse (passer de PostGreSQL à SQL Server, par exemple comme ce fut le cas pour la gestion des crues du grand delta du Rhône pour la DDE du Gard dans le cadre du renouvellement de ce système de Paratronic http://www.postgresql.fr/temoignages:paratronic)
Je connais aussi assez bien Oracle (pas aussi profondément que SQL Server, c'est un fait), mais au contraire de SQL Server et PostgreSQL, je ne le pratique plus en entreprise depuis plus de 10 ans... (ce qui ne m'empêche pas d'avoir des confrères très pointus sur Oracle pour leur demander leurs avis afin d'éviter de dire des bêtises - Exemple, Stéphane Faroult...).
Enfin en ce qui concerne la richesse SQL de PostGreSQL, j'ai eu l'occasion maintes fois d'en dire du bien, car le SIG, comme certains fonctions avancées (les fonctions fenêtrées par exemple) ont été bien faites et souvent en avance sur certains concurrents (SQL Server en particulier... Lire mon papier à ce sujet.
Mais c'est curieux, le forum PostGreSQL semble agir plutôt à charge à mon encontre qu'à décharge ! (peut être le mérite-je... Mais dans ce cas ça ressemble à un procès d'intention ;-)
Reste qu'aujourd'hui Oracle, IBM DB2, SQL Server et PostGreSQL sont à peu près à même niveau sur le plan du langage SQL, mais pas du tout sur l'administration ou les outils périphériques... Et c'est cela qui peut faire la différence, car le cout d'exploitation ne sera pas du tout le même...
Un seul exemple : PostGreSQL ne dispose pas d'outil de CDC... Cela doit se traduit, pour l'implémentation d'un datawarehouse, par la suppression avec reconstruction totale du DW toutes les nuits. C'est donc totalement inexploitable pour de grosses bases (plusieurs To) ou l'on ne peut mettre plusieurs jours à reconstruire le DW et ou l'ion doit agir par différence, ce qui est le but de Change Data Capture...
A +
PS (pour MitsuTomoe) : Je regrette beaucoup DRB qui était l'un des SGBDR les plus avancés et les plus calé sur la norme SQL avec notamment les assertions, toujours pas implémentées sous PostGreSQL, ni d'ailleurs sous aucun autre SGBDR à ma connaissance (sauf Ocelot de mon ami Peter Gulutzan aujourd'hui chez MySQL) ! En revanche le Fulltext PG n'est pas conforme à la norme SQL et pose quelques petits soucis... Il faudra que je fasse un papier comparatif un de ces jours ! Celui de SQL Server l'est avec une richesse fonctionnelle largement supérieure (recherche sémantique en sus par exemple).
Bonjour,
voici une nouvelle étude sur le stockage des données des bases avec PostGreSQL.
http://blog.developpez.com/sqlpro/p1182 … postgresql
Merci de vos commentaires.
le mieux serait d'utiliser PGagent.
A +
... Au passage, merci pour ce thread, je comprends mieux pourquoi l'article de comparaison sql server spatial versus PostGIS est rempli d'inepties.
Au passage ceci constitue à l'évidence une diffamation.
Si vous dite que ce que j'ai écrit dans cet article :
SQL et système d’information géographique (SIG)
est faux, prouvez-le, sinon, je vous prie de corriger votre message pour enlever ces termes diffamatoire !
C'est toujours sympathique de voir des gens dénigrer les autres, sans pour autant faire quoi que ce soit comme travail sur le sujet...
Salutations
Spatial references, coordinate systems, projections, datums, ellipsoids – confusing?
"
Spatial reference
The spatial reference is a combination of all the above. It defines an ellipsoid, a datum using that ellipsoid, and either a geocentric, geographic or projection coordinate system.
"
SRID, SRS ID: Spatial Reference System Identifiers
qui qualifie d'ailleurs cette définition d'excellente (je cite) mais commet la même erreur que beaucoup...
Vous noterez le mot EITHER qui en anglais veut dire L'UN OU L'AUTRE, c'est à dire que la définition d'un SRID peut encapsuler une projection OU un système de coordonnées géocentrique ou géographique...
Il n'y a donc pas de projection systématiquement encaspulée dans un SRID, mais les données d'un SRID permettent de définir les projections...
Pour avoir discuté avec Morten Nielsen de vive voix lors des MVP Summit aux USA, la confusion entre le SRID est le système de projection est vieille et hélas très répandue, notamment dans la documentions de PostGIS et même sur Wikipedia, dont on sait, hélas, que de nombreuses notices sont sujettes à caution...
Bref, je sais à peu près de quoi je parle et j'enseigne aussi cette matière notamment à travers des cours pro sur ce sujet, comme celui-ci que j'ai monté à Orsys : Gestion de données spatiales sous PostGreSQL et SQL Server 2008
Alors sans doute, vous direz que Morten Nielsen est vendu à Microsoft.... et que ce n'est donc pas une source fiable !!!
Popular websites with the topic: epsg
"
SRID
A Spatial Reference System Identifier is a unique value used to unambiguously identify projected, unprojected, and local spatial coordinate system definitions.
"
Vous noterez le terme unprojected !
Voir aussi le problème dans le livre "la mise en œuvre d'un SIG dans les collectivité territoriales", aux pages 58 à 60 ou le problème est posé au sujet du RGF93 et de la projection Lambert.
Si vous avez envie, d'une référence encore plus pointue, ouvrez l'ouvrage "Encyclopedia of GIS" édité par Springer Verlag (1370 pages, ed 2008) à la page 364 et suivante qui décrit le GML dont les réferentiels spatiaux sont originaires !...
Comme vous avez fournit une référence de choix, celles collectant les référentiel terrestre, jetez un coup d'oeil au SRID 4326 :
Spatial Reference Projection: 4326
GEOGCS["WGS 84",
DATUM["WGS_1984",
SPHEROID["WGS 84",6378137,298.257223563,
AUTHORITY["EPSG","7030"]],
AUTHORITY["EPSG","6326"]],
PRIMEM["Greenwich",0,
AUTHORITY["EPSG","8901"]],
UNIT["degree",0.01745329251994328,
AUTHORITY["EPSG","9122"]],
AUTHORITY["EPSG","4326"]]Vous n'y verrez nulle projection, mais bien l’ellipsoïde de référence !
C'est même la plus utilisée en général, par exemple pour les routes maritimes ou aérienne.
Vous avez aussi fournit une autre référence : LES PROJECTIONS ET RÉFÉRENTIELS CARTOGRAPHIQUES
À la page 5 figure un dessin montrant bien comment une référence spatiale associée à une ellipsoïde de référence (ce qu'est un SRID) permet, par le choix d'une projection, d'effectuer une représentation des données de manière cartographique. Les pages suivantes montrant bien la décomposition....
Malheureusement la confusion SRID/projection est extrêmement commune et visiblement l'essentiel de ceux qui postent dans ce forum la font... C'est dommage !
A +
Pour paralléliser l'indexation, le moyen le plus simple est de lancer plusieurs processus en même temps. En effet, PostGreSQL est incapable de multithreader une même requête quelle qu'elle soit y compris un CREATE INDEX ou un REBUILD, contrairement à Oracle ou SQL Server qui permettent non seulement de faire de l'indexation multithreadée, mais aussi ONLINE, c'est à dire sans bloquer les mises ou jours ou les sauvegardes... (création de l'index en parallèle de l'existant, même si mise à jour il y a).
C'est pourquoi je déconseille souvent PostGreSQL pour les bases de données de type VLDB et en particulier les gros DW !
Néanmoins, dans la 4e édition de mon livre sur SQL , j'ai donné une requête permettant d'évaluer la fragmentation des index d'une base PG...
WITH
T1 AS
(
SELECT current_setting('block_size')::numeric AS bs,
CASE WHEN substring(v,12,3) IN ('8.0', '8.1', '8.2')
THEN 27
ELSE 23
END AS hdr,
CASE WHEN v LIKE '%mingw32%'
THEN 8
ELSE 4 *
END AS ma
FROM (SELECT version() AS v) AS T
),
T2 AS
(
SELECT schemaname, tablename, hdr, ma, bs,
SUM((1-null_frac)*avg_width) AS datawidth,
MAX(null_frac) AS maxfracsum,hdr
+ (SELECT 1+count(*)/8
FROM pg_stats s2
WHERE null_frac<>0
AND s2.schemaname = s.schemaname
AND s2.tablename = s.tablename) AS nullhdr
FROM pg_stats s, (SELECT * FROM T1) AS constants
GROUP BY schemaname, tablename, hdr, ma, bs
),
T3 AS
(
SELECT ma,bs,schemaname,tablename,
(datawidth+(hdr+ma-(CASE WHEN hdr%ma=0
THEN ma
ELSE hdr%ma
END)))::numeric AS datahdr,
(maxfracsum*(nullhdr+ma-(CASE WHEN nullhdr%ma=0
THEN ma
ELSE nullhdr%ma
END))) AS nullhdr2
FROM T2
),
T4 AS
(
SELECT schemaname, tablename, cc.reltuples, cc.relpages, bs,
CEIL((cc.reltuples*((datahdr+ma-
(CASE WHEN datahdr%ma=0
THEN ma
ELSE datahdr%ma
END))+nullhdr2+4))/(bs-20::float)) AS otta,
COALESCE(c2.relname,'?') AS iname,
COALESCE(c2.reltuples,0) AS ituples,
COALESCE(c2.relpages,0) AS ipages,
COALESCE(CEIL((c2.reltuples*(datahdr-12))/(bs-20::float)),0) AS iotta
FROM T3
INNER JOIN pg_class cc
ON cc.relname = T3.tablename
INNER JOIN pg_namespace nn
ON cc.relnamespace = nn.oid
AND nn.nspname = T3.schemaname
LEFT OUTER JOIN pg_index i
ON indrelid = cc.oid
LEFT OUTER JOIN pg_class c2
ON c2.oid = i.indexrelid
)
SELECT schemaname, tablename, reltuples::bigint, relpages::bigint, otta,
ROUND(CASE WHEN otta=0
THEN 0.0
ELSE T4.relpages/otta::numeric
END,1) AS tbloat,
relpages::bigint - otta AS wastedpages,
bs*(T4.relpages-otta)::bigint AS wastedbytes,
pg_size_pretty((bs*(relpages-otta))::bigint) AS wastedsize,
iname, ituples::bigint, ipages::bigint, iotta,
ROUND(CASE WHEN iotta=0 OR ipages=0
THEN 0.0
ELSE ipages/iotta::numeric
END,1) AS ibloat,
CASE WHEN ipages < iotta
THEN 0
ELSE ipages::bigint - iotta
END AS wastedipages,
CASE WHEN ipages < iotta
THEN 0
ELSE bs*(ipages-iotta)
END AS wastedibytes,
CASE WHEN ipages < iotta
THEN pg_size_pretty(0)
ELSE pg_size_pretty((bs*(ipages-iotta))::bigint)
END AS wastedisize
FROM T4
WHERE T4.relpages - otta > 0 OR ipages - iotta > 10
ORDER BY wastedbytes DESC, wastedibytes DESC;Elle est inspirée de celle utilisée par le superviseur Nagios à travers le projet Bucardo (check_postgres).
A +
Non, vous vous trompez. Le SRID est un système de référence (coordonnées utilisées pour la courbure du sphéroïde , point de référence et unité de mesure). Une famille de projection peut être déduite d'après les données géométriques + le SRID... Dire que le SRID est la projection, c'est une ellipse (au sens figuré évidemment) un peu raccourcie (cette fois au sens propre)... La meilleure preuve est qu'à partir de telles données plusieurs types de projections sont possible dans la même famille de projection. Exemple projection conique de Delisles, Albers, Lambert...
A +
Il n'y a pas de projection dans une table, ni même dans une colonne. Le SRID n'est même pas une projection. C'est un référentiel de sphéroïde valable localement ou terrestriel. Il sert à effectuer des calculs précis compte tenu de la courbure retenue, par exemple pour la navigation orthodromique. Il est propre à chaque données de type géographique.
Commencez donc par nous préciser :
1) quelle version de PostGreSQL
2) quelle version de PostGIS
3) la description DDL de la table
4) un exemple de données
A +
Vous avez mis en place le filestream sur un serveur MS SQL ?
Oui, à de nombreuses reprises..
Pour de la GED par exemple, mais aussi pour des sites web de vente avec des photos des objets.
A +
par curiosité quel est l’intérêt de stocker une video dans une base de données ? plutôt qu'un lien qui pointe vers la ressource ?
La synchronisation entre les LOBs et les données relationnelles :
- la gestion des transactions (que faire si ROLLBACK des données relationnelles et enregistrement du LOB ou l'inverse ?)
- la sauvegarde synchrone (que faire si vous sauvegardez d'une côté votre base et de l'autre vos LOBs et qu'entre temps des mises à jour ont lieu ?)
Notez que la norme SQL à prévu un mécanisme intelligent appelé DATALINK, (SQL:1999) toujours pas implémenté dans PG...
Voici ce que j'en dit dans mon livre sur SQL :
"
5.8 DATALINK
Le type DATALINK est une référence à un fichier externe, permettant, par exemple, de stocker des images, de la vidéo, des sons et des fichiers binaires. Les fichiers ainsi référencés restent sur un disque quelconque du système informatique. Les données sont donc externes à la base, mais il est possible de maintenir une intégrité, de manière à interdire modification et suppression des fichiers autrement que par un ordre SQL de la base.
Il se déclare ainsi :
DATALINK [ <options_de_contrôle> ]
...
"
et plus loin
"
SQL:1999 fournit, en outre, des fonctions afin de piloter l’insertion, la restitution, comme l’extraction de certaines parties de l’URI :
• DLVALUE : instancie la valeur de l’URI pour la colonne de type DATALINK (constructeur).
• DLURLCOMPLETE : restitue la valeur de l’URI contenu dans la colonne de type DATALINK.
• DLURLPATH : restitue le chemin de l’URI, avec son origine.
• DLURLPATHONLY : restitue le chemin de l’URI, sans son origine.
• DLURLSCHEME : restitue le mode de flux (http ou file) de l’URI.
• DLURLSERVER : restitue la ressource de l’URI.
"
Ceci existe dans SQL Server depuis la version 2008 sous le nom de FILESTREAM...
A +
En sus, avez vous mis en place un plan d'indexation adéquat ?
À me lire : http://sqlpro.developpez.com/cours/quoi-indexer/
A +
Il faut quand même une clef primaire à ln_putative_inparalog_sequence. Ceci découle du MCD dans lequel cette table était une association de type n:m.
Sans cette clef primaire les lectures seront toujours mauvaise pour les jointures notamment !
A +
lol oui oui c'est pas une giga base mais sa taille se mesure en Go ( sur tout pour moi, habitué à des bases de données de moins de 6 Go sous informix héhéhéhé )
c'est du postgres 9.1
dans les tables il y a entre 21 et 23 millions de lignes
et entre 75 et 95 colonnes.
Grosso modo voici une indication de la taille des bases de données de la petite à la très grande :
http://blog.developpez.com/sqlpro/p8354 … onction_de
Vous êtes donc plutôt dans l'univers des petites bases... Voici par exemple un TRÈS TRÈS grosse base (MS SQL Server) http://fr.wikipedia.org/wiki/Pan-STARRS#Informatique
Ensuite sachez que des tables de 75 à 95 colonnes sont rarement des tables relationnelles. En pratique, des tables relationnelles dépassent rarement les 20 colonnes, et le moyenne est inférieure à la dizaine de colonnes. Il y a certainement un défaut de normalisation. Si tel est le cas (et je parierais à 99,99% pour), c'est un très mauvaise pratique, car aura des conséquences catastrophiques dans le futur, si ce n'est déjà pas le cas (multiplicité des index par exemple).
À me lire : Base de données et performances… petites tables et tables obèses !
http://blog.developpez.com/sqlpro/p1007 … es_petites
Plus généralement :
- 5 principes pour une base de données relationnelle performante
http://blog.developpez.com/sqlpro/p1083 … onnees_rel
- Les 10 meilleures pratiques pour développer avec un SGBDR
http://blog.developpez.com/sqlpro/p6507 … r_ms_sql_s
A +
Y a t-il moyen d'ajouter POSTGIS à la main dans Windows Seven, sans passer par Stack Builder ?
A +
Bonjour,
PostGRESQL 9.1 avec PostGIS 2.0 sous Windows Seven avec l'installeur de dbentreprise et stack builder...
lorsque je vais dans le menu "Outil / Etat du serveur" je me retrouve avec 6 fois la même erreur (pour 5 bases) :
ERREUR : séquence d'octets invalides pour l'encodage " UTF8 " 0xe86d65
Que dois-je faire ?
D’avance merci
A +
Bonjour,
après avoir désinstallé puis réinstallé PostGRESQL 9.1 avec PostGIS 2.0 sous Windows Seven avec l'installeur de dbentreprise et stack builder, je constate des anomalies de fonctionnement.
Après avoir créé une base avec le template "template_postgis_20" et créé la table suivante :
CREATE TABLE T_GEO
(ID SERIAL NOT NULL PRIMARY KEY,
GEO GEOMETRY)ma base refuse cet ordre SQL :
INSERT INTO T_GEO (GEO) VALUES ('POINT(0 0)') Tout comme celui-ci :
INSERT INTO T_GEO (GEO) VALUES (ST_GeomFromText('POINT(0 0)'))Avec le même message d'erreur :
ERREUR: n'a pas pu accéder au fichier « $libdir/postgis-2.0 » : No such file or directory
********** Erreur **********
État SQL :58P01
Bref, je sais pas trop quoi faire !
D'avance merci
A +
Et pourtant c'est bien uniquement en désactivant ce service que nous avons éradiqué le problème.
Peut être une mauvaise installation. Je vais désinstaller et recommencer tout.
A +
Bonjour,
suite à une installation de PostGreSQL 9.1 + PGAgent, sur un ordinateur mobile :
SONY VAIO VPCZ2 (Core i 7, 8 Go RAM, Windows 7 pro 64 bits, Disque SSD)
nous avons constaté les dysfonctionnement suivants :
1) ports USB plus utilisable
2) Wifi inutilisable
3) bluetooth inutilisable
4) paneau de configuration innateignable pour tout ce qui est réseau, imprimante et gestion ordinateur.
Après investigation, nous avons constaté que c'était le service PGAgent qui causait ces dommages.
Nous n'avons pu identifier l'origine profonde du mal....
Tout est rentré dans l'ordre après arrêt de ce service.
Ce problème es-il déjà connu ?
Y a t-il un correctif ?
faut-il procéder à une réinstallation ?
Merci
D'un point de vue performance il est beaucoup plus rapide de supprimer la table que de la vider.
Puis dans l'ordre :
1) CREATE TABLE sans aucun index, mais avec clef primaire
2) insertion des lignes (INSERT INTO...)
3) rajout des éventuelles contraintes d'unicité (ALTER TABLE ... ADD CONSTRAINT ??? UNIQUE (...))
4) rajoute des index (CREATE INDEX...)
A +
Quelles sont les attaques classiques sur pg , au delà de l'injection sql ?
Les attaques par deni de service (DOS), voire les attaques silencieuses (par exemple utilisant la fonction sleep pour générer une attente en cas de recherche positive). Toutes sont généralement liées à du code SQL dynamique.
A +
Bonjour,
J'ai 2 tables : table_ref et table_courante
chacune de ces tables à 64 colonnes desc_0, desc_1 desc ... desc_63
Déjà la modélisation n'est pas bonne. Vous violez par élision la première forme normale, dans le sens ou ces 64 colonnes aurait pu figurer dans un tableau et pourquoi d'ailleurs se limiter à 64 ? (en outre y a t-il des colonnes vides - NULL ?)
Remodélisez en déplaçant ces 64 colonne dans une table liée à la précédente en relation 1:n (n variant de 0 à 64).
Ensuite indexez les tables correctement.
Reprenez vos requêtes et comparez.
A +
Le problème est que...
Proposer des solutions non adaptées à PostgreSQL sur un forum où l'utilisateur cherche une solution pour son problème sur PostgreSQL est tout simplement hors-sujet non ? je peux comprendre que ce soit ajouté dans la discussion comme une fonctionnalité non couverte mais il faut le dire directement et pas laisser Postgres.0 tester des trucs donc on sait pertinnement que cela ne marchera pas sur PostgreSQL.
Pas du tout hors sujet.. Comme PG ne sait pas faire des index INCLUDE, une façon de contourner est de créer un index contenant TOUTES les colonnes utilisées par la requête... Ceci évite la double lecture index + table. C'est un vieux truc utilisé avant que les index INCLUDE arrivent.
Avez vous testé au moins avant de tirer à boulet rouge sur cette solution ???
A +
SQLpro a écrit :CREATE INDEX X2 ON aft (id_org, id_ref, ag_date, id, p,am_c, am_co, am_p, am_pw, am_r, am_s, am_s_n, am_t, nb_of_c, nb_of_c_s, nb_of_co, nb_of_p, nb_of_pw, nb_of_r, nb_of_sale, nb_of_sale_n, nbr_of_c)
A +Overkill, non ?
Le problème est que :
1) PostGreSQL ne sait pas faire de scan d'index (sauf la récente version 9.2, mais j'ai pas encore testé les limites...)
2) PostGreSQL ne propose pas de clause INCLUDE pour les index afin de les rendre couvrant, comme le fais MS SQL Server, ce qui éviterais de lire la table
3) PostGreSQL ne propose pas non plus de vue indexées afin de résoudre ce genre de cas de manière très performante
A +
C'est votre ANY = qui pose problème.
Déjà récrivez le comme suit et testez avec l'index indiqué :
AND id BETWEEN 23158 ANDE 23187 -- strictement équivalent à votre requête.
Ajoutez l'index suivant s'il n'y est pas :
test 1 :
CREATE INDEX X1 ON aft (id_org, id_ref, ag_date, id)
sinon mieux : test 2
CREATE INDEX X2 ON aft (id_org, id_ref, ag_date, id, p,am_c, am_co, am_p, am_pw, am_r, am_s, am_s_n, am_t, nb_of_c, nb_of_c_s, nb_of_co, nb_of_p, nb_of_pw, nb_of_r, nb_of_sale, nb_of_sale_n, nbr_of_c)
Au final remplacez le contenu de votre ANY par une jointure avec une table en dur indexée que vous alimenterez suivant vos besoins...
A +
Qu'est-ce que vous entendez par une transaction logique ? si votre idée est d'encapsuler l'insert dans une base et le delete dans l'autre base, oubliez le two-phase commit car ce n'est pas prévu pour ça.
Et bien si, la validation à deux phases est justement prévu pour ce cas de figure... Le problème c'est qu'il faut un superviseur de transactions. Par exemple MS DTC si vous êtes dans l'univers Windows.
Mais le 2PC, n'est jamais garanti....
Lisez l'article que j'ai écrit à ce sujet : Le mythe du Commit à deux phases...
A +