Bonjour,
 
Je m'explique...
 
j'ai plusieurs tables dans les-quelles il y a une adresse avec rue, ville, cp, pays. (tables clients, employés, fournisseurs)
 
et dans les 3 tables j'ai donc chaque fois un champ rue, ville, cp, pays.
 
Est-il vraiment necessaire de faire 4 tables supplementaires, (table rue, table pays, table ville, table cp) ?
 
Plus de redondance de données certe... mais perte de performance non?
 
Je travaille sur mon mémoire, est-ce que selon vous c'est vraiment utile?
 
merci d'avance.

non, je pense pas
Déjà, je ne suis pas sur qu'il y ait réellement une grande redondance.

ca dépend surtout de l'utilisation que tu veux faire de la DB...

Ben il s'agit de la gestion d'une salle de sport, donc va pas y avoir des millions d'inscrits...
 

Donc t'embêtes pas à faire 3 ou 4 tables pour des infos qui ne sont pas le "coeur" de ton application

rien à voir. ce que je veux savoir c'est les infos que tu veux tirer de la db, et comment.

 
ben il est possible que je veuille lister tous les membres d'une ville donnée par exemple, mais cela reste possible sans faire une table villes...

dans ce cas, sépare les villes.

 
D'acc, mais alors faut que je fasse de meme pour pays, rue, cp...

non, sauf si tu envisages de permettre la prospection par pays, commune, rue, etc...

ben ca serait des ptites options en plus mais rien d'important et comme j'ai dit ca reste faisable sans separer tout ca en 4 table... (evidement si faute de frappe ca passera pas)

fais une table lieu  

sincèerment je pense que tu devrait meiux orgainiser tes adresses aussi parceque meme si tu dis qu'il n'y a ura pas bcp d'inscrit ou que c'est pas importt tu risuqe a un moment donné de regretter toute cette redondance
et sincèrement si tu separe en pliens de tables  cp , ville etc.. je suis pas sur que tu perdes bcp en performances mais au moin ta BdD sera développé corrcetement et prete a recevoir bcp de données  ;o)

OK merci pour vos conseils,
 
j'ai demandé a ma prof tout a l'heure, elle m'a dit qu'en general on fait une table pays, CP et ville. Pour la rue, c pas vraiment necessaire.
 
A+ merci

Comme cela a été déjà dit, je pense que ces infos adresses ne sont pas au coeur de ton application.
 
Si tu comptes mettre en place une véritable gestion d'adresse avec restructuration, normalisation et validation postale, alors le problème se posera à toi.
Mais pour une gestion de salle de sport, cela n'est pas nécessaire.
 
Je te conseille de laisser les champs d'adresse tels quels dans les tables clients, fournisseurs, etc.
Tu peux éventuellement codifier les pays dans une table à part.
Mais le couple CP/ville est très lié. Si tu fais des tables séparées pour ces 2 données, tu t'obliges à avoir des tables de référence à jour, et à te tenir informé des modifications de ces tables. De plus, séparer le CP de la ville n'empêchera pas les incohérences du style 75001/marseille dans tes adresses.
 
Fait simple, et prévois juste des champs correctement taillés pour tes champs d'adresses (la norme postale en vigueur pour info: CP: 5 caractères, ville: 32 caractères, les autres volets de l'adresse sur 38 car.)

Slt agagax, merci pour tes conseils, je pense cela aussi, mais la prof a l'air de tendre pour l'autre solution a savoir pays et ville dans une table a part...  
 
Sinon pour CP 5 caracteres c bizzare vu qu'au canada le CP en fait 6 ?
 
a+

Effectivement j'ai mentionné la norme postale française dont le CP est sur 5 caractères, l'adresse contenant 6 volets de 38 car.
 
Il faut te renseigner sur la norme canadienne en matière de normalisation d'adresse, qui est différente puisque tu dis que le CP est sur 6 caractères.
 
Lors de la création d'un modèle de données, il faut se poser la question de l'usage et l'intérêt des tables que l'on crée. La modèlisation conceptuelle est fait normalement pour cela. Ensuite on passe au modèle physique où des optimisations se feront en fonction de la bdd choisie, avec son lot de dénormalisations.
Donc si tu crées une table de villes, c'est dans un but précis et non pour agrémenter un modèle.
Pour ton sujet, je pense que cela peut servir pour validation ou vérification d'une ville, soit directement à travers des formulaires de saisie d'adresse, soit après enregistrement, pour valider une adresse.
 
Bien sûr je suis conscient qu'il s'agit là d'un exercice, dont l'objectif est plus pédagogique que de coller absolument avec la réalité.
 
Bon courage dans tes études.

Ben justement cela doit coller avec la realité vu que c'est mon sujet de memoire
Enfin merci pour tes conseils a+

