Modélisation BDD - Régions, Départements, Villes FRANCE

[romrom_94]

Bonjour à tous,

Pour l'inscription sur un site internet que je développe, les utilisateurs auront la possibilité de renseigner leurs coordonnées via un formulaire contenant en partie :

- une liste déroulante contenant toutes les régions françaises
- une liste déroulante contentant tous les départements, ou tous les départements d'une région sélectionnée
- un champ texte pour la ville, qui fera des propositions en fonction de ce que l'utilisateur saisit et des régions/département qu'il a sélectionné
- et enfin un champ texte pour le code postal, qui sera pré-rempli si l’utilisateur a renseignée une ville dans la liste, ou alors l’inverse le fait de renseigner le code postal lui remplira tous les autres champs

En sachant qu’aucune des ces informations n’est obligatoire, il pourra très bien renseigner uniquement sa région. J’ai récupéré un fichier .xls mis à jour contenant toutes les communes françaises (région, dép., ville, CP) de 2011.

J'aurais besoin d'un avis d'un point de vue de l'organisation des données dans la base (Mysql)
Cette structure approximative vous parait elle être la plus optimisée :

Code: Tout sélectionner

tbl_region
reg_id : INT – PK, AI
reg_lib : VARCHAR

tbl_dep
dep_id : INT – PK, AI
dep_lib : VARCHAR
dep_reg : INT – FK (reg_id)

tbl_ville
ville_id : INT – PK, AI
ville_lib : VARCHAR
ville_reg : INT – FK (reg_id)
ville_dep : INT – FK (dep_id)

tbl_user
usr_id : INT – PK, AI
…
usr_reg : INT – FK (reg_id)
usr_dep : INT – FK (dep_id)
usr_ville : INT – FK (ville_id)

Merci.

[ZelkiN]

Salut romrom_94, a première vu ta structure à l'air bonne meme si j'emetterai un changement au niveau de la table user.
En effet pour eviter le nombre de requete croisé incésente surtout quand tu affiche les résultats pays,ville,région,cp de l'utilisateur moi je stockerai en "dur". C'est a dire qu'au lieu de mettre l'ID du pays je mettrai FRANCE. Ca te permettra également de mieux voir ta base de données ( a mon sens ).

Résultats : Meilleures visibilités, et économie SQL

Je repète que ce n'est que mon avis hein Bonne chance !

[spout]

C'est a dire qu'au lieu de mettre l'ID du pays je mettrai FRANCE

Je mettrais plutôt le pays en ISO 3166-1 alpha-2.

[romrom_94]

Merci pour vos réponses,

Etant donné que sur le site il y aura un moteur de recherche dont les critères principaux pour retrouver d'autres utilisateurs sont la région, le département, et/ou la ville (il n'y aura que la France en pays), le fait que ces infos soient stockés sous forme d'index et non en dur dans la table user améliora la rapidité de mes requêtes ?

[ZelkiN]

Tout dépend de la requete que tu fais, si tu fais une requete par index du type

Code: Tout sélectionner

SELECT pays FROM table WHERE pays = '1'


Alors la ca sera rapide, a contrario si tu fais

Code: Tout sélectionner

SELECT a.pays, b.idpays,b.nompays FROM tabl1 AS a INNER JOIN table2 AS b ON a.pays=b.idpays WHERE b.nompays = 'FRANCE'


La requete est plus lourde et donc plus gourmande

[Marie-Aude]

Attention, si un jour le site doit passer en version multilangue, il est essentiel que les pays soient indentifiés par un index, numérique ou code iso, mais certainement pas par leur nom en français. Pour les régions et les villes c'est moins important

[zeb]

A mon avis tu te prend la tête pour rien et optimiser c'est parfois faire plus lourd.
Une table qui contient en dur (pour la France) tous les noms de ville CP, département, région, ... c'est environ 40 000 entrées et 4Mb.
Tu va gagner quoi en dispatchant tout ça comme tu le fait ?
C'est pas la taille des bases qui est le plus handicapant, tu as presque partout accès a des fournisseur qui te donnent 1Gb de data en base, c'est la conso Sql souvent, en mettant tout en dur dans une table tu allège pas mal a mon avis.
Bon OK il y a forte redondance des champs région et département (en texte en plus) (et c'est pas DB friendly) mais si avec un select tu chope tout d'un coup dans tous les cas et que tu fait beaucoup référence a cette table a mon avis tu y gagne au final.