Désolé, mais je ne vois vraiment pas où le fait de mettre l'id du commercial dans la table client vient poser un problème avec les utilisateurs de l'application. La logique veut qu'un utlisateur fera une recherche pour choisir le commercial à affecter, on va pas lui demander de saisir en toutes lettres le nom du commercial, et mettre en toute lettre ce qu'il a saisi dans la table client, non ? (sinon bonjour les fautes de frappes, etc)
Envisagé de mettre le nom du commerical dans la table client, ça viole totalement, les rêgles de la normalisation, en introduisant de la redondance très lourde (j'imagine qu'un commercial sera responsable de nombre certains de clients) et lorsqu'il y a une telle redondances, on commence à avoir des problèmes de cohérences.
Bref, dans certains cas, on peut parfois être amené à enfreindre les rêgles de la normalisation, mais dans le cas présent, il est plus que manifeste que cela ne se justifie pas, donc j'ai du mal à comprendre où est le problème....

Salut,

Intéressant comme post.

Je suis developpeur dans une boîte et il y a des choses que les personnes qui utilisent l'appli ne peuvent pas toucher. Une données sensibles comme celle-la (TVA) ne pourra pas être éditer... Cela résout le problème. Même la plus stupide des personnes le comprendra (et pourtant y'en a qui peine vraiment). Le problème des commerciaux sera le même.

Pour moi stocker des chaînes de caractères comme les noms prenoms comme clé impose une gestion très particulière de l'application. Surtout que si une faute a été commise dans le prénom / nom du commercial, il va falloir modifier dans toutes les tables les clés correspondantes.

D'où au final tout un système mis en place pour le developpeur plutôt bancal...

En ce qui me concerne je reste persuadé qu'une clé primaire est la plus efficace des méthodes, quelque soit le problème... Il est plus facile de gérer un numéro fixe qu'une chaînes de caractères variable.

L'impossibilité d'éditer/supprimer un taux de TVA, résoudra le problème. Il sera bien obligé d'en ajouter un

C'est un avis personnel, ça n'engage à rien et c'est vrai que comme qui dirait : "Ca se discute"....

++

@iclo

Tu fais comme tu veux et comme tu penses. J'ai fait part de mon expérience car j'ai bossé pendant plus d'une dizaines d'années sur des cahiers des charges d'applications de gestion commerciale dans le domaine de la publicité, de la presse, de la vente de pièces automobiles, du cinéma, ... Au départ, j'étais comme tout le monde, pétri de certitudes et d'a priori sur le respect absolu du formalisme.

Et au bout d'un moment tu déchantes. Quand le directeur commercial vient d'expliquer qu'il ne retrouve plus les devis de Jacques Dupont et que tu passes 3 jours à les rechercher avant de comprendre que quand Jacques Dupont est parti, Jean Durand a récupéré son code et son mot de passe et a juste corrigé le nom et le prénom associé au compte (prévu initialement pour modifier les fautes de frappe). Va expliquer au directeur commercial que ta modélisation est correcte vis à vis des règles des modèles relationnels et que c'est l'utilisation qui est foireuse. Tu comprendras ta douleur !

Mais il faut que chacun construise son expérience. Je ne dis pas plus que "réfléchissez bien avant d'agir et sachez déroger aux règles quand cela est nécessaire". L'application bête et méchante d'une méthode est souvent aussi nuisible que pas de méthode du tout.

@jobi

Surtout que si une faute a été commise dans le prénom / nom du commercial, il va falloir modifier dans toutes les tables les clés correspondantes.

Juste deux remarques :
1) Il n'a jamais été question d'utiliser tout le temps le nom et le prénom. Bien sûr qu'il faut utiliser l'identifiant comme clé primaire/clé secondaire. Mais le cas qui nous intéresse est un cas très particulier : celui de la signature au bas d'un devis. Quand toi, tu signes un courrier, tu ne signes pas de ton numéro de sécu, tu mets bien ton nom et ton prénom ?
2) L'argument de la faute de frappe dans le nom et le prénom est l'argument classique. Bien sûr qu'il faut pouvoir modifier le nom et le prénom, mais tu fais cela au début AVANT QUE LE COM FASSE SES DEVIS !

