Discussion :

[DeRozan31]

Bonjour à tous,

Je travail en ce moment sur une application et j'ai une étape d'ajout de client avec pas mal d'informations et notamment l'adresse (adresse, code postal et ville).
Pour être précis j'ai conçu une première version de cette application mais ce n'était pas optimisé du coup dans ma table "clients" j'avais un champ "adresse", "code_postal" et "ville" à chaque fois avec des doublons.

Du coup je suis parti sur ma table "clients" avec une table "adresse" à part qui me permet de stocker les différentes adresses. Est-ce une bonne chose de procéder ainsi ?
Par ailleurs j'aimerais éviter les doublons, est-ce bien de faire une requête qui va vérifier si l'adresse, le code postal et la ville existe déjà ? Ou existe-il une manière plus simple ?

Je me disais aussi que c'est bien de vérifier l'adresse pour éviter les doublons mais qu'en cas d'écriture du genre "place de l'hôtel de ville" j'aurais une adresse doublon avec "place de l'hotel de ville" ou encore "PLACE DE L'HOTEL DE VILLE".

Du coup avez-vous des conseils pour faire quelque chose de ce genre ?

Merci d'avance

[Merguezman]

Bonjour,

je ne vois pas vraiment en quoi c'est un problème de stocker l'adresse (donc numéro de rue et nom de rue ?), le CP et la ville dans la table client ?
Tu as des doublons, bah effectivement 2 clients peuvent venir de la même ville, voir de la même rue.

Là ce que tu fais si je comprends bien ta 2ème table, tu enregistres dedans l'adresse du client, et tu joint le client de ta table client avec son adresse dans ta table adresse ?
Puis quand un nouveau client va être enregistré, tu regardes si son adresse existe déjà :

• si oui, tu lies le nouveau client a l'enregistrement déjà existant dans la table adresse ?
• si non, tu crées la nouvelle adresse ?

[al1_24]

Ou faut-il comprendre qu'un client peut avoir plusieurs adresses ?

[aieeeuuuuu]

bonjour,

je ne vois pas vraiment en quoi c'est un problème de stocker l'adresse (donc numéro de rue et nom de rue ?), le CP et la ville dans la table client ?

Cela contrevient à la troisième forme normale, puisque le CP dépend fonctionnellement de la ville.
Le risque est de se retrouver au mieux avec des répétitions (plusieurs fois le même couple CP/Ville comme indiqué), au pire à des incohérences (plusieurs fois la même ville avec des CP différents).
Cela engendrera également des problèmes de concurrences lors des mises à jour.

[Merguezman]

Le risque est de se retrouver au mieux avec des répétitions (plusieurs fois le même couple CP/Ville comme indiqué), au pire à des incohérences (plusieurs fois la même ville avec des CP différents).
Cela engendrera également des problèmes de concurrences lors des mises à jour.

Pour la répétition de couple CP/ville, oui de ce fait il y en aura forcément si des clients viennent de la même ville, mais bon faire une table à côté avec tout les couples CP/ville de France c'est un peu lourd.
Mais bon à la limite en séparant dans une table CP et Ville et lié ça à l'utilisateur, mais laisser l'adresse(nom de rue) dans la table client. Mais là pareil, des rues portant le même nom dans différentes villes, il y en a plein.

Et de toute façon, en laissant l'utilisateur rentrer les infos, il y a toujours un risque d'incohérences (comme tu le dis avec une ville et plusieurs CP). Donc après, voir pour un outils qui permet de contrôler les couples. Il y a un soft qui s'appelle codepostal et qui permet cette vérification.

[al1_24]

Pour information, une ville peut avoir plusieurs codes postaux et un code postal peut être associé à plusieurs communes.

[Merguezman]

Pour information, une ville peut avoir plusieurs codes postaux et un code postal peut être associé à plusieurs communes.

Ah bah oui, ça m'étais sorti de la tête cette histoire

[Artemus24]

Salut merguezman.

je ne vois pas vraiment en quoi c'est un problème de stocker l'adresse (donc numéro de rue et nom de rue ?), le CP et la ville dans la table client ?

Raisonnement stupide car vous partez de l'hypothèse que le client en question n'a qu'une seule adresse.

Ou faut-il comprendre qu'un client peut avoir plusieurs adresses ?

C'est ce que j'ai compris.
Et plus précisemment, DeRozan31 doit gérer différentes adresses pour différents usages. Par exemple, définir :
--> l'adresse domicile.
--> l'adresse travail.
--> l'adresse fiscal.
--> l'adresse résidence secondaire.

Il y a autant d'adresses à définir qu'il y a de particularités chez un client.

