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.

[quote] les solutions de data-warehouse sont faites pour ça [/quote]

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 : [color=red]"select * from devis where signature='jacques dupont'"[/color] 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 ? [b][size=150]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.[/size][/b] 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, [u]la modélisation expliquée fait exactement ce qu'il demande avec des jointures sur des champs integer[/u].

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 :
[quote="iclo"]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) [/quote]
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.

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é ?

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.

[quote="iclo"]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. [/quote]
Pas de jointure

[quote="iclo"]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. [/quote]
Pas de jointure

[quote="iclo"]pour faire des statistique sur le nombre de devis négocié par un commercial, tu auras donc une jointure[/quote]
Pas de jointure

[quote="iclo"]la liste de tous les commerciaux avec des infos sur leurs profils et en regards le nombre de devis dont ils sont responsables.
[/quote]
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.

[quote="iclo"]

Je te demandais de me montrer comment afficher la liste de tous les commerciaux avec des infos [size=134][color=red]sur leurs profils[/color][/size] et en regards le nombre de devis dont ils sont responsables.

[/quote]

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.

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
[code]
select cound (id_devis), signature from devis group by signature
[/code]
Voici la solution avec l'id du commercial dans le devis
[code]
select cound (a.id_devis), b.nom from devis a, commercial b where a.id_commercial = b.id_commercial group by b.nom
[/code]
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.

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.

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 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

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" ?

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.

Tout a fait sauf que si tu relis l'historique de [b]mes[/b] 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 :roll: ) puisque j'ai l'impression que tu utilises cet argument comme il te plait et non comme je l'ai dit

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

[quote="Henri"]Allons-y, ergottons, ergottons pour quelques millisecondes. :roll: :wink:[/quote]
Je vais essayer d'être clair et concis :
[size=150][b]J'ai dit que ce critère n'est pas le critère principal que je prend en compte[/b][/size]

Excusez moi d'avance pour cet excès mais je n'ai pas l'impression qu'[b]Henri[/b] 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 ;)