mais plutot sur declarer ce que les autres doivent savoir.
Bah disons que quand c'est le point (la méconnaissance des SGBDR) qui fait passer de 10s à 18h d'exécution, non ce n'est plus "un savoir parmi d'autres" mais "le problème n°1".
Je ne peux qu'abonder dans le sens de l'auteur du journal et du commentaire initial. Venant d'un monde JEE, j'ai vu mon lot de développeurs d'applis de gestion qui ne comprennent rien aux SGBDR / à SQL (voire refusent de) et les horreurs que ça provoque. Alors que dans le même temps, dans chaque test de recrutement on leur demandera la différence entre une TreeMap et une LinkedHashMap (donc ils la connaissent, éventuellement par cœur sans la comprendre). Différence dont on se bat les gonades dans le contexte de la majorité des applis JEE car elles contiendront maximum 100 éléments et auront la durée de vie d'une requête HTTP, alors qu'un pauvre index sur la table utilisée ferait passer le temps de chargement de cet écran de 10s à 10ms (et je parle même pas de mieux modéliser les données).
Je ne sais pas pourquoi mais c'est comme ça. Enfin si j'ai une vague idée, liée au fantasme des abstractions comme Hibernate et équivalents ailleurs (quand j'ai fait de très modestes contribs à des projets non-Java, même des avec pignon sur rue, j'ai vu de ces trucs qui m'ont bien décomplexé de mon passé Javaiste, comme quoi c'est pas une question de langage utilisé...), qui promettent d'abstraire totalement le stockage concret des données. Note que j'aime bien Hibernate pour ce qu'il apporte réellement, mais je reste lucide. Mais malheureusement on a formé des générations de développeurs qui pensent que "le stockage des données ça juste marche et c'est pas un problème".
Donc je n'ai pas de preuve parfaitement scientifique, mais j'ai l'impression que oui, le problème des développeurs qui font des horreurs avec leur modélisation / stockage des données, est bien plus grave que "là tu aurais pu dérouler ta boucle et gagner 10 cycles de processeur".
[^] # Re: Beaucoup de dev ne savent pas faire du SQL
Posté par Sufflope (site web personnel) . En réponse au journal Optimisez votre code !. Évalué à 7.
Bah disons que quand c'est le point (la méconnaissance des SGBDR) qui fait passer de 10s à 18h d'exécution, non ce n'est plus "un savoir parmi d'autres" mais "le problème n°1".
Je ne peux qu'abonder dans le sens de l'auteur du journal et du commentaire initial. Venant d'un monde JEE, j'ai vu mon lot de développeurs d'applis de gestion qui ne comprennent rien aux SGBDR / à SQL (voire refusent de) et les horreurs que ça provoque. Alors que dans le même temps, dans chaque test de recrutement on leur demandera la différence entre une TreeMap et une LinkedHashMap (donc ils la connaissent, éventuellement par cœur sans la comprendre). Différence dont on se bat les gonades dans le contexte de la majorité des applis JEE car elles contiendront maximum 100 éléments et auront la durée de vie d'une requête HTTP, alors qu'un pauvre index sur la table utilisée ferait passer le temps de chargement de cet écran de 10s à 10ms (et je parle même pas de mieux modéliser les données).
Je ne sais pas pourquoi mais c'est comme ça. Enfin si j'ai une vague idée, liée au fantasme des abstractions comme Hibernate et équivalents ailleurs (quand j'ai fait de très modestes contribs à des projets non-Java, même des avec pignon sur rue, j'ai vu de ces trucs qui m'ont bien décomplexé de mon passé Javaiste, comme quoi c'est pas une question de langage utilisé...), qui promettent d'abstraire totalement le stockage concret des données. Note que j'aime bien Hibernate pour ce qu'il apporte réellement, mais je reste lucide. Mais malheureusement on a formé des générations de développeurs qui pensent que "le stockage des données ça juste marche et c'est pas un problème".
Donc je n'ai pas de preuve parfaitement scientifique, mais j'ai l'impression que oui, le problème des développeurs qui font des horreurs avec leur modélisation / stockage des données, est bien plus grave que "là tu aurais pu dérouler ta boucle et gagner 10 cycles de processeur".