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

(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.

sql.js est l'équivalent de SQLite, mais en Javascript.

Google migre ses bases mySQL vers MariaDB. Merci Oracle, tu as bien foutu le bordel.

Je note ça ici: un script pour convertir mySQL en SQLite