
Envoyé par
pascal-od
Publier des infos sur le site web serait de l'inconscience au niveau de la sécurité. Avec un tel enjeu politique, il y a bien trop de monde qui rêve d'un piratage du site web.
Admettons...
un piratage, si certains sont tentés, ils n'auront pas besoin de ça, passer en revue tous les exploits du moment est souvent plus efficace. Mais évidemment ce serait faciliter la tache... Il n'empêche que... le contenu dévoilé est pauvre
Publier l'ensemble, c'est offrir la possibilité à des yeux différents de regarder ton code et lever des loups que tu n'imagines même pas.

Envoyé par
pascal-od
Quel serait ici techniquement l'avantage des jointures explicites par rapport aux jointures implicites ?
Je ne suis pas un spécialiste, donc je vais me garder des certitudes. Si quelqu'un sait mieux répondre que moi, qu'il n'hésite pas.
La question est combien de fois cette ou ces requêtes sont exécutées, ainsi que toutes celles qui ne nous sont pas données à voir.
Et sur quels jeux de données travaillons-nous ?
Cela a trait à l'optimisation des requêtes...
Un SGBD travaille sur des ensembles (de données), qu'il va grouper, croiser, réduire, afin d'offrir des réponses correspondantes à tes critères de requêtes.
En utilisant des jointures explicites, le mot-clef join, tu donnes des indications à l'optimisateur de requête, celui qui va faire ces opérations, sur la façon dont tu mets en relation ces tables, pour ensuite filtrer les résultats (la clause where).
C'est peut être pas optimal selon comment tu écris ces jointures et leur ordre, mais toi tu connais tes données et leur organisation. Néanmoins tu optimises le jeu de résultats sur lequel va se faire le filtrage.
Quand tu as tout dans la clause where, tu mets tout le contenu de toutes les tables en mémoire, puis tu demandes à l'optimisateur SQL de se débrouiller avec toutes tes clauses. A lui de trouver lesquels appliquer en premier, puis croiser, puis réduire. En gros à lui de déterminer le meilleur plan d'exécution. Et plus tu mets de clauses et plus les combinaisons entre tables augmentent, et moins cette recherche du meilleur plan sera rapide, voir possible.
De toute façon cette syntaxe fait partie de la norme SQL depuis 1992. Quand je me suis fait remarquer à ce sujet par SQLpro c'était en 2004. On est en 2018 et je dois vous expliquer ça, à des développeurs de métier ?
2 autres points comme ça en relisant ce même code d'où j'avais pris la requête : ConnecteurDonneesPropositionsOracle.java
le gars utilise des statements et des prepared statements : visiblement il utilise les 2e quand il a des paramètres à passer. C'est bien d'un point de vue sécurité, éviter les injections SQL.
Mais les prepared statements c'est aussi garder en mémoire un plan d'exécution de la requête, c'est écrit ici par exemple: https://docs.oracle.com/javase/7/doc...Statement.html : "This object can then be used to efficiently execute this statement multiple times. "
Or ses grosses requêtes avec une dizaine de tables jointes, mais qui n'ont pas de paramètres, bah ils les passent avec un java.sql.statement, pas avec un preparedstatement. Donc sans optimisation d'aucune sorte. Pas de rétention du plan d'exécution qui sera recalculé probablement à chaque fois. C'est peut être des ms, mais tous ces ms comptent, croyez-moi
Ces prepared statement existent dans tous les langages, même les plus anciens.
D'un point de vue pratique je vous fais pas de dessin sur la différence entre garder un plan d'exécution en mémoire, et ressortir des milliers de lignes de données pour évaluer comment il conviendra de les assembler avant de les filtrer.
Donc pour ma part sur mes serveurs dotés de plusieurs Go de RAM, j'utilise uniquement des requêtes préparées. Et je cherche pas à savoir si ça irait plus lentement sans. C'est plus que probable. Au pire ça ne nuit pas.
Et quand on travaille avec des données, autant en tirer le meilleur, c'est du bon usage des SGBDR.
Et quand je lis l'instruction
stmt.setFetchSize(1000000);
bah en regardant la ref, je comprends que le gars réserve un million de lignes en retour. Ca fait déja pas mal
Et je ne fais pas de Java, la dernière fois que j'ai écris du java j'avais 20 ans de moins.
Enfin bref ... existerait-il une argumentation raisonnable contre l'utilisation du mot clef "join" en SQL ?

Envoyé par
Sodium
Je ne parle pas du choix des technos mais de l'attitude snob bien française de refuser de se soumettre à un standard.
La majorité des évolutions informatiques récentes ont été réalisées par des anglophones. La majorité des programmes sont écrits en anglais. L'immense majorité des ressources de qualités pour l'apprentissage sont réalisées en anglais et il faut des mois pour qu'apparaissent potentiellement des ressources de qualité en français. C'est comme ça et c'est une excellente chose car cela signifie qu'une seule langue permet de communiquer avec les développeurs du monde entier.
Donc oui, si vous voulez être un bon développeur, apprenez et pratiquez régulièrement l'anglais et écrivez vos programmes en anglais car on n'est jamais certain de qui est susceptible de devoir le lire.
J'abonde...
Je crois qu'il n'y a pas photo, sans maitrise à minima de l'anglais, je vois pas comment on peut prétendre rester à la page.
Cependant pour le problème que tu évoques du retard technologique, je crois que c'est aussi sinon en majeure partie lié à la façon dont l'informatique existe en France, essentiellement à travers de la prestation de service vendue par des SSII.
Peu d'éditeurs, pas beaucoup de startup, donc probablement peu de gens amenés à développer des vrais produits, de vrais applis et des vrais offres de service numériques pour lesquelles les responsabilités ne soient pas diluées, divisées eg sans notion de projet commun, et de concurrence.
Partager