Post 9nl47aKkF3RCsnTKz2 by christophecourtois@framapiaf.org
 (DIR) More posts by christophecourtois@framapiaf.org
 (DIR) Post #9nkqWKL3RudV9lWLuC by zero_@framapiaf.org
       2019-10-09T16:30:28Z
       
       0 likes, 1 repeats
       
       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 ?)
       
 (DIR) Post #9nktZizoWu8AMSthdQ by djiko_iko@framapiaf.org
       2019-10-09T17:03:42Z
       
       0 likes, 1 repeats
       
       @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 :-)
       
 (DIR) Post #9nkzd1ceKidMiw1GZk by oranadoz@framapiaf.org
       2019-10-09T18:12:10Z
       
       0 likes, 1 repeats
       
       @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...#souvenirs
       
 (DIR) Post #9nkzrMmITRZyOIN1XM by MlleChat@miaou.drycat.fr
       2019-10-09T17:11:38Z
       
       0 likes, 1 repeats
       
       @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.
       
 (DIR) Post #9nl3iQGCYasYOxLgJs by christophecourtois@framapiaf.org
       2019-10-09T18:58:16Z
       
       0 likes, 1 repeats
       
       @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.
       
 (DIR) Post #9nl3mXKGEIdtTOD1Y8 by christophecourtois@framapiaf.org
       2019-10-09T18:58:58Z
       
       0 likes, 1 repeats
       
       @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.
       
 (DIR) Post #9nl47aKkF3RCsnTKz2 by christophecourtois@framapiaf.org
       2019-10-09T19:02:58Z
       
       0 likes, 1 repeats
       
       @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 : https://use-the-index-luke.com/fr)