Premier conseil :
 
Au lieu de stocker les adresses dans chacune des tables, crée une table "adr", qui va avoir pour structure :
 
typtie char(3) ('CLI', 'FOU', 'EMP')
sigtie numeric (foreign key vers tes 3 autres tables, évidement, la clé ne sera pas codée dans la base)
rue
ville
cp
...
 
Second conseil : je pense que tes trois tables client, employé et fournisseur doivent avoir une structure similaire. Il est donc débile de les séparer. Crée donc une table "tie" (pour tier) avec la structure suivante :
 
typtie
sigtie
nom
prenom
...
 
En plus, à ce moment, tu pourras indiquer explicitement les clés étrangères entre adr et tie.
 
PS: ce système est utilisé dans l'ERP GENERIX. Il est tout à fait performant. Cet ERP, comme tout ERP digne de ce nom utilise évidement un modèle bien plus complexe (notamment avec possibilité d'avoir plusieurs adresses de différents types pour les différents tiers, ainsi qu'une gestion des alias d'adresses, permettant d'avoir par exemples les adresses de livraison, facturation et livraison pointant sur la même ligne de la base. Mais bon, là ça devient plus complexe, et ça ne réponds pas à tes besoins).
 
Question maintenant :
C'est quoi ta formation ? Quel niveau ? Parceque tu me fait un peu peur de te poser des questions pareilles

je pense personnellement que c'est un très mauvais conseil
il suffit de voir le problème lors de l'inscription. imagine une application qui gère des clients dans tout un département... je me vois pas chercher ma ville dans la liste des 800 communes de mon département.
en plus, pour les villes comme paris, lyon ou marseille, qui ont des arrondissements, on sait pas trop si on doit séparer les arrondissements ou nons (des fois _a sert, des fois ça sert pas...)
donc autant laisser le champs libre, et compter sur la propreté des utilisateurs pour pas saisir n'importe quoi.

elle a bouffé quoi ta prof
 
j'ai jamais vu ça dans un système de gestion moi !
à la limite, une table de référence pour les pays. généralement ça s'arrête la.

hein?! mais qui te parle d'une inscription avec une liste?
Et puis c'est quoi cette blague de laisser le soin à l'utilisateur de remplir bien ses champs?! Et cet identifiant en string que tu lui fous? T'es pas bien?!

Une table cp+ville+code_pays permet de verifier la validité de la saisie.
 
Pour la France, çà ne représente que 36000 enregs (de ville).
 
En fait, y'a beaucoups plus de CP que çà à cause des CEDEX, etc
En plus le même CP peut être utilisé pour plusieurs localités...
 
Pour la france, une table des CP n'est pas trop difficile à trouver, mais pour les autres pays, çà devient plus compliqué...

1) si tu veux que l'utilisateur puisse pas saisir n'importe quoi, t'es obligé de lui proposer une liste de valeurs. a ce moment, non seulement la recherche dans la liste est chiante, mais en plus, si sa ville n'existe pas, c'est le bordel.
2) bah si tu veux pas faire de liste, trouve-moi une autre solution, je suis preneur. de toute façon, une adresse ne demande pas une propreté exemplaire, faut juste que l'utilisateur remplisse les bons champs de la bonne façon, pour le reste, tu t'en fou.
3) tu sais ce que c'est qu'un index ? un char(3), c'est 3 octets, c'est à dire bien plus petit qu'un numeric. donc non seulement c'est plus rapide, mais en plus avec l'index de toute façon tu fais abstraction complète du type, un index ne bosse pas en interne avec des chaînes, révise tes cours de sgbd. deplus, mon identifiant est le couple sigtie et typtie, typtie étant uniquement un code, permettant de différencier le type du tiers, ce qui implique une liste de valeurs très réduite. pour info, GENERIX toujours, utilise un varchar12 pour le sigtie, et niveau perfs, y'a rien à redire. à nouveau, révise ce que c'est qu'un index, surtout un PK, qui est systématiquement clustered. y'aura pas la moindre différence de perf entre un nombre ou une chaîne.
4) oui, je vais bien.

pour une application gérographique, il y a peut-être un intérêt. pour gérer une registre d'inscrits, je vois vraiment pas le moindre intérêt si ce n'est complexifier la base, et faire chier l'utilisateur quand il entre les infos.
 
quand un village comme celui chez ma grand-mère est orthographié différenement selon la SNCF, France Telecom, le DDE ou La Poste, tu peux y passer un bout de temps avant de réussir à saisir la bonne orthographe.
 
