Discussion :

[Marco46]

Mais si cet argument est valable pour les batchs de nuit qui prennent du temps, c'est plus difficile à faire valoir pour des petits traitements. Mais surtout, et là ce n'est pas un problème d'optimisation ni de présentation, beaucoup de développeurs, même excellents, n'ont pas forcément un bon niveau SQL, et ça leur sort par les yeux de voir du SQL qu'ils ne comprennent pas ou dont ils ne veulent pas se donner la peine de comprendre. 4 ou 5 jointures c'est déjà beaucoup pour quelqu'un qui n'aime pas le SQL et qui pense que ça n'a pas sa place dans un développement non batch.

Le truc c'est que c'est méga variable selon l'expert à qui on parle. Je veux dire je me souviens d'avoir lu des posts de SQLPro sur ce forum qui expliquait qu'il en avait marre de voir des devs java pisser des km de codes inutiles et errorprone alors qu'il suffisait de réfléchir un peu à la requête.

En plus en terme de performances ça doit être horrible de fonctionner comme ça. Je veux bien qu'Hibernate ait un système de cache mébon quand même.

Mais bon si tu t'es incliné je ne vois pas le problème, mais comme vous n'avez pas la même façon de penser il a peut-être eu peur de devoir ergoter sans fin et a préféré pour cette raison mettre fin à la période d'essai.

Certes mais ce n'est pas la raison invoquée de sa part

D'une certaine façon, même si ce n'est pas correct de le dire au dernier moment, il vaut mieux que ça se finisse comme ça si vos façons de travailler ne sont pas conciliables même si vos arguments à vous 2 sont tout à fait valables indépendamment.

Bah après comme je te le disais je me suis plié aux consignes à posteriori. Donc je vois pas où est le soucis. On ne peut pas être d'accord sur tout. J'ai l'impression que certains ne supportent aucune contradiction et ont besoin d'être les seigneurs.

On peut parfaitement ne pas être d'accord, discuter, prendre une décision et respecter la hiérarchie. Si on ne peut pas faire ça, on ne peut pas progresser puisqu'il est nécessaire de savoir au préalable si la suggestion va plaire ou non. On sclérose à mort.

+1, surtout que malheureusement avec les périodes d'essai de 4+4 mois tu es encore dans les clous de la période d'essai.

Non c'est 4 + 3. J'étais à 10 jours de la fin.

[icsor]

Bonjour,

quelques remarques sur votre dernier message :

Le truc c'est que c'est méga variable selon l'expert à qui on parle. Je veux dire je me souviens d'avoir lu des posts de SQLPro sur ce forum qui expliquait qu'il en avait marre de voir des devs java pisser des km de codes inutiles et errorprone alors qu'il suffisait de réfléchir un peu à la requête.

La personne s'appelle SQLPro, ce qui déjà en soit, devrait mettre la puce à l'oreille quand à sa compétence dans ce domaine. C'est sur que si on parle à un expert DBA, il va trouver que n'importe qu'elle requête est lisible et que les dév java font n'importe quoi. J'ai 4 développeurs java dans mon équipe, je pense que j'en ai un seul qui serait capablme de lire mes requêtes les plus complexes, aucun qui comprendrait pourquoi je mets tel hint sur ma requête. Ils font du code SQL simple, mais quelques soit la personne de l'équipe, c'est lisible. La complexité du code est aussi dicté par la vie futur du code (one shot ou TMA pendant 30 ans).

Non c'est 4 + 3. J'étais à 10 jours de la fin.

C'est Syntec qui limite le renouvellement de la période d'essai à 3 mois. Par contre, pour avoir déjà été du coté employeur, quand on a un bon élément en période d'essai, on fait tout pour qu'il reste et on va certainement pas lui ralonger la période d'essai, c'est un risque énorme pour l'entreprise.

Pour votre cas personnel, je vous dirai simplement d'avoir (encore) du courage pour une recherche d'emploi et de voir le coté positif de chacune de vos expériences.

[el_slapper]

J'ai un grave défaut, je dis ce que je pense. Il faut que j'apprenne à arrondir les angles, je pensais avoir mis de l'eau dans mon vin par rapport à ya quelques années mais visiblement il faut dilluer à mort.

