PostgreSQL

Pourquoi un virement bancaire a besoin de plus que deux UPDATE Déplacez 50 € d’un compte à un autre et la version naïve, ce sont deux instructions : soustraire du compte A, ajouter au compte B. Exécutez-les séparément et, si le processus plante ou si la connexion tombe entre les deux, l’argent a disparu de A et n’arrive jamais sur B. La base de données a fait exactement ce qu’on lui a demandé, deux fois. L’entreprise a quand même perdu 50 €. ...

Un JOIN mal écrit ne lève pas d’erreur. Il s’exécute, renvoie un résultat, et les lignes sont fausses : des clients manquants, des totaux gonflés, des enregistrements orphelins invisibles. La plupart du temps, la requête a obtenu exactement ce qu’elle demandait, et son auteur a choisi le mauvais type de join, ou filtré au mauvais endroit. Un join combine les lignes de deux tables selon une condition que vous écrivez. Les lignes qui survivent dépendent du type de join, et les six types ci-dessous donnent six réponses différentes à partir des mêmes deux tables. ...

Sur une table d’un million de lignes, la même SELECT peut prendre cinquante millisecondes, ou nettement moins d’une seule milliseconde. Toute la différence tient à un choix : la base de données lit chaque ligne pour trouver celles que vous avez demandées, ou elle saute directement dessus. Un index est ce qui lui permet de sauter, et vous le payez à chaque écriture. Concrètement, un index est une seconde copie triée d’une ou plusieurs colonnes, stockée à côté de la table et mise à jour automatiquement à chaque modification de la table. La base de données l’utilise pour atteindre les lignes correspondantes sans toucher au reste. ...