Ca me fait penser à l'histoire des dévellopeurs qui ont décidé un jour d'encodé des années de dates sur deux chiffres en se disant que la fin du siècle était loin.

Et ils avaient parfaitement et absolument raison. Bien sûr, avec l'optique des années 90-2000, avec des ordinateurs qui alignent les Mo de RAM, les Go de disques, cela semble parfaitement ridicule. Je peux te dire que dans les années 70, dire l'octet était rare est un doux euphémisme : chaque octet gagné était une victoire.

On voit surtout ce que ce qu'a coûté le passage en l'an 200 en travaux de modification (d'ailleurs le passage à l'euro a coûté beaucoup plus cher).
Mais est-ce qu'on a calculé ce que 2 octets de plus par enregistrement stocké sur 30 ans et plus auraient coûté :
- en espace disque quand les disques durs plafonnaient à quelques Moctets et que le prix/octet était non négligeable. Idem pour les bandes magnétiques.
- en temps de traitement sur des ordinateurs pas très rapide (selon les critères actuel) : lire et traiter 4 octets au lieu de 2, c'est deux fois plus de temps, donc c'est deux fois plus cher.

Que penseront les informaticiens dans 30 ans quand ils verront qu'en 2000, il y avait 53 langages informatiques différents avec des jargons particuliers selon les machines. Que des gens passaient leur temps à prendre un programme pour "Linux" et le modifier pour le faire tourner pour "Windows" et que d'autres prennaient le même programme pour le faire tourner pour "Mac OS" au lieu d'utiliser -évidemment- le "Universal Language Translation". Qu'il fallait sélectionner les actions avec une ridicule petite flèche à l'écran manipulée par une espèce de demi-patate en plastique posée à côté d'un truc avec 102 boutons.

Méfions nous des jugements a posteriori sur ce qui c'est passé il y a des dizaines d'années.

Mais ceci est une autre histoire ...

Et ils avaient parfaitement et absolument raison.

Ca c'est un vaste débat, sur lequel j'ai bien ma petite opinion, mais on est déja suffisament hors-sujet du problème initial de jointure...

Il ne nous a pas été indiqué ce que l'application devait pouvoir faire, rien ne nous dit qu'un jour le gestionnaire du système ne voudra pas savoir combien de clients chaque commercial a sous sa responsabilité. et là, il y en aura une belle de jointure.

Où ? Il n'y a toujours pas de jointure.

Bon, j'arrête là, je sens que le ton commence à monter et qu'on tourne en rond sans avancer.

Relis bien le post d'hier à 21h14 que j'ai écris sur la fonction commerciale dont l'id sert à marquer les clients et le nom du commercial qui sert à signer les devis. Tu y trouveras les réponses aux objections que tu fais. Y compris sur cette histoire de performance qui commence vraiment à devenir un peu lourde parce que vous vous attachez aux performances dans certains cas, mais pas dans d'autres.

Qu'un programme soit vital ou non, il doit avoir une certaine robustesse et une certaine adaptabilité.

On pourra, si tu le désires, ouvrir un thread sur les facteurs et critères de qualité d'un programme, ceux qui sont en conflit et ceux qui se renforcent. cf les travaux de J.A. McCall sur la question.

Y compris sur cette histoire de performance qui commence vraiment à devenir un peu lourde parce que vous vous attachez aux performances dans certains cas, mais pas dans d'autres.

Je me permettrais d'ergotter sur ce point parce que je l'ai cité une fois et que j'ai par la suite dit que je ne prennais pas que ça en compte

Tu avances des idées que se défendent. Tant au niveau performance que utilisation. Mais, du point de vue robustesse et évolution, ce sont des freins immenses.


A partir de ce point, et comme tu le dit bien, il est clair qu'il y 2 points de vue completement opposé et que chacun est persuadé du bien fondé de son opinion. Je vous conseille donc d'arrêter ce débat qui s'enlise et qui tourne en rond.

Mais je dit ça ... je dit rien

Allons-y, ergottons, ergottons pour quelques millisecondes.

Non, sérieusement, j'arrête. J'ai dit ce que j'avais à dire sur le sujet, ce qui se résumé à "réfléchissons avant d'agir et d'appliquer bêtement des recettes de cuisine". La valeur ajoutée d'un analyste (dans quelque domaine que ce soit), c'est de connaître les règles qui sont dans les manuels, mais de savoir quand il doit ne pas les appliquer.

Mon intervention initiale était juste pour rappeler ce point-là parce que la première réponse à la question posée, c'était "tu stockes l'id" et basta.

Voila. C'est tout.

Si le gestionnaire veut avoir une liste de commerciaux avec le nombre de client, il y a aura une jointure entre la table commercial et client.
On peut supposer qu'avant de choisir quel commercial va s'occuper d'un client, il veuillent tenir compte de critère comme la charge de travail de l'ensemble des commerciaux (par ex: celui qui a le moins de clients)

Je ne pense pas qu'il y ai un problème, jusqu'à maintenant la conversation est des plus courtoise, non ?
Personne n'ergotte, c'est plutot que chacun à ses priorités, pour moi quelques miliseconde sur une requêtte, ça peut être beaucoup en fonction du nombre de fois où elle sera exécuté.

Allons-y, ergottons, ergottons pour quelques millisecondes.

Je vais essayer d'être clair et concis :
J'ai dit que ce critère n'est pas le critère principal que je prend en compte

