Lefounard

Bonjour,
Voila je dois creer une base de donnée et tout son système de gestion pour un site web marchand.
On peut reprenseter le probleme sous la forme d'une arborescence :
Rubrique (niveau 0)
| |
Sous Rubrique --------- Sous Rubrique (niveau 1)

------------ ------------
| |
S. Rub S. Rub S. Rub S. Rub (niveau 2)

Je cherche a porter une dynamique sur la profondeur de mon arborescence.
C'est-a-dire que par la suite, le webmarchand pourrat creer une sous rubrique sans mettre les mains dans
le cambouilli et restant néophyte en informatique.
Le problème c'est d'assurer un modèle pouvant etre optimiser en terme de requete et d'occupation memoire.
Et d'une autre part, faire un affichage générique html/php.
Je voulais savoir si vous pouvez me conseiller existe-t-il une méthode ?
Mysql ou PGSQL, la derniere m'étant pas trés mais me semble interressante pour l'objet, les triggers, tout ces elements que
j'ai vu sur oracle.
Merci,

Lefounard

J'ai élaboré une organisation maison.
Dans notre arborescence, chaque noeud et feuille va connaitre son pere.
Ainsi j'aurais une table de données arbo:

Identifiant Noeud Pere

Cette table restera statique dans sa structure.
Le problème c'est lorsque le webmarchand ajoutera 2 sous catégories,
il faudra qu'il deplace tous les elements (produits) dans les catégorie
inférieurs. Cela necessite de faire un UPLOAD sur le champs id_catégorie de chaque produit.
Je ne vois pas trop les autres limites de ma méthode,
Merci de me donner vos avis,
Ciao,

LA GLOBULE

Ton truc hiérarchisé ainsi, ca fonctionne, par contre, attention à la profondeur de ton arbre.

Si la profondeur est trop grande (illimitée), ca va ramer du steak, MySQL n'étant pas adapté à ce genre d'exercice, auquel on préfèrera un SGBD objet (qui sont très rarement utilisés, sauf dans les SIG).

LupusMic

> SGBD objet

Et une base de données hiérarchique telle que LDAP ne serait pas adaptée ?

j_erome

LDAP est conçu pour gérer des données d'annuaires. Ce n'est pas un système relationnel. Pas du tout adapté.

Le système d'indiquer l'id du noeud parent dans chaque tuple fonctionne sans problème. Par contre, ça nécessite au minimum une requête par niveau + un peu de bidouillage pour ou pire une requête par noeud (à chaque fois que tu rencontre un noeud, tu fais une requête pour récupérer les noeuds enfants).

En terme de performances, c'est pas top.

Il existe une autre solution c'est la méthode description intervalaire d'un arbre.

http://sqlpro.developpez.com/cours/arborescence/

Plus délicat à mettre au point mais également plus efficace en terme de performances

LA GLOBULE

La représentation intervallaire n'est qu'un "trix" pour stocker un arbre dans un SGBD relationnel.
A la base, ce n'est pas prévu pour.

Je doute des performances si on part sur du 100 update / seconde (en même temps, tu me diras, quel site perso. a un tel trafic ? :p).
Car le problème de cette représentation, c'est justement les mises à jour.

Le SGBD objet a été créé justement pour résoudre ce genre de problème.