Bonjours je souhaite enregister une adresse mais j'ai du mal a choisir entre
la solution de tous mettre d'un seul coup

id_adresse|codepostal|commune|region

ou éclater ces données pour éviter des doublon

id_adresse|id_codepostal|id_commune|id_region

avec cette methode, je pense qu'il faudra faire des mini tables de 2 colone pour le codepostal,la commune et la région
niveau preformance lesquels des 2 deux sont plus rapide ?

merci de vos réponses

Salut !

Moi, je te proposerai ceci :

1 table Commune avec comme champ commune et code postal
1 table Région avec comme champ la région (et plusieurs champs comme par exemple, le n°, son abréviation, etc.)

Comme ceci, t'évites de faire des doublons ou des fautes de frappes lorsque tu sélectionnera une commune et une région.

Bien sûr, ces 2 tables devront relié à la table où t'enregistres les personnes avec leur adresse.

Salut, il y a une redondance dans ta façon de procéder car en ayant la commune tu peux facilement avoir la région ;). J'ai déjà eu à implémenter ce genre de truc et j'ai procédé de cette façon :

[personnes]
id

[adresses]
id
num_rue
type_rue
nom_rue
commune_id
personne_id (implique qu'une adresse ne peut appartenir qu'à une personne, à voir avec tes besoins si tu n'as pas besoin d'une relation ManytoMany à la place)

[communes]
id
code_postal (pas forcément unique puisque plusieurs villes peuvent avoir le même CP)
nom
region_id

[region]
id
nom

Tu auras des problèmes de performances quand tu auras le trafic de Twitter et Facebook, sois tranquille pour le moment

merci de ces réponses, je suis effectivement essayer de contruire un base de donnée sur les données d'un client par exemple pour un site de recherche d'emploi par exemple

c'est ce que j'avais aussi penser mettre une table cp/commune et une autre region,

il faut donc essayer de chosir le juste milieu, un peu de doublon ne fera pas de mal , et des table pas trop dispersé ?

pour les entiés si je fait

personnes (id_personne,adresse,id_geo,telephone_f,telelphone_p)
geographie(id_geo,id_cp_comm_,region)
commune(id_commune,cp,commuen)
region(id_region,region)

par contre est t'il nécessaire de scinder entre l'adresse et la personne ?

Citation : keo

il faut donc essayer de chosir le juste milieu, un peu de doublon ne fera pas de mal , et des table pas trop dispersé ?

Si tu pars du principe que des conventions de conception de base de données ne servent à rien, oui si tu veux

Quel est l'intérêt de ta table geographie ?
Attention aussi à ne pas confondre les notions table et entité...

je me suis trompé sur ce coup

si je fait comme ceci:

table commune
id_commune|commune|departement|cp

table departement
id_departement|num_dep|nom_dep

et la table region

id_reg|nom_region

ensuite dans ma table persone je met ces 3 id

id_perso|nom|prenom|adressse|tel_fixe|tel_portable|courrielid_commune|id_departement|idregsion|

ses table sont t'il correcte

Non, tu as toujours des redondances étant donné qu'une ville est liée à un département qui lui-même est lié à une région...

Tables:
personnes : personne_id, tel_fixe, tel_portable, courriel
adresses : adresse_id, personne_id, numero_rue, type_rue, nom_rue, commune_id
communes : commune_id, code_postal, nom, departement_id
departements : departement_id, numero, nom, region_id
regions : region_id, nom

Je ne vois pas pourquoi tu te compliques la vie à chercher à faire compliqué quand tu peux faire simple est très évolutif...

merci pour tes tables,

lorsque j'essaye de crée ma base j'essaye toujours d'avoir le minimum de table, donc
c'est un tort?

il faut que je me concentre sur l'évolutivité et les doublons , le nombres
de table n'a pas d'importance ?

C'est un tort en quelque sorte, il faut que tu raisonnes en terme d'entités. Ensuite, tu as juste à établir les relations de la façon suivante entre tes entités :

Une commune a un nom et un code postal
Une commune appartient à un département
Un département possède plusieurs communes
Une personne possède une ou plusieurs adresses
Une adresse est possédée par une seule personne
... et ainsi de suite.

Tu obtiens ainsi tes cardinalités qui te permettent d'établir la modélisation de chaque aspect dans ta bdd.
Une commune a un nom et un CP => une commune ne peut être représentée par un type simple alors c'est une table. Elle a un nom. Le nom peut être représenté par un varchar alors c'est une colonne de commune. Idem pour le CP.
Une commune appartient à un département => Mais un département a un nom et un numéro alors ça ne peut être une colonne de table commune. Alors c'est une entité, et il faut une clé étrangère dans commune qui pointe vers un enregistrement de département.

... et ainsi de suite

Voilà la méthode Merise expliquée en très condensé

Pour le nombre de tables, l'importance vient quand tu as un gros trafic et que tes entités sont attachées à un grand nombre d'autres entités. Dans ce cas alors, les requêtes de jointure vont vite devenir gourmandes. Pour remédier à ça il y a diverses techniques, mais qui ne remettent jamais en cause le schéma initial s'il est bien fait.
Il y a par exemple la création de tables d'indexation, créer des tables "miroir"...

merci de ces précision :), je ne suis pas dans le cas ou il y a un très gros trafique , mais je ne savais qu'il y avais un procéder pour augmenter
la performance en cas de grosse jointure.
je vais pouvoir me concentrer a la conception des tables et ne plus penser au peformance des jointures