Excusez moi d'avance pour cet excès mais je n'ai pas l'impression qu'Henri m'écoute sinon.

Ma proposition n'était pas une modération, loin s'en faut, uniquement un point de vue de participant qui remarque que le débat tourne en rond.

Mais comme je viens de le dire, ce n'est qu'un conseil et je ne viendrais pas à modérer ce sujet tant que le ton reste celui qui est utilisé jusqu'a maintenant

eh oh, calmos ! Tu vois les deux petits smileys derrière mon texte. Cela signifie "Humour".

Tout a fait sauf que si tu relis l'historique de mes messages, tu pourras lire à plusieurs reprise ce que je viens d'écrire et que le fait d'écrire en gros n'est pas un signe d'énervement mais une mise en avant (comme je l'indique dans mon précédent post, juste en dessous du texte en gros ) puisque j'ai l'impression que tu utilises cet argument comme il te plait et non comme je l'ai dit

Henri :il faut être logique, soit tu préfères comme tu l'as annoncé sur ce poste clore la discussion, et on en reste là, mais alors je ne comprends pas la raison de l'envoit d'un mp, où tu hausses le ton, (avec entre autres des "noms de dieu" dans le texte)

Pour en revenir au problème initial : tu veux mettre en clair le nom du commercial dans la table devis ? ok, pour faire des statistique sur le nombre de devis négocié par un commercial, tu auras donc une jointure.

Ben oui, je met des "noms de dieu" parce que je me demande si tu as lu ce que j'ai écrit et que je te demande depuis 1 heure de relire. Si je te l'ai envoyé en message privé, c'est pour ne pas gonfler les gens avec cette histoire de jointure sur laquelle tu t'accroches et pour ne pas recopier inutilement ce que j'ai déjà écrit. Mais même après te l'avoir envoyé en MP, je me demande encore si tu as lu. Cela dit, tu veux en reparler, reparlons-en pour mettre tout à plat.

Arrêtons de discuter dans le vide et passons à du concret. Tu soutiens qu'il faut des jointures. OK : montre-les. Ecris les requêtes avec les jointures afin qu'on puisse discuter sur du concret et pas sur du concept.
Cela aura au moins le mérite de clarifier la situation et éviter les incompréhensions.

Alors allons-y : qu'est-ce que tu vois comme requête pour "faire des statistique sur le nombre de devis négocié par un commercial" ?

Je t'ai cité des exemples pratiques dans mes messages précédents. Mais tu n'as pas répondu à la manière dont tu y répondrais avec la structure de donnée que tu préconnises

Je n'ai pas été assez précis dans ma demande.
Ecris ce que tu vois comme requête SQL, écris des SELECT avec ces fameuses jointures. C'est ça que je veux dire quand je dis "faisons du concret" : faisons du SQL.
Moi, j'ai beau tourner et retourner ça dans tous les sens, dans ta demande de "statistiques sur les devis d'un commercial", je ne vois pas de jointure. Toi oui. Je te demande juste de les mettre en évidence en écrivant l'ordre SQL que tu imagines.

Je t'ai mis une description très simple d'un problème qui se poserait avec ta structure de donnée, il t'aurait suffit de lire mes messages précédents.

Je te demandais de me montrer comment afficher la liste de tous les commerciaux avec des infos sur leurs profils et en regards le nombre de devis dont ils sont responsables.
Je ne vais pas te pondre le code sql qui correspond à ma solution, qui est trivial, vu que ma base de donnée est normalisée.

C'est à toi de nous prouver que ta solution est viable dans le temps et du point de vue efficacité charge de travail.

Note : Je te signale en passant qu'il y a un champ et un seul dans la solution que je propose qui n'est pas normalisé. Celui de la signature du devis. Tout le reste marche de manière parfaitement normalisée, avec clé primaire/clé étrangère.

Avec ta base de données entièrement normalisée, explique comment tu vas résoudre ce cas ?

Jean Dupont a fait des devis pendant des mois. Il quitte la société. L'admin du système est en réunion pour toute la journée. Pas de souci, Jean Dupont file son code et son mot de passe à son remplaçant Jacques Durand. Celui-ci modifie le nom et le prénom dans la fiche commercial et le tour est joué. Question : quelle structure as-tu mis en place pour qu'on puisse reconnnaître les devis de Jean Dupont et les distinguer de ceux de Jacques Durand.

La solution : il est interdit de passer le code à son voisin est bien entendu non valable. Va t'en empêcher de le faire.

Après, je pourrais te poser des études un plus rigolotes sur des échanges de portefeuille client (un des sports préférés des commerciaux).

Je regrette simplement que tu dises qu'à la question 'quel est le nombre de devis par commercial', tu répondes qu'il faille faire une jointure, mais que tu refuses d'écrire la moindre ligne de code SQL et que tu te contentes de me renvoyer vers d'hypothétiques explications tout aussi abstraites. Tu me permettras de trouver la dérobade un tout petit peu facile.

Alors, voici ma solution avec la signature dans le devis Voici la solution avec l'id du commercial dans le devis Question : où se trouve la jointure ?

Quant à te prouver qu'elle est stable dans le temps : quelle meilleure preuve que de dire que j'ai participé à au moins trois applications qui employaient des structures similaires pour tout ce stockage d'information historique informative et que ces applications ont fonctionné (fonctionnent) pendant plusieurs années. Mais je suppose que ce n'est pas une preuve acceptable puisque je ne peux pas vous les montrer. Il n'y a donc rien à prouver, rien à montrer.