C'est encore moi!
Ce que je souhaiterai faire c'est hierarchiser des données en catégories.
Par exemple Continent>Pays>Region>departement>villes
Au debut je pensais procéder comme suis: utiliser deux chiffres pour chaque catégories et les acoler, chaque élement ville possédera alors un ID unique.
Par exemple Paris "serait"(son ID dans ma table mysql) : 0101010101
L'ile de france serait: 0101010100(on met des 00 quand on ne veut pas regarder les catégories "enfants")
... et l'Europe aurait pour ID: 0100000000
Seul problème ca me fait des entiers très longs et puis si je veux mettre toutes les villes du monde il va pas falloir coder sur deux chiffres les villes mais sur beaucoup plus, de meme pour les regions etc
J'ai alors penser à me tourner vers des lettres, ce qui permettra d'avoir moins de caractères, ou meme si c'est long, stocker ca dans une table sous form de TEXT.
Le problème c'est que la gestion va etre un plus compliquée.
Y a -til une autre solution communément utilisée qui permet de réaliser ce que je veux faire?
Merci.
sans trop réfléchir, mais juste pour l'idée :
pourquoi est-ce que tu ne fais pas une table avec un champ "identifiant-parent" ?
un peu comme ça :
(table 'entites')
- id
- #id_parent
- nom
- #id_type
avec #id_type clef étrangère vers une table te donnant si c'est, par exemple :
(table 'type')
- 1, 'continent'
- 2, 'pays'
- 3, 'ville'
et, par exemple, tu aurais des enregistrements tels ceux-ci :
- 1, NULL, 'Europe', 1
- 2, 1, 'France', 2
- 3, 1, 'Allemagne', 2
- 4, 1, 'Belgique', 2
- 5, 2, 'Paris', 3
- 6, 2, 'Lyon', 3
- 7, 2, 'Lille', 3
pour retrouver les pays d'europe, ça sera genre
select * from entites where id_parent = 1
pour les villes de France, du style
select * from entites where id_parent = 2
Bon, après, ça se complexifie si tu veux bosser sur plusieurs niveaux de hiérarchie, genre pour retrouver toutes les villes d'europe
Avec des requetes imbriques (en mySQL, supportées uniquement depuis la version 4.1), ça serait du genre :
select * from entites where id_parent IN (select id from entites where id_parent = 1)
(on garde les entités (=villes) dont le parent est une entité (=pays) qui a pour parent l'europe)
pas forcément LA solution optimale, mais ça te permet n'importe quel niveau de précision : pour certains endroits, tu peux ne mettre que le pays, pour d'autres, tu peux descendre aux rues ^^
sinon, tu as la possibilité de faire moins générique, mais peut-être plus facile à se représenter :
un table pour les continents, une pour les pays, une pour les ville, avec dans chaque table (sauf pour celle le plus haut dans la hiérarchie) une colonne qui pointe sur l'enregistrement en table parente
effectivement, une solution récursive me semble idéale, pour une arborescence de profondeur non fixe.
du genre
pour toutes les entités de niveau N
afficher l'entité de niveau N
recommencer sur les entités de niveau N +1 qui ont l'entité de niveau N comme parent
après, ça risque de te faire pas mal de requêtes... et donc, de pas être ultra-rapide...
il doit y avoir moyen d'accèlérer un peu ça, genre en pré-chargeant une partie des données tout d'un coup vers un tableau, et de les traiter ensuite...
Mais là, sur le vif, j'ai pas d'explication brève et simple qui me vienne à l'esprit ^^
Oui la solution de neuroo est mieux.
Parce que charger toutes les données => très crade, ça veut dire que ton code est pas réutilisable (bah oué des bases de plusieurs To ça existe, mais pas des machines avec plusieurs To de ram)
Requêtes récursives => même problème, si la table grossit tu peux te retrouver à tapper dans les 500000 requêtes, c'est pas top.