Il faut emballer. Là, je viens de faire comprendre plein de vérités désagréables à ma chef, mais sur le ton de la rigolade, dans le genre "ailleurs c'est pire", "j'en ai vu d'autres", "mais bon, je ne peux pas m'empecher de rire - et tu sais pourquoi. Par contre, je vais faire ce que tu veux, comme tu veux, je sais que c'est important". J'ai fait des progrès, les 13 dernières années. J'en ai encore à faire(notamment sur les dynamiques inter-équipes)

Et, aussi, il faut d'abord gagner la confiance des gens. Quand j'arrive dans une nouvelle mission, je la ferme, et j'obéis. Une fois que j'ai eu l'occasion de faire mieux que les autres, je commence à proposer un, deux petits trucs. Et je vois si ça prend.

Ouai ... On parle de 4 ou 5 jointures avec ptet quelques SUM/AVG/ etc ... un GROUP BY et un HAVING. Faut quand même pas déconner. Si le SQL n'est plus lisible où on va ?

Les autres ont répondu : ça dépend pour qui.

Bon, je suis biaisé, aussi : j'appartiens au monde COBOL, ou il est préférable de décharger la table dans un fichier plat, de faire un batch qui le traite, et de recharger la table à partir du nouveau fichier plat - COBOL est idéal pour ça(tant qu'on a pas 2 jointures à simuler, et encore, je l'ai déjà fait).

Dans le monde JAVA, ça se discute. Mais suivant les gens, tu auras l'une ou l'autre préférence.

C'est pas faux, je vois que le noir pour le moment.

C'est le plus grand danger. Des gens ayant confiance en eux peuvent renverser des montagnes de recruteurs avec un CV de merde.

Oui mais j'ai précisé que bien que n'étant pas d'accord avec le chef et bien que lui ayant signifié, je fais depuis comme il veut, plein de jolis boucles avec tout plein de totaux qu'il faut tester en unitaire.

Tu lui as dit? Tu lui as dit qu'en fait ça marche bien, sa technique?



Sinon, tu as raison de ne pas chercher à t'accrocher. Une réputation, ça colle.

[Marco46]

Bonjour,

quelques remarques sur votre dernier message :

La personne s'appelle SQLPro, ce qui déjà en soit, devrait mettre la puce à l'oreille quand à sa compétence dans ce domaine. C'est sur que si on parle à un expert DBA, il va trouver que n'importe qu'elle requête est lisible et que les dév java font n'importe quoi. J'ai 4 développeurs java dans mon équipe, je pense que j'en ai un seul qui serait capablme de lire mes requêtes les plus complexes, aucun qui comprendrait pourquoi je mets tel hint sur ma requête. Ils font du code SQL simple, mais quelques soit la personne de l'équipe, c'est lisible. La complexité du code est aussi dicté par la vie futur du code (one shot ou TMA pendant 30 ans).

Je veux bien l'entendre mais je voudrais aussi faire remarquer que les études de dev incluent des cours de SQL qui couvrent 95% des besoins des applications de gestion (Jointures, GROUP BY, HAVING, ...) (Tiens ça me fait penser que les tests techniques de cette boite inclus ces notions, on est donc supposés savoir tous faire ça).
Le fond de la question c'est quel niveau en SQL on veut que les devs aient.

Je veux dire, on développe pas du code Java dégueulasse sous prétexte que les devs seraient pas capable de le lire. Je vois pas pourquoi ça serait pas vrai pour le SQL.

Que ce soit compliqué de lire du transact SQL complexe avec des procédures stockées appelant des fonctions SQL maisons etc ... Ok. Mais des jointures non, pour moi ya un soucis.

C'est Syntec qui limite le renouvellement de la période d'essai à 3 mois. Par contre, pour avoir déjà été du coté employeur, quand on a un bon élément en période d'essai, on fait tout pour qu'il reste et on va certainement pas lui ralonger la période d'essai, c'est un risque énorme pour l'entreprise.

Oui certes. Je n'étais pas un bon élément à ses yeux c'est certain. Ou du moins pas comme il le voulait et pas assez docile.