Mais bon à la limite en séparant dans une table CP et Ville et lié ça à l'utilisateur, mais laisser l'adresse(nom de rue) dans la table client. Mais là pareil, des rues portant le même nom dans différentes villes, il y en a plein.

Votre entité de base est l'adresse ! Et cette adresse forme un tout, à savoir :
--> nom du client
--> prénom du client
--> numéro du chemin/rue/avenue/boulevard
--> le type de chemin/rue/avenue/boulevard
--> le libelle de l'adresse exacte sur plusieurs lignes. En effet, sur une enveloppe, la largeur de ce que vous devez mettre n'est pas infinie. Vous devez tenir compte de cette particularité.
--> code postal
--> nom de la ville

Mais aussi tenir compte :
--> des particularités de chaque pays où sont destinés le courrier que vous allez envoyez.
--> de spécifier la liste des adresses en fonction du type de courrier : fiscal / publicitaire / ...
--> et surtout de gérer l'adresse par défaut afin de ne pas créer des doublons. Par exemple, si adresse domicile et fiscale sont les mêmes, ne pas les définir sous ce type mais la définir sous le type "défaut".

comme tu le dis avec une ville et plusieurs CP

Ce n'est pas une incohérence, on nomme cela un arrondissement !
Voire pire, un secteur où l'on fait la distinction entre le particulier et l'entreprise.

L'organisation de votre table des adresses doit dépendre de ce que vous cherchez à faire.
Le point d'entrée de cette table sera l'identifiant client !

@+

[SQLpro]

Bonjour,

je ne vois pas vraiment en quoi c'est un problème de stocker l'adresse (donc numéro de rue et nom de rue ?), le CP et la ville dans la table client ?

Raisonnement doublement stupide car pour ceux qui n'ont pas d'adresse vous commettez deux énormités :
1) réserver des octets pour rien (dans le principe l'Algèbre Relationnelle d'où sont tirés les SGBD Relationnels interdit l'absence de valeur...)
2) alourdir toute les requêtes qui ne portent que sur la partie "personne" de cette table du fait que pour extraire ne serait même qu'une seule information, le SGBDR, sauf exception (index couvrant) va lire l'intégrabilité de la ligne pour ne ramener que les informations utile à la requête !

Et comme on vous l'a dit, pour ceux qui ont plusieurs adresse...

A +

[SQLpro]

Votre entité de base est l'adresse ! Et cette adresse forme un tout, à savoir :
--> nom du client
--> prénom du client
--> numéro du chemin/rue/avenue/boulevard
--> le type de chemin/rue/avenue/boulevard
--> le libelle de l'adresse exacte sur plusieurs lignes. En effet, sur une enveloppe, la largeur de ce que vous devez mettre n'est pas infinie. Vous devez tenir compte de cette particularité.
--> code postal
--> nom de la ville

D'un point de vue modalisation que ce vous proposez Artemus viole allégrement les formes normale notamment en cas de client sans adresse comme en cas de pluralité d'adresse d'un même cluent. Les informations de cleint et d'adresse doivent être deux entités séparées.

Mais aussi tenir compte :
--> des particularités de chaque pays où sont destinés le courrier que vous allez envoyez.

Mettez vous à la page, les adresses sont normalisées sur la plan européen depuis 20 ans et sur le plan internationale depuis plus de 10 ans http://www.upu.int/fr/activites/adre...norme-s42.html

--> de spécifier la liste des adresses en fonction du type de courrier : fiscal / publicitaire / ...
--> et surtout de gérer l'adresse par défaut afin de ne pas créer des doublons. Par exemple, si adresse domicile et fiscale sont les mêmes, ne pas les définir sous ce type mais la définir sous le type "défaut".
Ce n'est pas une incohérence, on nomme cela un arrondissement !
Voire pire, un secteur où l'on fait la distinction entre le particulier et l'entreprise.

L'organisation de votre table des adresses doit dépendre de ce que vous cherchez à faire.

Là aussi c'est une grave erreur. Il faut chercher à modéliser les informations pour ce qu'elle sont à l'état naturel et non chercher à coller à un quelconque traitement...
Si vous faites ce que vous dite, vous n'aurez pas une base capable d'évoluer en fonction des évolutions légales ou fonctionnelles. Or les données sont très inertielles contrairement aux traitements qui peuvent évoluer sans cesse.

A +

[Artemus24]

Salut SQLPRO.

Admettons que pour un client donné, il a deux adresses :
1) à son domicile.
--> M. Albert Dupont
--> 15, boulevard des capucines
--> 75005 Paris

2) et une autre adresse, celle de ses parents :
--> M. et Mme François Dupont
--> 64 allée des peupliers
--> 33000 Bordeaux