Pour information, ce village s'appelle Venarey-Les Laumes (orthographe DDE)
France Télécom l'appelle Vernarey-Les-Laumes, tandis que la Poste l'orthographie Venarey Les Laumes. La SNCF quant-à elle fait un amalgamme avec le village voisin, ça devient "Les Laumes Alésia". (vous pouvez vérifier)
Je ne vous parle pas de la réductions "Les Laumes" utilisée par les otoctaunes.
A savoir qu'un village voisin s'appelle quant à lui "Venarey" d'après la DDE, mais pour éviter la confusion avec "Les Laumes" qui est plus grand, on l'appelle "Le vieux Venarey".
 
Alors si vous voulez emmerder les utilisateurs pendant 3 plombes pour saisir une adresse, c'est la bonne solution que de faire une table de référence avec la liste des villes. Mais très franchement, j'en voit pas l'intérêt.
Je vais même vous en rajouter une couche : Dans "Le vieux Venarey", il y a un lieu-dit "La croix bleue". Sâchant que la rue qui y passe passe aussi dans le village lui-même, et que les numéros de boîte postales sont réinisialisés, il y a des doublons avec les numéros du village. Pourtant, ce n'est qu'un lieu-dit, ce n'est pas un hameau. Donc aucune base vous l'indiquera. Le facteur aura donc intérêt à connaître qui habite où lors de la distribution du courrier, car vos adresses seront pas complètes.
 
M'enfin ce que j'en dit...

Pof : Maporama, pourtant une application de géographie, avec donc une base d'extrêment qualité et précision ne connait pas "Venarey".
 
http://www.maporama.com/share/map. [...] DRESS.y=12
 
Alors je fais comment pour m'y rendre ?
Je peux vous jurer que si vous envoyez un courier aux Laumes au lieu du vieux Venarey, il n'arrivera jamais.
 
Il est même complètement absent de la carte. (c'est la tâche grise qui est en dessous de "Venarey-Les Laumes"
 
http://www.maporama.com/share/Map. [...] 6E89AD748}
 
LOL, sur Mapy c'est carrément "Laumes (les)", ce qui n'a rien à voir avec le véritable nom de la commune, puisque le nom original est Venarey, "Laumes" voulant dire "Marais" dans le patois régional...

1) quand t'as une liste de 36000 communes, tu vas pouvoir attendre quelques minutes avant que l'autocomple se charge. ensuite, faudra espérer que ça va pas faire planter le PC. deplus, si tu ajoute à la volée les données saisies, tu va polluer ta base de la même façon. si "Venarey-Les Laumes" est présent dans la base, et que tu tapes "Les Laumes", tu va faire un doublon sans inquéter le moins du monde ton système, qui ne sert donc rigoureusement à rien.
2) un salle de sport ne fait pas ses démarches marketing elle-même (y'a d'ailleurs pas beaucoup d'entreprises qui se basent sur leur fichier client pour faire venir de nouveaux clients... m'enfin ce que j'en dis...) Deplus, y'a un truc qui s'appelle l'INSEE qui fournis des fichiers propres, et légèrement plus ciblés (je vois pas trop l'intérêt de démarcher un octogénère parcequ'il s'est inscrit il y a 5 ans pour des exercices de rééducation suite à un accident...)
3) 16 bits ? tu rigoles ? pour un ID ? biensûr... et quand t'as plus de 65000 lignes tu fais comment ? de toute façon, dans ce cas, précis, il n'y a en que 3 choix possibles donc pour ce qui est de la pollution de la base, j'attends de voir tes arguments... (TYPTIE POUR TYPE DE TIERS ! FAUT QUE JE TE LE DISE EN QUELLE LANGUE ? T'EN A PAS 150 QUE JE SACHE...) Deplus, j'ai indiqué CHAR(3) c'est pas un varchar. Arrête de me contredire pour le plaisir. 1, 2, 3 c'est cool, sauf que quand tu écris une requête tu sais pas ce que c'est. 'FOU' pour fournisseur, 'CLI' pour client, et 'EMP' pour employé, c'est quand même autrement plus explicite, et comparé à un int32, c'est à la fois plus petit et plus performant. Evidement, tu peux utiliser un tinyint, mais de toute façon ça changera rien pour 3 valeurs énuméres.
4)

