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.

Si tu dois combiner des informations issues de la table commercial et devis, je ne vois pas comment c'est faisable sans jointure.

Je sais parfaitement qu'il arrive de devoir dénormaliser partiellement une base de donnée (et ne met absolument pas en doute ce que tu affirmes sur les applications partiellement dénormalisées), mais je pense que c'est une décision complexe, et je ne juge pas ça souhaitable de le conseiller d'entrée de jeu à une personne qui vient poser une question sur le forum, sans avoir l'ensemble des détails sur le contexte. (ni le niveau de compétence de la personne)
Peut-être que ta solution est la meilleure dans le cas présent, mais sans informations précises, je ne pense pas qu'il soit possible de faire un choix objectif. Espérons que notre débat aura permis à l'initiateur de son poste d'avoir des éléments suffisant pour faire le meilleur choix pour l'application qu'il dévellope.

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.

Pas de jointure

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.

Pas de jointure

pour faire des statistique sur le nombre de devis négocié par un commercial, tu auras donc une jointure

Pas de jointure

la liste de tous les commerciaux avec des infos sur leurs profils et en regards le nombre de devis dont ils sont responsables.

Oui, une jointure, tu y es arrivé. Mais il a fallu que tu ailles la chercher celle là.
De toute façon, quelque soit la solution adoptée, il y aura une jointure puisque tu ne vas pas mettre l'ensemble de la fiche du commercial dans le devis. Je ne vois pas où est le problème. Et je te signale en passant qu'avec une table normalisée, dans les trois premières questions que tu as posé, tu auras une jointure.

Mais n'oublie pas de répondre à mon petit problème. Il n'est pas du tout artificiel, lui. Il se passe hélas trop souvent.

Bien-sûr que j'aurais une jointure, mais une jointure sur un id numérique, donc beaucoup plus rapide que sur une chaine de caractère.
Les DBMS sont conçu dans l'optique d'optimiser ce genre de requêtte.

Contrairement à ce que tu as l'air de penser, je n'ai pas été chercher la demande nécessitant obligatoirement une jointure bien loin, que du contraire, Elle date d'ailleurs d'un bout de temps dans ce topic si tu relis mes messages précédents.

Il n'est pas illogique qu'un gestionnaire veuille voir une liste de commerciaux avec leurs résultats. Comme il fait partie du travail du designer d'anticiper les raisonnablement les nouvelles attentes que l'utilisateur pourrait formuler.
Trop souvent une base de donnée est conçue pour un besoin trop précis et finit en usine à gaz à la suite de bidouillage lorsqu'on sort du cahier des charges initial.

Je crois pouvoir dire que réaliser des jointures entre des tables en sql n'est pas vraiment quelque chose d'exceptionnel
Comme je pense que recycler les informations d'un commercial quand il quitte la boite, pour les réaffecter à un autre est dangereux.

Si on veut travailler avec des notions d'historiques sans conserver dans la base de donnée de production, des informations sur d'anciens commerciaux, les solutions de data-warehouse sont faites pour ça et permettent justement d'éviter des compromis évitables dans la modélisation de la base de donnée de production.

Afin de mettre un terme à ce débat qui ne fait que tourner un rond, je vais tenter de faire un point rapide.

N'hésitez pas à me reprendre.

La modélisation théorique à retenir est l'utilisation de clés étrangères, de tables intermédiaires, ...

En pratique, il existe des cas (taux de TVA, echange de comptes, ...) où il vaut mieux réflechir à l'utilisation qui va en être faite afin de parer les mauvaises utilisations.

Les manières de parer ces utilisations peuvent aussi bien être de forcer l'utilisateur à suivre LA manière obligatoire, voire de limiter les droits, avec les limites que celà comporte, c'est à dire qu'il est impossible de prévoir l'utilisation qui va etre faite d'une application.
Mais également de prendre quelques libertés avec la modélisation, au risque de perdre de la facilité de maintenance ou de l'évolutivité.

Je pense avoir fait un compte-rendu assez synthétique de ce qui c'est dit dans ce thread.

Pouvons nous considérer que le débat est terminé ?

les solutions de data-warehouse sont faites pour ça

La signature au bas d'un devis, c'est pour indiquer qui a fait le devis. C'est uniquement visuel, sauf de temps en temps pour faire une recherche sur quels devis a fait jacques dupont, c'est à dire une fois par an au maximum : "select * from devis where signature='jacques dupont'" Cela n'a aucun autre but. Ce n'est pas pour faire des stats, ce n'est pas pour faire des jointures, ce n'est pas pour faire des calculs de rentabilité, c'est uniquement pour montrer à l'écran qui a fait le devis ou sortir la liste des devis de jacques dupont qui s'est barré il y a 2 ans. Ca va, c'est compris ? Je n'ai jamais, jamais dit que ce champ signature était fait pour faire des jointures. Je n'ai jamais, jamais programmé ce champ signature pour faire des jointures. J'en ai un peu ras le bol que l'on me fasse dire des choses que je n'ai pas dites. Et s'il faut sortir un datawarehouse à je ne sais combien de dizaines de milliers d'euros pour répondre à la question "quelle est la liste des devis de jacques dupont", c'est qu'il y a quelque chose de pourri au royaume de l'informatique !

Tant qu'on y est, pourquoi est-ce qu'on stocke la date dans le devis. Pourquoi ne pas stocker un id vers une table qui contient les dates ? J'aimerai que iclo lise enfin attentivement la modélisation que j'ai expliqué et qu'il voit que toutes les objections qu'il m'apporte sont résolues avec la notion de fonction commerciale. Et comme à un instant T, un commercial = une fonction commerciale, la modélisation expliquée fait exactement ce qu'il demande avec des jointures sur des champs integer.

Merci pour la leçon sur le cahier des charges. J'ajouterais que les cahier des charges oublient trop souvent les utilisateurs, leurs qualités et leurs défauts. Le cas que je signalais (celui du commercial qui échange son code et son mot de passe) arrive trop souvent pour pouvoir être négligé. Et si la réponse que tu apportes à ce problème, c'est un datawarehouse, on n'est pas sorti de l'auberge ! Jusqu'à présent, le débat était à peu près sérieux.

Je terminerais sur une phrase qui m'a fait bondir :

mais je pense que c'est une décision complexe, et je ne juge pas ça souhaitable de le conseiller d'entrée de jeu à une personne qui vient poser une question sur le forum, sans avoir l'ensemble des détails sur le contexte. (ni le niveau de compétence de la personne)

Eh bien non, je ne suis absolument pas d'accord. On n'est pas sur un forum destiné à de la vulgarisation. On est sur un forum technique et il est normal d'aller au-delà des réponses simplistes du type "De maniere generale il faut toujours stocker la clef primaire d'un champ." surtout si la réponse est complexe. C'est même surtout dans ces cas complexes qu'il faut essayer d'expliquer : cela s'appelle de la pédagogie. Au contraire de toi, je trouve fortement souhaitable de dire aux gens que ce n'est pas si simple au lieu de les aiguiller sur les réponses simplistes parce qu'on ne connait pas leur niveau de compétence. Regarde mon premier post dans ce thread : j'essaye de faire appel à l'intelligence de celui qui pose la question en lui disant "attention, ce n'est pas aussi simple". Comme disait l'autre, aider les gens, ce n'est pas leur donner du poisson, c'est leur apprendre à pêcher.

Ceci est définitivement mon dernier message sur ce sujet.

Pour moi, la discussion est close.
Dommage, qu'il ne soit pas possible d'avoir un débat sans que certains ne se sentent forcés de hausser régulièrement le ton.