Pour votre cas personnel, je vous dirai simplement d'avoir (encore) du courage pour une recherche d'emploi et de voir le coté positif de chacune de vos expériences.

Il faudra bien

[Marco46]

Il faut emballer. Là, je viens de faire comprendre plein de vérités désagréables à ma chef, mais sur le ton de la rigolade, dans le genre "ailleurs c'est pire", "j'en ai vu d'autres", "mais bon, je ne peux pas m'empecher de rire - et tu sais pourquoi. Par contre, je vais faire ce que tu veux, comme tu veux, je sais que c'est important". J'ai fait des progrès, les 13 dernières années. J'en ai encore à faire(notamment sur les dynamiques inter-équipes)

Et, aussi, il faut d'abord gagner la confiance des gens. Quand j'arrive dans une nouvelle mission, je la ferme, et j'obéis. Une fois que j'ai eu l'occasion de faire mieux que les autres, je commence à proposer un, deux petits trucs. Et je vois si ça prend.

C'est la sagesse de l'âge ça. Je suis encore trop jeune ou trop obtus

Tu lui as dit? Tu lui as dit qu'en fait ça marche bien, sa technique?

Ben non. J'ai fait à contre coeur.


Bref au final j'ai eu un deuxième entretien avec lui et la RH pour leur indiquer qu'ils s'étaient plantés sur le document signé hier. Visiblement c'est la première fois qu'on leur fait remarquer ça ou bien ils ont fait un peu d'acting.

L'entretien a été bref, j'ai expliqué que ça ne m'intéressait pas d'aller jusqu'au 18/12, j'ai eu droit à une leçon de morale sur le fait d'être payé sans travailler ce à quoi j'ai rétorqué que outre que c'était la loi, ça ne semblait pas beaucoup le gêner de lourder les gens du jour au lendemain sans leur donner une chance de modifier les choses. Il n'est pas d'accord et prétend que j'aurai du voir les signaux. Je ne suis pas devin.

Mon collègue développeur semble stupéfait du déroulement de ces 2 derniers jours. Il n'a rien vu venir lui non plus.