Alors, je vais écrire de manière bien visible la solution que nous avions trouvé pour ce genre de problème :

• On a une table des fonctions commerciales : cela dépend de l'organisation de l'entreprise, mais ça peut être un truc du style commercial du secteur auto, commercial du sud-est de la France, ... Si nécessaire, on peut avoir des services commerciaux au-dessus, mais ne compliquons pas.
  On a une table des commerciaux avec leur id, leur nom, leur prénom, leur code, leur mot de passe et leur fonction commerciale (id sur la table ci-dessus).
  Les clients sont rattachés à des fonctions commerciales.
  Les devis sont rattachés à des clients. Le nom et le prénom du commercial qui a fait le devis sont apposés en signature du devis. Pour gagner du temps, on peut (mais c'est une redondance qu'il faut gérer) ajouter l'id de la fonction commerciale.
  
  - Si on veut connaître tous les devis d'un commercial qui est parti, on cherche sur la signature. C'est peut-être un peu long, mais plus rapide que consulter les impressions papier. Cela n'arrive presque jamais, mais quand un directeur demande, y a intérêt à ce que ça marche.
  - Quand un commercial s'en va, le nouveau commercial qui le remplace récupère la fonction commerciale (peu importe comment, soit par la création d'un nouveau commercial, soit en récupérant le code et le mot de passe). Il récupère donc par ce biais l'ensemble des clients et donc l'ensemble des devis. Mais ces anciens devis ne sont pas signés par lui, tandis que les nouveaux le sont.
  - Quand un commercial veut savoir où en sont ses devis, on fait une interrogation par sa fonction commerciale : comme ça, il sait où en sont les siens propres et ceux de tous ces prédécesseurs à ce poste.
  - Quand on réorganise les secteurs (ça arrive plus souvent qu'on ne le croit), il suffit de créer de nouvelles fonctions commerciales et d'y transférer les clients (et donc les devis suivent, d'où mon option sur l'id fonction commerciale sur les devis).
  - Quand un commercial part et n'est pas remplacé, on prend ses clients et on les répartit sur les fonctions commerciales de ses ex-collègues. Les devis suivent automatiquement. Pareil quand on embauche un commercial pour aider un autre qui a trop de boulot.
  
  C'est à dire que cette solution dissocie la fonction d'un côte de la personne de l'autre. Si vous y réfléchissez un peu, vous vous rendrez compte que dire que c'est un commercial qui fait un devis est trop flou. Il faut différencier le commercial (poste, fonction) de la personne physique (nom, prénom). Si à un instant T, ces informations coïncident, à l'instant T+1 elles peuvent être dissociées. La fonction est restée, mais la personne a changé ou inversement, la personne est restée, mais sa fonction a changé. D'où la nécessité que nous avons eu d'introduire la fonction commerciale en plus de la personne.

Alors, maintenant, on parle performances :
On me dit que quand on fait une recherche sur un index alphanumérique, cela consomme plus de ressources que sur un index numérique. C'est vrai. Mais combien de fois fait-on des recherches sur nom+prénom ?(note au passage : on peut tout à fait proposer une liste déroulante préalablement remplie avec un select distinct signature from devis).

D'un autre côté, l'affichage des devis en cours est une opération que chaque commercial va effectuer des dizaines et des dizaines de fois par jour. Qu'est-ce qui est le plus efficace ? Au nom du sacro-saint principe de la clé primaire obligatoire apprise à l'école, pour ne pas perdre en performances sur une requête rarement utilisée, on va perdre en performances sur des requêtes utilisées tous les jours ? Faites votre choix, camarade !

intéressant tout ça

modélisation théorique vs réalité du terrain:

je me souviens d'un formulaire de 170 question, j'avais modélisé:
_ 1 réponse = 1 ligne

sauf que 20 personnes saisissaient les données en même temps, ce qui a fait goulot, pourtant la modélisation était bonne, souple et tout et tout.

j'ai revu la copie:
_ 1 questionnaire = 1 ligne de 170 réponses

et c'est passé tout seul

conclusion:
il faut être pragmatique, savoir modéliser et prendre du recul par rapport à la théorie, pour pouvoir mettre en pratique.

A+

Pascal

oulala, je ne me doutais pas que mon post provoquerais tant de réaction

Mais en tout cas, ça fait plaisir, surtout tant que ça reste amical.Merci à tous les contributeurs d'avoir apporté leur pierre à l'édifice.

Sur le fond, je suis de l'avis de Henri. La théorie, c'est bien de la connaitre (c'est même le minimum) mais il est des cas où elle provoquera plus de désagrément qu'autre chose (les commerciaux ou la TVA en sont des exemples flagrants)

Concernant l'application, il s'agit d'une petite gestion de devis/facture sans prétention. Dans pas mal de cas, il est évident que stocker l'id et non la valeur provoquera de gros souci.

Encore merci à vous tous,

Excellente journée,

JM

Dans pas mal de cas, il est évident que stocker l'id et non la valeur provoquera de gros souci.

(Désolé mais je suis tétu) c'est plutot l'inverse, dans certains cas, on dénormalisera une solution pour certaines raisons, (on en a lu de très bonnes sur ce poste) mais dans le cas des clés étrangères, je parierais qu'on peut stoker l'id dans plus de 90% des cas.

Petite question: et si tu as deux personnes qui ont le même nom de famille ?
Mais bon, c'est un débat théorique, le principal, c'est que tu ais trouvé une solution à ton problème.

je parierais qu'on peut stoker l'id dans plus de 90% des cas.

Tout à fait d'accord : dans 90% (et même plus) des cas, on utilisera l'id. Il n'a jamais été question de dire qu'on allait supprimer les id, les jointures et les tables liées. Nous parlons d'un cas très particulier.

Petite question: et si tu as deux personnes qui ont le même nom de famille ?

Petite question en retour : comment fait-on dans une entreprise quand deux personnes portent le même nom et le même prénom ? Comment fait la standardiste pour aiguiller les appels ? Est-ce que c'est vraiment un problème majeur ou juste une gêne ? Replace-toi dans le contexte du thread : il s'agit de signatures au bas d'un devis, pas d'un logiciel de paye ou de suivi médical.

Et toujours cette satanée "rentabilité" qui revient à la charge : est-ce que ça vaut la peine de s'emm... et de complexifier l'application pour un hypothétique cas qui n'arrivera probablement jamais ? La réponse peut être oui. Mais elle peut être non. Il faut évaluer les risques et l'impact.

• Anecdote dans le même style : lors de la 1ère version du logiciel de gestion des contacts commerciaux développé il y a presque 15 ans, nous avions une table des entreprises (clients, prospects, ...) et une table des personnes dans ces entreprises. Le client nous a indiqué qu'il y avait des cas (parait-il nombreux) où des personnes pouvaient appartenir à plusieurs entreprises : des consultants, des dirigeants, des multi-cartes, ...
  Nous avons mis en place une structure n-n entre la table PERSONNE et la table ENTREPRISES, donc une table intermédiaire.
  Lors de la refonte complète de l'application 5 ou 6 ans plus tard, on nous a imposé de garder cette fonctionnalité "in-dis-pen-sa-ble". J'ai fait un simple comptage : sur environ 10.000 entreprises et 50.000 personnes de la base, il y avait exactement 7 personnes qui appartenait à 2 entreprises et 1 seule qui appartenait à 3 entreprises. Et sur ces 8 personnes, il y en avait 3 qui s'appelaient du genre "M. Test Bidon". Il a suffit de montrer ce comptage au responsable du client qui tenait les cordons de la bourse, de lui expliquer l'implication technique et financière d'une liaison 0-n à la place d'une liaison n-n pour qu'il soit décidé immédiatement qu'une personne appartenait à une société et une seule. Et pour ces 5 personnes, tant pis, on a créé des enregistrements doublons.

Puisqu'on est dans la théorie, je terminerai juste avec une petite modélisation du mécanisme de modélisation qui montre l'implication que peut avoir le concret sur l'abstrait, la pratique sur la théorie.
On distingue deux mondes :
- le monde réel : celui des papiers, des devis, des commerciaux, des ordinateurs, des programmes informatiques
- le monde abstrait : celui de la conception, de la modélisation des bases, des algorithmes, ...

On distingue deux espaces :
- l'espace du problème : c'est la question qui est posée par le client "je veux un truc qui fasse ça et ça"
- l'espace de la solution : c'est ce qu'on a trouvé pour répondre à la question posée.

On représente ces mondes et ces espaces sous forme d'une matrice avec 4 cases : 1 : le client pose un problème concret : gérer les devis des clients, aller de paris à marseille en 3 heures, ...

1 -> 2 : analyse : on théorise le problème concret en problème abstrait. On effectue un recensement des objets qu'il faudra traiter. On effectue une première modélisation théorique. On décrit les traitements que l'on veut effectuer. On obtient en 2 un document d'analyse ou de spécifications (les terminologies varient) qui décrit le "QUOI ?" : qu'est-ce que qu'on veut faire ? On va d'ailleurs vérifier avec le client que ce qu'on a compris correspond bien à son problème.

2-> 3 : conception : on reste dans le monde abstrait, mais on introduit des contraintes. Aller de Paris à Marseille, certes, mais il y a des problèmes de rayon de courbure des rails, de frottements, de sécurité, ... gérer des devis, oui, mais combien ? 500, 50.000 ? Et cette histoire de nom de commercial, qu'est-ce qu'on en fait ? On effectue une deuxième modélisation, mais pratique cette fois. On décrit les traitements que l'on va effectuer. On obtient en 3 un document de conception ou des plans, .... qui décrit le "COMMENT ?" : comment on va faire ?

3-> 4 : réalisation : on sort du monde abstrait pour revenir dans le monde réel. A partir de la conception, on fabrique des locomotives, des rails, ... on produit du code informatique, on dessine des écrans, des formulaires, on programme des états d'impression. Au final, on a en 4 un produit qu'on livre au client.

4-> 1 : vérification : l'étape trop souvent oubliée : on vérifie que le produit fabriqué correspond au besoin exprimé. Il y a parfois des suprises.

Bouclage : la mise en place du produit va influer sur le besoin du client. Après quelques temps d'utilisation, il voudra gérer plus de clients, gérer des versions de devis, aller de Paris à Marseille en 2h30. On est donc reparti pour un tour ...

Petite question en retour : comment fait-on dans une entreprise quand deux personnes portent le même nom et le même prénom ? Comment fait la standardiste pour aiguiller les appels ? Est-ce que c'est vraiment un problème majeur ou juste une gêne ? Replace-toi dans le contexte du thread : il s'agit de signatures au bas d'un devis, pas d'un logiciel de paye ou de suivi médical.

La standardiste propose une solution de rechange pour préciser et savoir de quelle personne il s'agit. C'est ce comportement qu'il nous appartient à nous, développeur, de pouvoir reproduire.

Imagine si la standardiste trouve les 2 personnes et qu'elle te dit "Erreur de fonctionnement" et qu'elle te recroche au nez. Tu pourras expliquer que ce n'est qu'un cas sur tant

Sur l'histoire des probabilités, d'un point de vue personnel, je pense que 1 chance sur 1 000 000 000, c'est toujours une chance que ça arrive. Donc je prévoit en conséquence. De plus, dans l'expérience que tu parles, ce n'était pas utilisé, certes, mais çà aurait pu être l'inverse. Et tu aurais bien été content de ne pas devoir modifier la modélisation de la base et le code associé.

Maintenant, la refonte, c'est une nouvelle modélisation à partir des enseignements obtenues par le fonctionnement de l'application, tu ne peut donc en tirer des conséquences sur la totalité des fonctionnalités

J'ai du mal à comprendre où est le problème d'avoir une n à n même si elle est peu utilisée, c'est moins pénalisant que de faires des jointures sur des chaines de caractère, et de loin.

Quand aux expériences vécues, conseil reçu du responsable IT d'une compagnie aérienne où j'avais réalisé un travail de re-modélisation :
"A la conception, faites le maximum pour faire quelque chose de robuste, et qui soit normalisé, pendant la durée de vie de l'application, on va pas arrêter de la dénormalisé, donc vaut mieux partir de quelque chose de propre qu'on pourra charcuter par après"

Un des principes de bases, c'est de partir d'un projet de solution normalisé, et d'ensuite commencer à envisager de prendre certaines libertés avec la normalisation et la théorie.

Imagine si la standardiste trouve les 2 personnes et qu'elle te dit "Erreur de fonctionnement" et qu'elle te recroche au nez. Tu pourras expliquer que ce n'est qu'un cas sur tant [...]De plus, dans l'expérience que tu parles, ce n'était pas utilisé, certes, mais çà aurait pu être l'inverse

Imagine qu'il y a deux personnes. Imagine que ce soit l'inverse. Imagine que ...
On a peut-être deux façons différentes de voir l'informatique. Personnellement, je préfère imaginer les cas qui vont se produire et les traiter à fond plutôt que perdre mon temps à imaginer des cas qui ne se produiront jamais.
[mode coup de gueule on] C'est d'ailleurs un gros défaut de l'informatique et de la technologie en général : gérer l'accessoire et oublier l'essentiel. Tu as un magnétoscope qui te permet de programmer 52 semaines à l'avance, mais pour arriver à enregistrer l'émission qui démarre dans 15 secondes, il te faut appuyer sur 5 touches ! Tu as des browsers qui permettent de modifier la page Internet consultée mais qui sont incapables d'imprimer correctement une page qu'ils présentent pourtant parfaitement à l'écran ! [mode coup de gueule off]

Sur l'histoire des probabilités, d'un point de vue personnel, je pense que 1 chance sur 1 000 000 000, c'est toujours une chance que ça arrive. Donc je prévoit en conséquence.

Moi non. Je me pose la question de savoir si c'est utile ou pas, rentable ou pas, dangereux ou pas, important ou pas. Je fais de l'informatique pour gagner ma vie et donc je fais de l'analyse de risque et de rentabilité. Il y a des impasses qui sont faites volontairement et le plus souvent avec l'accord des clients. Ils sont, en général, assez peu enclin à payer pour que je développe quelque chose qui pourra éventuellement servir si un jour, malheureusement les dieux sont défavorables, ...

C'est le syndrome du 80-20 : dans une application informatique, 80% du temps de développement sert à gérer 20% des cas. Là, ce n'est plus du 80-20, c'est du 9999-1 !

Cependant, il est certain que l'analyse du risque sera différente si c'est un programme de suivi de soins médicaux ou un programme de gestion des cartes de fidélité de la boulangerie du coin.

J'ai du mal à comprendre où est le problème d'avoir une n à n même si elle est peu utilisée, c'est moins pénalisant que de faires des jointures sur des chaines de caractère, et de loin.

Mais qui parle de faire des jointures sur des chaînes de caractères ? Il n'en a jamais été question.
Reprend les posts : on se posait la question de savoir si la signature au bas d'un devis, est-ce qu'elle doit être faite avec une jointure sur la table des commerciaux ou si on devait inclure le nom et le prénom du commercial dans le devis. Mais il n'a jamais été question de se servir de ce champ comme d'une jointure.
A la limite, on place un index dessus pour les quelques fois où il y aura une recherche sur cette signature (ça ne mange pas de pain), mais pas plus.

Un des principes de bases, c'est de partir d'un projet de solution normalisé, et d'ensuite commencer à envisager de prendre certaines libertés avec la normalisation et la théorie.

C'est exactement ce que je dis. On n'applique pas bêtement la théorie et quand on viole les règles, on sait où on le fait, quand on le fait et pourquoi on le fait. Et en plus, on documente pour expliquer tout ça.

Personnellement, je préfère imaginer les cas qui vont se produire et les traiter à fond plutôt que perdre mon temps à imaginer des cas qui ne se produiront jamais.

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.

C'est le role d'un bon analyste programmeur que de bien conseiller le client.
Et pas uniquement en lui expliquant quelle solution sera la plus simple et la plus rapide à mettre en oeuvre, un décideur en entreprise voit avant tout l'aspect financier et pas les risques de bug ou de problèmes futurs.
C'est à l'analyste de lui expliqué pourquoi une solution n'est pas bonne et les raisons des surcouts qui doivent être jugé comme nécessaire.

Henri : quand tu préconise de mettre le nom du commercial dans la table client et non son id unique, lorsqu'on voudra lister les clients d'un commercial, c'est bien une jointure sur chaine de caractères qui va arriver, non ?

C'est le role d'un bon analyste programmeur que de bien conseiller le client.
Et pas uniquement en lui expliquant quelle solution sera la plus simple et la plus rapide à mettre en oeuvre, un décideur en entreprise voit avant tout l'aspect financier et pas les risques de bug ou de problèmes futurs.

Tout à fait d'accord. Mais c'est aussi son rôle de ne pas lui vendre des trucs inutiles comme cela arrive trop souvent. C'est pour ça que je dis que je ne ferais pas la même chose pour un logiciel médical que pour un logiciel de cartes de fidélité.

Henri : quand tu préconise de mettre le nom du commercial dans la table client et non son id unique, lorsqu'on voudra lister les clients d'un commercial, c'est bien une jointure sur chaine de caractères qui va arriver, non ?

Euh non. Qu'est-ce que tu entends par jointure ? Quand tu fais il n'y a pas de jointure. Et lorsque tu fais il n'y a pas de jointure non plus.
Explique nous ce que tu veux dire, ce n'est pas très clair.


Reprend les posts plus haut, en particulier mon explication sur la différence entre fonction commerciale et nom du commercial, ce que l'on stocke dans la table client, ce que l'on stocke dans la table devis, je ne vais pas recommencer toute l'explication. Mais en gros, dans ce cas et dans ce cas seulement, la recherche sur un nom sur un devis est une fonctionnalité suffisamment inintéressante pour ne pas mériter tout ce tintamarre.

Tout à fait d'accord. Mais c'est aussi son rôle de ne pas lui vendre des trucs inutiles comme cela arrive trop souvent. C'est pour ça que je dis que je ne ferais pas la même chose pour un logiciel médical que pour un logiciel de cartes de fidélité.

Qu'un programme soit vital ou non, il doit avoir une certaine robustesse et une certaine adaptabilité. je doute qu'un client soit d'accord de prendre des risques, même avec un système de carte de fidélité. Faut pas oublier que faire des économies de conceptions, ça ne sert à rien si par après on doit démonter toute l'application pour corriger une erreur imprévue, ou bien ajouter une fonctionnalité

Euh non. Qu'est-ce que tu entends par jointure ? Quand tu fais

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.

Dévelloper un système c'est aussi anticiper un peu ce qu'on devra réaliser un peu plus tard, et donc

Ensuite dans les exemples que tu as proposé, même si il n'y a pas de jointure une clause where sur des valeurs numériques sera toujours plus rapide que sur des chaines de caractères.

dans ce cas seulement, la recherche sur un nom sur un devis est une fonctionnalité suffisamment inintéressante pour ne pas mériter tout ce tintamarre.

N'ayant pas tous le cahier de charge de l'application sous la main, je ne me base pas sur ce genre d'hypothèses.