Comment allez-vous structurer votre table pour faire en sorte que ce client puisse avoir ces deux adresses libellées ainsi ?
Sachant que ce monsieur est six mois à Paris et six mois à Bordeaux ?

@+

[SQLpro]

Ce sont deux personnes différentes et deux adresses différentes, je ne voit pas le problème !

Dans ce cas particulier on met :
--> M. Albert Dupont c/o M. et Mme François Dupont
--> 64 allée des peupliers
--> 33000 Bordeaux
et dans le modèle cela se traduit par un lien entre personnes/adresses (trois pattes à l'association).

A +

[Artemus24]

Salut SQLPRO.

Ce sont deux personnes différentes et deux adresses différentes, je ne voit pas le problème !

Ce ne sont pas deux personnes différentes, mais la même personne, avec deux adresses différentes.
Et comme je le disais précédemment, l'une des adresses concerne son domicile personnel et l'autre, l'adresse de ces parents.

Imagines que tes adresse en question concerne des immeubles.
Si je ne précise pas le nom du locataire de l'appartement, comment le courrier va arriver au bonne endroit ?
Oui je sais, on peut aussi préciser l'étage et le numéro de l'appartement.

De plus, les parents de ce monsieur ne sont pas des clients, donc pourquoi créer une fiche client ?

Et ce que je formulais dans mon exemple, c'est de traduire le libellé de l'adresse sous forme de lignes à remplissage libre.
Ce qui fait que la mise en forme de l'adresse est bien indépendant du code postal, du nom de la ville et du nom et prénom du client.

On peut même aller sur la différence entre le nom d'une femme qui continue à se nommer de son nom de jeune fille alors que pour l'adresse elle utilise son nom de femme mariée.

et dans le modèle cela se traduit par un lien entre personnes/adresses (trois pattes à l'association).

Non, il y a l'entité mère qui est le client (ou la personne) et l'entité fille qui est l'adresse.
Et il n'y a pas trois pattes à l'association car une adresse est rattaché à une et une seule personne à la fois.
Par contre, il se peut qu'un client possède plusieurs adresses qu'il faut distinguer les unes des autres selon l'usage que l'on en fait.

@+

[SQLpro]

Salut SQLPRO.

Ce ne sont pas deux personnes différentes, mais la même personne, avec deux adresses différentes.

Désolé de vous le dire aussi crument, mais vous prenez les gens pour des imbéciles !

Vous me dite que :
M. Albert Dupont
est la même personne que
M. et Mme François Dupont

Achetez vous une paire de lunette !

A +

[Artemus24]

Salut SQLPRO.

Encore une fois, vous ne savez pas lire !

Ce ne sont pas deux personnes différentes, mais la même personne, avec deux adresses différentes.

Il n'y a pas deux clients dans cette table des clients, mais un seul client dont le nom est "M. Albert Dupont".
Et ce client possède deux adresses différentes, dont l'une est son domicile à Paris et l'autre chez ses parents à Paris.

Qu'est-ce qui vous dérange tant dans la façon de libeller ces adresses ?

De ne pas voir apparaître ceci : "M. Albert Dupont c/o M. et Mme François Dupont"
Désolé, mais je ne voie pas l'intérêt de surcharger l'adresser ainsi, car le libellé de l'adresse exacte, c'est M. Albert Dupont qui l'a fournit ainsi.
Et ce n'est pas à vous de modifier cette adresse selon votre convenance !

Et en ce qui concerne ma remarque précédente au sujet d'un client qui utilise son nom de jeune fille.
Dans la table, elle est connue sous son nom de jeune fille, tandis que pour le courrier elle met son nom de femme marié.
Allez-vous me dire que ce sont aussi deux personnes ?

@+

[SQLpro]

Qu'est-ce qui vous dérange tant dans la façon de libeller ces adresses ?

De ne pas voir apparaître ceci : "M. Albert Dupont c/o M. et Mme François Dupont"

Et donc de voir quelqu'un ouvrir le courrier d'un autre !!! Même un parent n'a pas le droit d'ouvrir le courrier de son enfant devenu adulte
Bravo pour la confidentialité... mais pire, c'est pénalement condamnable !

Article 226-15 du code pénal : "le fait, commis de mauvaise foi, d'ouvrir, de supprimer, de retarder ou de détourner des correspondances arrivées ou non à destination et adressées à des tiers, ou d'en prendre frauduleusement connaissance". Infraction punissable d'un an d'emprisonnement et de 45 000 euros d'amende...

L'imbécile qui modéliserait les adresses et clients de la façon que vous proposez serait bien évidemment complice de cette infraction !

A +