le champ typtie est mambre de la PK, et fait partie de l'index primaire unique. mysql gère peut-être pas ça (j'en doute) mais n'importe quel sgbd le gère très bien. utiliser un int pour ça me fait bondir pour la bonne raison que ça nécessite d'avoir en permanance en mémoire les codes quand on code. alors qu'un champ de 3 caractères est à la fois plus explicite et ne gène en rien au niveau des performances (puisque membre de l'index primaire unique). Mettre 'F', 'C', 'E' à la place revient en effect à peut près au même, à la différence près que ça peut être confondu aisément avec un autre champ, le status par exemple 'C' pour Cancel, 'E' pour Error et 'F' pour Finished par exemple. Ca nuit donc à la lecture, alors qu'avec 3 caractères y'a 1000 fois moins de risques.
Je t'en remet aux codes ISO qui sont très souvent utilisés comme identifiant dans une base. Il sont généralement de 2 ou 3 caractères, et sont utilisés tels quel directement, car permettent d'être lisibles sans devoir chercher dans la table de correspondance. Dans une adresse, c'est quand même plus aisié de lire "FR" pour "FRance", que "F" qui peut être compris comme "France" ou "Finlande".
Pour ce qui est du Varchar dans generix, oui, c'est moi qui en ai parlé, mais :
1) dans la strucure des tables que j'ai indiqué, j'utilise un char(3) et un numeric. Pas de varchar. Sinon, j'ai parlé du Varchar, car par expérience, même in ID en varchar(12) est amplement suffisament performant pour obtenir de bonnes performances, dont les différences seront quasiement invisibles par rapport à un champ numérique. Mais je n'ai jamais dit de faire pareil, surtout que pour des client, ça sert à rien. Pour des produits ça a un sens, parceque tu as déjà un identifiant unique, le code catalogue, qui est généralement alphanumérique. Afin d'éviter de se compliquer la vie, il vaut mieu le reprendre plutôt que d'utiliser un code interne. Mais dans ce cas on s'en fout.
L'utilisateur en fait en effet pas la requête. Seulement, une appli, avant d'être utilisée, faut la développer. Et se simplifier la vie pour gagner du temps, sans porter préjudice à l'utilisateur final est le premier boulot de l'analyste. Donc les codes numériques à la con qui nécessitent 25 jointures pour partir du code qui sera tapé par l'utilisateurs, ça s'appelle du masochisme.
Deplus, quand l'appli aura 2 ans et que le client voudra mettre à jour son système, faut penser au petit stagiaire qui va se pallucher le code. Il sera content de pouvoir se baser sur des données lisibles. Je ne parle même pas d'éventuel interfaçage avec une appli externe, qui ne connaît pas les codes internes à l'appli, et donc sera incapable de mapper 1, 2, 3. Des strings seront un peu plus aisées à interpréter.

Bonsoir tlm,
 
Oulala je vois que ca a chauffé dans mon post !
Bon j'ai lu vos reponses, j'pense qu'y'a du vrai des deux coté, en fait tout depend de ce qu'on veut exactement. Mais arretez de vous dechirer svp
 
Moi de mon coté je ne compte pas "pre-enregistrer" les villes, etc...
 
Je pense que cela se fera lors de l'encodage du client.  
Si la ville existe pas encore on l'ajoute, et ca s'arrete la. Idem pour CP et pays.
 
De plus pour le fait que le client entre n'importe quoi, ca n'arrivera pas car generalement c un employer qui se charge de l'encodage. Entk j'ai jamais vu une salle de sport ou c le client qui fait ca lui meme... tous ce qu'il fait c dicter ses coordonnée ou donner sa carte d'identitée au comptoir. Alors bon a moins que le mec du comptoir a but 5 bieres, il prendra quand meme soint de pas taper des conneries
¨
Sinon pour le code postal et la ville :  
 
En belgique (suis belge ), il y a des ville (bruxelles, liege, Namur etc...) et ces ville sont divisee en communes. Chez vous les communes ca equivaux aux arrondissement, chef-leux, etc... Et chaque communes a donc son propres code postal. Et le nom de la commune on s'en fout c'est pas obligatoire dans l'adresse. Le CP suffit!
 
Donc en fait le plus chiant ca sera les premiers client, il faudra ajouter chaque fois les ville et CP qui n'existent pas, mais apres qques client, ca sera souvent les meme villes et CP qui sortiront... les gens viennent pas du bout du monde non plus pour pratiquer un sport
 
Voila, voila... merci magicBuzz et gizmo!
 
 

Conclusion, si tu as une bonne table des CP valides, quand l'utilisateur le saisie, tu peux vérifier tout de suite s'il est bon, et remplir automatiquement la ville/commune, ou proposer une liste si y'a plusieurs communes avec le même CP...
Exemple :

C'est le genre de détail qui facilite la vie des utilisateurs.
 
Pour le reste tu peux très bien garder tes champs d'adresses dans tes tables clients, employés ou fournisseurs (ou tu ne fais qu'une seule table avec un type_tiers...). La redondance est permise si çà évite de faire des requêtes qui accèdent à plein de table genre :
tiers, adresse, ville, cp, pays ( plus les tables de liaison )
A+
 
J'ai trouvé çà : http://www.charline.be/info/codepost/cpost.htm
2ème lien dans google "codes postaux belgique"