Voilà, pour XCMS, j'ai un système d'entête qui sont lues lorsque l'on va sur une rubrique du site. Cette entête défini la balise meta-description, meta-keywords, title, index(en option), les droits d'administration, la source des données, et enfin, la configuration du module utilisé.

Je souhaiterai lui ajouter un champ Père et un champ fils. De cette façon, je pourrais créer une arborescence qui permettra de lier les rubriques entre elles via une relation de filiation.

Mais voilà, j'ai bien peur que cela ralentisse le temps d'execution. Pourquoi ? Parceque si je crée une arborescence, je devrais afficher les entêtes filles de l'entête consultée (1 requête), l'entête mère de l'entête affichée (1 requête) voir, toute l'arborescence qui mène à l'entête consultée (ex: Accueil>Articles>Articles des membres>Articles de Gérard) ...

Et je serais obligé de procéder de deux manières (si vous en connaissez une autre, hésitez pas !!!) :
- La manière forte :
SELECT * FROM Entete WHERE Lang="$Lang"
Puis un tri via tableaux... Alors si j'ai 100 entêtes, v'là le dégât...

La manière douce, mais pleine de requêtes...
$IDEntete="ID_de_l'entête_courante";
while(mysql_num_rows($Requete=mysql_query('SELECT Description, Titre, ID, Rub WHERE Parent="' . $IDEntete . '"'))
{
echo '<a href="?Rub=' . mysql_result($Requete,0,'Rub') ... >...</a>';
}
Plus un :
while($Row=mysql_num_rows(mysql_query('SELECT * FROM Entete WHERE Fils='$IDEntete)))...


Dans les deux cas, j'ai une 20aine de requêtes à effectuer et ça me semble tout de même un peu pompeux en ressources... Des solutions ou tous les système ayant une arborescence pompe les ressources d'un serveur ????

> Dans les deux cas, j'ai une 20aine de requêtes à effectuer et ça me semble tout de
> même un peu pompeux en ressources... Des solutions ou tous les système ayant une
> arborescence pompe les ressources d'un serveur ????

Tous les systèmes hiérarchiques codés avec une base relationnelle posent problèmes. Tu mélanges deux concepts totalement opposés.

Maintenant tu as quelques solutions. Il y a des cas d'école avec des jolis algos qui permettent de numéroter les entrées et récupérer toute une arborescence en une ou deux requête. Globalement ça reste complexe à gérer et/ou casse couille.

Le plus simple est encore d'attribuer un identifiant à chaque catégorie et de rajouter un champ "chemin" à chaque entrée. Le chemin retrace toutes les catégories pères.

ex :
id - nom - chemin
1 - informatique - 1
2 - littérature - 2
3 - systèmes d'exploitation - 1/3
4 - programmation - 1/4
5 - linux - 1/3/5

Avec des tris sur le champ "chemin" tu pourras faire facilement des recherches sur les sous catégories, les catégories pères, les catégories filles ....
Ce n'est clairement pas le plus efficace mais c'est probablement le plus simple.

Tu devrais mettre ceci en 'cache'. Lorsqu'une nouvelle rubrique est créée, le cache se met à jour, et tu ne fais qu'un appel pour dépiler l'ensemble de tes rubriques.

La redondance d'informations, dans une base de données, peut etre utile lorsqu'elle permet d'alléger les ressources. Dans ce cas, je pense que ca peut etre utile. Soit par base de données, soit par un système de cache en 'fichier texte'.

Anonymus.

Tu as la représentation intervalaire qui est assez amusante à mettre en place : http://sql.developpez.com/arborescence/

Sinon, de façon plus pratique, j'ai déjà utilisé la même technique que celle que présente Ganf, calquée un peu sur le modèle d'une arborescence web. C'est vraiment très simple à mettre en place, et il est ensuite très facile de récupérer les enfants/parents, et en utilisant des fonctions MySQL un peu plus compliquées, on peut récupérer quasi n'importe quoi.

Une autre solution consiste à dépiler toute la table, et à gérer tout cela par tableau. Ca irait probablement plus vite, t'éviterait les multiples requètes. Seulement, il faut maitriser les fonctions récursives.

Anonymus.

C'est pas une mauvaise idée. La répétition n'est pas vraiment dans l'esprit optimisation de table, mais il est clair que ça optimise le code de façon conséquente. Ca ne permet pas, par contre, de gérer la double parenté comme dans l'ODP (Open Directory Project). A moins que je ne crée un système de ce style :
<?
$Chemin='1,2,3-4,5,6,3';
foreach(explode('-',$Chemin) as $T)
{
?>
<ul class="Arborescence">
<?
foreach(explode(',',$T) as $TT)
{
$Requete=mysql_query('SELECT Description, Titre FROM Entete WHERE ID=' . $IDEntete);
?>
<li><a href=....></a></li>
<?
}
?>
</ul>
<?
}
?>

En fait, ça me paraît même une bonne façon de procéder A moins qu'une recherche dans ma requête ne me permette de ne pas faire plusieurs requêtes... Mais je ne vois pas, à moins que le chemin ne représente plutôt la filiation que la parenté...

Edit: Incohérences...

Il me semble que si tu dois tout pouvoir faire en trois requetes MySQL. Avec un index correctement configuré cela ne devrait pas poser de problèmes particuliers. Si tu crée une seconde relation (sous forme de table), avec une clé d'index claculée sur plusieurs colonnes. Tu devrais encore pouvoir accélérer les choses, surtout si cette seconde est dans la RAM (MySQL 4.0 permet de faire cela).
Tu peux prévoir d'avoir une première table codée en dur et une seconde qui va être créée au fur et à mesure du fonctionnement du site.

Laurent.

Pour finir, j'ai utilisé la méthode de Nudrema, merci à lui sans lequel j'aurais sûrement eu un mal de chine à trouver mon bohneur.

Mais je suis confronté à un nouveau problème (il a bien-sûr fallu que ça arrive...). Mais cette fois-ci, c'est de l'ordre de l'oganisation de cette dernière.

J'ai plusieurs options qui me sont offertes :
- Soit, je met les deux premiers niveaux de l'arborescence du site dans le menu et une fois que ces deux premiers niveaux sont dépassés, je retrace le chemin des niveaux de l'arborescence dans l'entête sous forme de liste.
- Soit, je laisse le menu indépendant de l'arborescence et j'affiche l'arborescence dans l'entête dès le début.
Qu'en pensez-vous ?