Quelles sont les bonnes habitudes en SQL ? Comment créer une migration SQL ?

Un article sur les ORM (avec Python, mais presque tout ce qui y est dit est indépendant du langage).

Peut-on faire des migrations SQL sans forcement utiliser d’ORM ?

Oui, il "suffit" d’écrire les scripts de migration en SQL

MySQL permet-il de faire ça simplement ?

Non, ni aucun SGBD relationnel. C’est pour ça qu’on utilise des ORM qui font ça pour nous : écrire des migrations, c’est difficile. Les gérer correctement (rendre le processus fiable, réversible et idempotent) encore plus.

C’est vraiment un gain de temps d’utiliser un query builder ?

Quand tu utilises un langage typé, l’ORM permet de tirer parti du typage statique pour vérifier que tes requêtes sont correctes. En ce sens, oui, c’est un gain de temps : si ta requête contient une erreur, le code ne compile pas.

L’autre chose qui fait gagner du temps, c’est surtout que tu n’as pas à gérer toute la couche de remplissage de tes modèles à partir des requêtes.

Enfin, quand tes modèles s’imbriquent les uns les autres (ce qui se traduit par des relations en SQL), les requêtes commencent à devenir de plus en plus complexes, et dans ce cas, un ORM qui supporte les requêtes eager va vraiment t’épargner d’écrire de grosses requêtes complexes : quand t’as les bons outils, oui, ça fait vraiment gagner beaucoup de temps et d’assurance. Ce qu’un ORM te fournit, c’est une abstraction en-dessous de laquelle tu n’as presque plus jamais besoin de descendre.

C’est aussi des outils pour générer le plus gros du code de tes modèles.

Par exemple, pop fait ça en Go : en une commande où l’on se contente de décrire les colonnes de la table, il te génère le code de base du modèle avec déjà quelques validations implémentées, le stub des tests pour ton modèle, ainsi que les fichiers de migration up et down (donc réversible) pour ce modèle. C’est un vrai gain de temps et de confort.

Ben déjà, utilisation des transactions quand elles sont nécessaires uniquement. Si un ensemble de transactions n’a pas besoin d’être atomique, la transaction est inutile et juste coûteuse.

Sur les transactions toujours, il faut éviter au maximum qu’elles s’éternisent, ce qui pourrait avoir pour effet de verrouiller la table. Donc il faut ne garder dans la transaction que le strict minimum.

Pour le reste des bonnes pratiques, me viennent aussi en tête les requêtes préparées.

Ça dépend de tes requêtes, mais ça peut vite devenir compliqué quand tu imbriques jointures, sous-requêtes et CTE.

On peut faire des requêtes en SQL avec un ORM (je ne sais pas si c’est tous). Voici un exemple avec Doctrine (PHP). En bonus, un second exemple avec Sequelize (JS).

Si c’est trop complexe ou impossible de faire une requête à l’aide de l’ORM, il y a une méthode pour utiliser une requête en SQL.

J’aime beaucoup l’ORM mais comme dit plus haut, dans certains cas, ça peut devenir lourd. D’ailleurs, c’est expliqué dans la documentation de Sequelize :

As there are often use cases in which it is just easier to execute raw / already prepared SQL queries, you can use the function sequelize.query.