Au final mon ex-chef a pris un coup de sang et m'a libéré aujourd'hui même. Du coup on part pas en méga bons termes puisque lui semblait trouver normal de virer quelqu'un et le garder un mois pour taffer sur un boulot où on te dit au bout de 7 mois qui tu fais pas la maille. Pour moi c'est du grand n'importe quoi et humainement je ne me voyais pas faire comme si de rien n'était les dernières semaines à continuer à rigoler avec eux (l'ambiance était plutôt bonne). Pour lui ça semble aller de soit. On a pas la même vision des choses.

Bref, voilà c'est fini, demain matin ce sera du passé. Merci à tous les intervenants pour leurs remarques et leurs soutiens.

[phili_b]

Il n'est pas d'accord et prétend que j'aurai du voir les signaux. Je ne suis pas devin.

Il est peut-être sincère mais tu ne peux pas deviner, à moins ça soit la confrontation quotidienne, la prochaine fois il devra être plus clair.

Au final mon ex-chef a pris un coup de sang et m'a libéré aujourd'hui même.

Au moins il n'a pas cherché à t'emmerder.

Bref, voilà c'est fini, demain matin ce sera du passé. Merci à tous les intervenants pour leurs remarques et leurs soutiens.

Et c'est parti pour de nouvelles aventures Bon courage pour tes recherches maintenant que tu sais à quoi t'en tenir et que c'est derrière toi

[Manu0086]

Bon ben voilà, t'as au moins gagner une dizaine de jours ^^

Un mois payé à chercher un autre job, c'est pas si mal :cool:

De plus, ils réfléchiront peut-être davantage quand ils voudront lourder quelqu'un à l'avenir.

[Carhiboux]

Bon courage pour la suite!

[el_slapper]

C'est la sagesse de l'âge ça. Je suis encore trop jeune ou trop obtus

Moi aussi, en fait. Un peu moins qu'avant, mais je fais encore des erreurs.

Ben non. J'ai fait à contre coeur.

Ca n'est pas une raison. Je sais, nos sommes des techos, notre force, c'est d'être factuels, mais parfois, il faut arrondir les angles. Ma chef vient de me prolonger d'un mois. Les autres se plaignent du manque d'interêt de leur travail. Je lui est dit "je n'ai pas le pire boulot dans l'équipe, donc ça va".

En fait, ça me fait ***er d'être prolongé, mais je n'y peux rien, alors je peux me plaindre et avoir plein de rancoeur dans le coeur, et me faire mal voir, ou alors dire que "ça va", me faire mieux voir, mais aussi avoir le coeur plus léger.

Bref au final j'ai eu un deuxième entretien avec lui et la RH pour leur indiquer qu'ils s'étaient plantés sur le document signé hier. Visiblement c'est la première fois qu'on leur fait remarquer ça ou bien ils ont fait un peu d'acting.

Non, je pense réellement qu'ils étaient surpris. Je peux me tromper, mais c'est le plus probable.

L'entretien a été bref, j'ai expliqué que ça ne m'intéressait pas d'aller jusqu'au 18/12, j'ai eu droit à une leçon de morale sur le fait d'être payé sans travailler ce à quoi j'ai rétorqué que outre que c'était la loi, ça ne semblait pas beaucoup le gêner de lourder les gens du jour au lendemain sans leur donner une chance de modifier les choses. Il n'est pas d'accord et prétend que j'aurai du voir les signaux. Je ne suis pas devin.

Tu as fait au mieux : tu a négocié de meilleures conditions pour ton départ. Il était impossible pour toi d'espérer plus.

Mon collègue développeur semble stupéfait du déroulement de ces 2 derniers jours. Il n'a rien vu venir lui non plus.

Normal. Vous bossiez, vous ne faisiez pas de politique. C'est un autre métier. J'ai du faire du pilotage cet été en l'absence des chefs, j'ai fait des conneries, parceque je ne sais pas faire. Le gars est chef depuis des années, il s'imaginait que j'allais être parfait du premier coup. En étant prévenu la veille, en son absence, sans connaitre le projet, sans personne pour me guider.

"voir les signaux", c'est un métier. C'est pour ça qu'il m'est arrivé de prévenir des gens qu'ils étaient dans le collimateur. Ils étaient les seuls à ne pas s'n douter. Après, dans les 2 cas, ils n'ont pas changé. Tant pis pour eux. Je leur ai donner leur chance. Je ne pouvais pas faire plus.

Au final mon ex-chef a pris un coup de sang et m'a libéré aujourd'hui même. Du coup on part pas en méga bons termes puisque lui semblait trouver normal de virer quelqu'un et le garder un mois pour taffer sur un boulot où on te dit au bout de 7 mois qui tu fais pas la maille. Pour moi c'est du grand n'importe quoi et humainement je ne me voyais pas faire comme si de rien n'était les dernières semaines à continuer à rigoler avec eux (l'ambiance était plutôt bonne). Pour lui ça semble aller de soit. On a pas la même vision des choses.

ça va de soi en SSII, en mission chez le client. Ils voulaient me virer après l'incident dont je parle au-dessus. Ils viennent de me prolonger jusqu'à la fin Décembre, et il est inconcevable que je glandouille d'ici là. J'ai même un client qui était "très content que j'ai fait l'impossible", qui me laissait partir à la fin du projet parceque j'avais déplu à la personne qu'il ne fallait pas...et qui m'a prolongé 11 jours pour un truc imprévu.

Les derniers jours, on a toujours du mal. Mais dans ton cas, tu avais le droit avec toi. Moi pas. Donc j'ai quand même bossé - même si le coeur n'y était plus. Etre professionel, c'est aussi arriver à continuer à bosser quand le coeur n'y est plus.

Bref, voilà c'est fini, demain matin ce sera du passé. Merci à tous les intervenants pour leurs remarques et leurs soutiens.

Bon courage pour la suite!

[fredoche]

Je veux bien l'entendre mais je voudrais aussi faire remarquer que les études de dev incluent des cours de SQL qui couvrent 95% des besoins des applications de gestion (Jointures, GROUP BY, HAVING, ...) (Tiens ça me fait penser que les tests techniques de cette boite inclus ces notions, on est donc supposés savoir tous faire ça).
Le fond de la question c'est quel niveau en SQL on veut que les devs aient.

J'ai pas l'expertise qu'ont certains ici, mais il est une chose évidente, c'est que les SGBD sont optimisés pour gérer des données et des ensembles de données.
En cas d'accès concurrentiel, pour le web qui est mon domaine, il n'y a pas photo, toutes les facilités apportées par un SGBD c'est énormément de temps de gagné sur le traitement d'une demande, et c'est un point essentiel pour la "scalabilité"
Le gros du boulot d'une appli web aujourd'hui, c'est de piocher dans un SGBD. Si le SGBD peut te présenter le résultat tout fait, le temps gagné est énorme.

Je ne sais pas quelle était la finalité du projet, mais tu es toi sur les bonnes pratiques, pas ton chef.
En plus les JVM sont pas des foudres de guerre, boucler sur des grands ensembles, ça doit être drôle.

Je me forme sur mongodb en ce moment, bases dénormalisées, pas d'intégrité référentielle et pas de jointures, elles se font depuis l'appli si on en a besoin. Rien que ça tue l'intérêt de ces outils je trouve.

Par contre c'est le genre de produit qui irait bien à ton chef, il faudrait lui recommander, ça justifierait ses méthodes d'architecture logicielle, puisque tu peux pas faire autrement.


Bonne chance pour la suite, ce dont tu témoignes pour ce dernier entretien ne me surprend pas plus que ça.

Fais attention à soigner l'estime que tu as de toi-même, ne te culpabilise pas de ce dont tu n'es pas maître, c'est important pour ta vie au quotidien, mais aussi pour la suite professionnelle.

[Carhiboux]

J'ai pas l'expertise qu'ont certains ici, mais il est une chose évidente, c'est que les SGBD sont optimisés pour gérer des données et des ensembles de données.
En cas d'accès concurrentiel, pour le web qui est mon domaine, il n'y a pas photo, toutes les facilités apportées par un SGBD c'est énormément de temps de gagné sur le traitement d'une demande, et c'est un point essentiel pour la "scalabilité"
Le gros du boulot d'une appli web aujourd'hui, c'est de piocher dans un SGBD. Si le SGBD peut te présenter le résultat tout fait, le temps gagné est énorme.

Je ne sais pas quelle était la finalité du projet, mais tu es toi sur les bonnes pratiques, pas ton chef.
En plus les JVM sont pas des foudres de guerre, boucler sur des grands ensembles, ça doit être drôle.

Tout dépends du contexte c'est sur.

Mais d'une manière générale, le niveau de la plupart des devs classiques en SQL est faible. C'est une réalité et il faut faire avec. Si demain, ton chef te remplace par une développeur lambda, il ne sera peut être pas aussi fort que toi en SQL, mais il devra bien pour autant maintenir ton code.

Un code simple c'est un code maintenable. Même si il est long.

Une requête compacte... cela peut être plus dur à lire.

Donc j'entends les deux points de vue, et il y a des cas qui justifient l'usage de la requête complexe (j'ai eu l’exemple d'une carte qui devait afficher 15 millions de points en moins de 15 secondes, là pas question de faire du traitement sur le résultat de la requête!! ), mais dans la plupart des cas, je vais préférer voir du code java (ou autre) qu'une grosse requête SQL.

Ne serait-ce que parce que le code java, je vais pouvoir le lire en 10 minutes pour un truc très complexe.

La requête SQL... il me faudra bien plus de temps, probablement aller voir en base comment c'est boutiqué, etc...

[phili_b]

c'est que les SGBD sont optimisés pour gérer des données et des ensembles de données.
En cas d'accès concurrentiel, pour le web qui est mon domaine, il n'y a pas photo, toutes les facilités apportées par un SGBD c'est énormément de temps de gagné sur le traitement d'une demande, et c'est un point essentiel pour la "scalabilité"
Le gros du boulot d'une appli web aujourd'hui, c'est de piocher dans un SGBD. Si le SGBD peut te présenter le résultat tout fait, le temps gagné est énorme.

[Invité]

Salut Marco,
j'avais répondu sur ton autre post. C'est réglé cette histoire de date de départ et de paiement des 1 mois de délai de prévenance ?

[fredoche]

Tout dépends du contexte c'est sur.

Mais d'une manière générale, le niveau de la plupart des devs classiques en SQL est faible. C'est une réalité et il faut faire avec. Si demain, ton chef te remplace par une développeur lambda, il ne sera peut être pas aussi fort que toi en SQL, mais il devra bien pour autant maintenir ton code.

J'ai du mal à recevoir cet argument Carhiboux.

Je suis un auto-didacte, je n'ai pas de diplômes liés à l'informatique, juste une formation de webmaster il y a 15 ans où j'ai vu SQL et modélisation en 40h (1 semaine).
J'ai appris à apprendre, à me mettre à niveau et à m'adapter.

Pour moi ça ne veut rien dire "fort en ..." dans notre métier. D'ailleurs je me demande si ce n'est pas une terminologie Java/.Net.

Moi je suis fort à TF2 ou en VTT, en soulevé de terre (j'ai un record de bourgogne ) mais en SQL, c'est un langage que je pratique, au même titre que d'autres langages. En transact-SQL mes meilleurs profs sont F1 et shift+F1, les docs MS sont excellentes sur cet outil. Et SQLpro bien sur, qui sévit depuis au moins 15 ans sur les newsgroup ou par ici

J'ai plein de complexes dans ce métier, mon métier, du fait du nombre de cadors qui viennent parader avec leur diplome bac+++++ et leur mépris des "codes pourris" qu'ils lisent chez les autres devs. Mais je n'ai jamais fait qu'apprendre depuis 15 ans, et pas que dans le développement logiciel ou applicatif.

Alors j'ai beaucoup de mal quand tu me dis ça, pour moi, c'est une des qualités principales d'un informaticien que de savoir apprendre et s'adapter, et il n'est pas question de force.

[Carhiboux]

Sur l'idée, je suis 100% d'accord avec toi.

Tu peux remplacer "fort" par "à l'aise" si tu préfères.

Mais cela ne changera pas la réalité qui est que malgré (ou à cause de? ) tous leurs éventuels diplôme, une bonne part des informaticiens ne sont pas forcément ce que j’appellerai des débrouillards.

Si il ne savent pas faire, il ne vont pas chercher à faire, et encore moins à apprendre.

Ils vont se retourner vers leur collègue débrouillard (et d'expérience, il y en a TOUJOURS au moins un dans les équipes qui marchent bien) et refiler la patate chaude (à moins que ce soit le collègue débrouillard qui se dise qu'il a plus vite fait de faire lui même que d'expliquer au non débrouillard).

C'est l'éternelle différence entre la théorie, et la pratique.

En théorie, un informaticien doit être capable de s'adapter et d'apprendre. Donc de comprendre une requête SQL complexe.

En pratique... c'est loin d'être le cas. Et c'est ce qui justifie un certain pragmatisme dans la conception et le développement.

[el_slapper]

+1 avec carhiboux. J'ajouterais que dans tout métier il y a 30% d'incompétents. Le dev n'y échappe pas. Ma doctrine, c'est que même un incompétent doit pouvoir arriver à comprendre mon code. Si je fais du SQL avec autre chose qu'un WHERE, il est chocolat. Donc je simplifie. Les COALESCE sur des UNION sur des LEFT INNER JOIN avec des IN et autres, c'est typiquement le truc que 30/40% des professionels ne comprendront jamais.

Alors qu'une bête boucle et un bête if, on doit tomber à 15%.


Et + 1 aussi sur les diplômes : on peut être bon matheux et n'avoir aucune capacité d'abstraction simultanée à deux niveaux différents. Et donc ne rien paner à un code informatique. La selection est déplorable. Et on doit faire avec.

[phili_b]

+1 avec carhiboux. J'ajouterais que dans tout métier il y a 30% d'incompétents. Le dev n'y échappe pas. Ma doctrine, c'est que même un incompétent doit pouvoir arriver à comprendre mon code. Si je fais du SQL avec autre chose qu'un WHERE, il est chocolat. Donc je simplifie. Les COALESCE sur des UNION sur des LEFT INNER JOIN avec des IN et autres, c'est typiquement le truc que 30/40% des professionels ne comprendront jamais.

Alors qu'une bête boucle et un bête if, on doit tomber à 15%.

Quand les perfs ne baissent pas, pourquoi pas, mais quand les perfs chutent là y'a pas photo, il faut rester avec une requête SQL complexe et puissante plutôt que n requêtes qui vont mettre des plombes et dont en plus on ne va plus comprendre les tenants et aboutissants tellement l'implémentation est dispersée.

Par contre je ne parlerais pas d'incompétence. Je préfère quelqu'un de compétent dans son domaine (java par exemple), qui avoue son incompétence dans un autre domaine (SQL par exemple) et s'en remet à toi, ou simplifie son SQL s'il a personne sous le coude, personne n'est à 100% polyvalent, que quelqu'un qui impose une implémentation pauvre du SQL avec des arguments fallacieux, comme semble le faire l'ex-chef de Marco46.

[Carhiboux]

Quand les perfs ne baissent pas, pourquoi pas, mais quand les perfs chutent là y'a pas photo, il faut rester avec une requête SQL complexe et puissante plutôt que n requêtes qui vont mettre des plombes

Oui, mais cela ne concerne qu'un infime minorité des requêtes à mettre en oeuvre.

La plupart du temps, pour du web, on va faire des requêtes qui vont retourner, entre une et une vingtaine de lignes...

Il y a surement des métiers très spécifique qui justifient que tout soit optimisé au max, mais c'est alors l'exception et non pas la règle.

[el_slapper]

Quand les perfs ne baissent pas, pourquoi pas, mais quand les perfs chutent là y'a pas photo, il faut rester avec une requête SQL complexe et puissante plutôt que n requêtes qui vont mettre des plombes et dont en plus on ne va plus comprendre les tenants et aboutissants tellement l'implémentation est dispersée.

mais encore faut-il avoir une requête optimisée, et pas avec 15 jointures.

après, moi, je parle du monde COBOL qui est fort différent du web, mais entre un SELECT FROM A,B et SELECT FROM A, puis SELECT FROM B, et un rapprochement à la mimine, il n'y a pas photo : le second est plus rapide(pour peu que les index ne soient pas débiles).

Par contre je ne parlerais pas d'incompétence. Je préfère quelqu'un de compétent dans son domaine (java par exemple), qui avoue son incompétence dans un autre domaine (SQL par exemple) et s'en remet à toi, ou simplifie son SQL s'il a personne sous le coude, personne n'est à 100% polyvalent, que quelqu'un qui impose une implémentation pauvre du SQL avec des arguments fallacieux, comme semble le faire l'ex-chef de Marco46.

On joue sur les mots. Mais quelqu'un qui arrive péniblement à comprendre mon code, et qui n'arrive pas du tout à comprendre mes requêtes, il est incompétent. Il ne sait pas apprendre. Pourtant il existe, et je dois faire attention à lui. Mon code lui est dédié.

[fredoche]

La plupart du temps, pour du web, on va faire des requêtes qui vont retourner, entre une et une vingtaine de lignes...

Quand tu vas chercher ces lignes au sein d'ensembles de millions de lignes, le nombre de résultats ne compte que très peu, surtout si tu dois faire du sort, du limit ou du from to...

C'est difficile de généraliser pour le web, la diversité est telle...
Retiens tout de même l'idée que petit à petit beaucoup d'applis deviennent des applis web, donc tu peux avoir une complexité équivalente à ce que tu connais dans des domaines plus classiques.

Et l'une des problématiques des applis web comme des sites web, c'est le ressenti utilisateur. C'est, sans prétention , un art de faire un site web qui répond vite, parce que justement ça fait appel à une bonne somme de compétences diverses, et de créativité pour contourner les problèmes.
Le référentiel partagé par tous désormais, c'est 2 secondes max entre requête et page rendue/finie dans le web browser.
Ton datawarehouse et la puissance de ses fonctions a un rôle majeur face à cette problématique