Un petit gestionnaire de bases de données web en php supportant MySQL, MariaDB, PostgreSQL, CockroachDB, SQLite, MS SQL, Oracle et autres.

Quelques faits amusants et particuliers à propos de SQLite.

Un chouette outils en ligne pour expliciter (y compris graphiquement) les EXPLAIN PLAN de Postgres, et de bien voir ce qui consomme le plus.

mySQL pourrit par le rachat par Oracle => mariaDB.
Et maintenant mariaDB est racheté par un fond d'investissement.
Il est temps de le fuire.

PS: Pour préciser, c'est la partie "Entreprise" qui se fait racheter, pas la fondation.

Sous le coude : une extension vectorielle à SQLite (très pratique pour faire des requêtes du genre : donne-moi les point à moins de telle distance de tel point. Ou bien: Donnes-moi tous les points situés dans ce rectangle.)

DuckDB peut être une alternative à SQLite, intéressante car elle utilise tous les coeurs du CPU. (https://duckdb.org/)

Sous le coude : Des tutoriels pour Postgres, avec un terminal sql directement dans le navigateur pour expérimenter.

Oh mais non, pas encore.
Ils se rappellent encore pourquoi ils ont forké MySql ? 🤦🏻‍♂️

Bon je retourne sur mes SQLite et Postgres.

Sous le coude : un long article sur le chiffrement des données en base de données.

Sous le coude: Choisir ses clés primaires sous Postgres.

Sous le coude: Un livre pour développeur avec quelques astuces SQL.
PS: Il faut s'inscrire à la mailing-list pour recevoir le livre.  Si cela vous embête, voici le livre : https://sebsauvage.net/nc/s/GdSGGJEnMGPDM2D

Utiliser SQLite pour stocker des données sensibles, ce n'est pas con : SQLite étant immensément plus simple que des bases comme Postgres ou Oracle, la surface d'attaque est largement inférieure.
(Et c'est sans compter que SQLite est très fortement testé et résiste très bien aux crashs. Le "redémarrage" du serveur est également nettement moins problématique.)

Quand un ancien de l'équipe MySQL/MariaDB décide de quitter Oracle en disant que - franchement - vous ne devriez pas utiliser MySQL/MariaDB et que vous devriez vraiment regarder du côté Postgres, on peut se dire que oui, il y a des problèmes.
(Et cela rejoint les constatations que j'ai pu faire dans mes boulots précédents: MySQL pose beaucoup de problèmes. Postgres est plus intéressant et possède désormais des fonctionnalités plus avancées et il est plus performant.)

PS: Oui je sais que MariaDB est forké de MySQL et n'a plus à voir avec Oracle.

Sous le coude.
SQLite est une formidable base de données, mais très simple. Elle n'a pas certaines fonctions avancées de Postgres ou Oracle. Mais SQLite est facilement extensible, et beaucoup de monde a développé des extensions. En voici quelques unes (fonctions de hashage, recherche flou et phonétique, fonctions json, expressions régulières, UUID...)

Sous le coude: Des supports de formation pour la base de données Postgres.

Sous le coude parce que ça pourra me servir: Insérer 1 milliard de lignes dans une base SQLite en moins d'une minute.

Si on résume (extrait de l'article):

PRAGMA journal_mode = OFF;
PRAGMA synchronous = 0;
PRAGMA cache_size = 1000000;
PRAGMA locking_mode = EXCLUSIVE;
PRAGMA temp_store = MEMORY;

What do these do?
- Turning off journal_mode will result in no rollback journal, thus we cannot go back if any of the transactions fail. This disables the atomic commit and rollback capabilities of SQLite. Do not use this in production.
- By turning off synchronous, SQLite does not care about writing to disk reliably and hands off that responsibility to the OS. A write to SQLite, may not mean it is flushed to the disk. Do not use this in production.
- The cache_size specifies how many memory pages SQLite is allowed to hold in the memory. Do not set this to a high value in production.
- In EXCLUSIVE locking mode, the lock held by the SQLite connection is never released.
- Setting temp_store to MEMORY will make it behave like an in-memory database.

De bonnes raisons d'utiliser SQLite (autre que celles que j'énonce d'habitude)

Pour Postgres. Sous le coude on ne sait jamais.

Woo alors attendez: SQLite peut:
- supporter l'insertion directe de json
- avoir des colonnes virtuelles basées sur le json
- et donc permet du requêtage sur ces colonnes virtuelles.
On peut donc utiliser SQLite pour stocker du json et requêter dedans en profitant des indexes et du tri !
(via http://nicolas-delsaux.hd.free.fr/Shaarli/?chmZMQ)

Sous le coude: Un client SQL multibases qui permet d'afficher directement des graphes à partir des requêtes SQL.
Ça peut être sympa pour avoir rapidement des vues sur les données sans pour autant se monter un BO.

Sous le coude: Les choses à ne pas faire dans Postgres.

Sous le coude: Quelques recommandations de configuration pour Postgres.

La faille de SQLite a été montée en épingle.
En réalité, vous n'êtes vulnérable que si :
1) vous avez activé le module recherche full text (FTS3) (qui ne fait pas partie du coeur de SQLite)
et
2) Vous exécutez du code SQL arbitraire.
Si vous êtes dans le cas 2), vous être déjà dans une énorme merde question sécurité, avec SQLite ou n'importe quelle autre base, en fait.

Pour mon boulot, après avoir pratiqué de l'Oracle et du SQL Server pendant des années, j'aborde Postgres (j'ai un gros script à adapter pour Postgres).

Je veux importer des CSV, et je découvre la commande COPY qui permet de coller directement son CSV dans le script  \o/
C'est dix fois plus pratique que les outils Oracle.

J'importe des données, erreur sur un format de date: Postgres me suggère la bonne option à utiliser \o/

Je sens que je vais aimer ce dbms  :-)