Quand sortez-vous une analyse de SQL pour la faire en Python ?

Restez en SQL pour filtrer, joindre et agréger, parce que le travail se fait à côté des données et passe à l'échelle sans les déplacer. Passez à Python quand vous avez besoin de modélisation statistique, d'itération ou de simulation, de traitement complexe de chaînes ou de texte, d'appels à une API externe, ou de graphiques reproductibles. Une règle utile : agrégez d'abord en SQL, puis rapatriez le résultat plus petit dans Python pour les parties où SQL est mauvais.

Mon réflexe par défaut est SQL pour tout ce qui est filtrage, jointure ou agrégation, parce que le calcul se fait là où vivent les données et que je ne déplace pas des gigaoctets sur le réseau pour faire un group by que l'entrepôt aurait fait en quelques secondes. Je passe à Python quand la tâche est quelque chose où SQL est vraiment mauvais : ajuster un modèle, lancer une simulation, parser du texte sale, appeler une API externe, ou produire des graphiques que je veux régénérer à l'identique. La règle que je suis, c'est d'agréger d'abord. Je rapatrie le résultat résumé, peut-être cinquante mille lignes, pas les vingt millions brutes, ce que j'ai vu des gens faire avant de se demander pourquoi leur kernel est mort. L'autre facteur est la maintenabilité. Si cette analyse doit être relancée tous les mois par quelqu'un d'autre, du SQL dans un modèle versionné avec des tests vaut mieux qu'un notebook qui dépend de l'environnement d'une seule personne. Si c'est une exploration ponctuelle, un notebook convient parfaitement et s'écrit plus vite.