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  :-)

(sous le coude)

Une recommandation d'utiliser des UUID à la place des auto-incréments en bases de données.
(J'avais aussi lu l'inverse... ^^)

OVH est l'un des plus importants hébergeurs mondiaux.
Ils sont donc confrontés à des problèmes peu communs, comme celui de sauvegarder un million (glups) de bases de données chaque jour.
C'est toujours intéressant de voir comment ils s'y prennent (et j'aime les entreprises qui partagent leur expérience).
(via http://links.kevinvuilleumier.net/?SwboWA)

J'aime SQLite.
Article similaire en français: http://www.developpez.com/actu/94614/Cinq-raisons-d-utiliser-SQLite-en-2016/
(via http://lehollandaisvolant.net/?id=20160109175118)

Hoper nous gratifie d'une études sur les méthodes d'injection SQL. Intéressant !

Visiblement il est possible de faire des attaques à travers mysql_real_escape_string().  Ce n'est donc pas la panacée pour vous protéger des attaques d'injection SQL.