Suivre

Dites, question bête d'un étudiant naïf (moi) : savoir écrire des requêtes SQL, en vrai, c'est utile à quel point ? (Et de manière plus générale : en gestion de bases de données, n'y a-t-il pas d'outils un peu moins austères qu'il serait tout aussi intéressant de connaître ?)

@zero_ Disons que si un jour ou l'autre tu te frottes à des bases de données, ca peut servir. C'est parfois en faisant des requetes que tu vas comprendre que tu as mal structuré ta base, que tu as oublié des index... TU ne feras pas forcément des requetes en SQL, mais SQL est un moyen simple de comprendre l'utilisation d'une DB. J'ai du apprendre le SQL il y a plus de 30 ans et ca sert encore, donc on est pas prêt d'en être débarrassé.

@zero_ Pour les outils moins austères, y'en a, mais la plupart de ceux que j'ai vu finissaient par générer des requêtes SQL et quand tu avais de problèmes de performances tu n'avais plus qu'à éditer la requête pour l'optimiser, alors bon... Ceci dit, je ne suis pas DBA, donc je n'ai qu'une vision parcellaire du truc. (Et sinon, c'est chiant de faire du SQL, faut se forcer souvent ^^ )

@zero_
Oui c'est important. Même si tu utilises un ORM, il va générer des migrations que tu devras savoir lire. Parfois il sera plus performant, voire carrément obligatoire, que tu écrives tes propres requêtes dans ces migrations parce que tu seras confronté à une problématique particulière. Faire une impasse sur SQL, çaymal :-)

@zero_
Le sql c'est indispensable.
Dans certains cas tu peux t'en passer en passant pas un ORM mais pas toujours.

Par exemple, dans mon boulot, on fait des rattrapages de la BDD quasi toutes les semaines, donc directement en SQL : le script est testé en dev puis poussé en prod (= pas de risque de fausse manip entre les 2, pas besoin de l'intervention d'un expert en production).
Ce sont des cas où il n'est pas possible de passer par le soft pour corriger, soit parce qu'on n'est pas capable d'identifier la source, soit parce que le client a jugé que ça coutait trop cher de mettre en place une solution pérenne.

@zero_ C'est hyper important. Grâce à SQL, tu peux te connecter à une base et faire des interventions chirurgicales à chaud pour corriger un problème, genre

DELETE FROM table ;

et te chopper une bonne suée parce que tu as oublié de mettre la condition WHERE...

@zero_
Parce que toute appli a besoin de stocker des données et ne va pas réinventer la roue. Parce que le SQL est là depuis 30ans et sera encire là dans 30 ans. Parce qu'une base de données peut faire des opérations sur de gros volumes, elle est faite pour ça. Parce que la plupart des bugs de perfs que je vois sont du code écrit par un ORM et pas un humain, ou du code qui aurait dû être écrit en SQL et pas dans le client.

@zero_
Parce que la base de donneées survivra à toutes les réécritures de l'applicatif dans les langgages à la mode. Parce que pour accéder aux données d'une autre appli en masse, le SQL reste souvent le plus efficace.

@zero_
Et ce n'est pas le SQL même le plus important, mais ensuite la modélisation propre des données (le schéma), les notions de transaction, d'intégrité des données et, pour l'efficacité, l'indexation (lecture obligatoire : use-the-index-luke.com/fr)

@zero_ Les outils en questions utilisent en général SQL en-dessous, donc parfois pour faire une requête spécifique, tu peux difficilement t'en passer.

Mais c'est vrai que de plus en plus, les framework et CMs utilisent/mettent ) dispo de ORM (Object Related Model, il me semble) qui à partir d'une définition des objets et de leur relations créé et requête la BDD.

Mais connaître SQL permet de mieux comprendre comment ça fonctionne te facilite la manipulation de ces outils.

@zero_
Faire de la programmation sans connaître sql, c'est un peu comme faire du piano sans savoir lire une partition. C'est faisable... Mais celui qui reste à ce niveau, reste très très limité 😉

Inscrivez-vous pour prendre part à la conversation
Framapiaf

Mastodon est un réseau social utilisant des protocoles Web ouverts et des logiciels libres. Tout comme le courriel, il est décentralisé.