Salut les gens,

Si j'abuse dans les questions "spaces" dites le... [*]

Pouvez-vous me dire vos sentiments sur les données à représentation Intervallaire (RI) ?

Je me pose la question et j'avoue que, même si j'ai bien assimilé la chose, quelques
doutes subsistes. Ok, l'intervallaire fait gagner "énormément" de temps sur la recherche
mais en même temps cela perd de son intérêt quand on sait qu'on ne peut obtenir le niveau
de l'élément ciblé sans ajout d'une donnée le mentionnant. D'autre part toute modiifications
des branches obligent à modifier l'arbre des données lui-même (data Gauche/data Droite) et que,
de ce fait, cela augmente, de beaucoup, le temps d'exécution. Bref, j'ai toujours utilisiser
une représentation classique et je me demande si je vais pas changer pour la RI... D'ou ce post.

Si vous pouviez me donner un exemple, un avis, les + et les -, etc... ce serait sympa.

@+ les gens ...[*] je tentrai d'éviter ce genre de questions à l'avenir

hello,

Les + selon moi :
- recherche facile
- recherche facile
- recherche facile
- recherche facile
- recherche facile
- une fois codé, on est tranquille

Les - :
- il faut coder proprement la chose, ou utiliser un ORM qui fait déjà ça

En gros : c'est un peu plus lourd à mettre en place, mais tellement + simple à utiliser que ça vaut la peine.
Quelques champs en plus, ça ne compte pas, car les bases de données sont faites pour stocker les données, ce n'est pas génant en termes de volume.
Le temps de modification des données augmenté, pas très pertinent selon moi, sauf si on a un benchmark sur beaucoup de données (des dizaines de milliers).

A+

Pascal

Salut,

Pour moi, en positif :
-> C'est le meilleur modèle de stockage d'arborescence en base de données, en particulier du point de vue des performances.

en négatif :
-> peu intuitif et inadapté à une édition à la main, l'arbre doit presque obligatoirement être lu (et encore plus, modifié) depuis un script.

Ok, l'intervallaire fait gagner "énormément" de temps sur la recherche
mais en même temps cela perd de son intérêt quand on sait qu'on ne peut obtenir le niveau
de l'élément ciblé sans ajout d'une donnée le mentionnant.

Et en quoi c'est un souci ?

(A noter que si tu es vraiment maso, et si tes arbres ont des tailles/profondeurs "raisonnables" genre moins de 10 niveaux, ça peut quand même se faire)

D'autre part toute modiifications
des branches obligent à modifier l'arbre des données lui-même (data Gauche/data Droite) et que,
de ce fait, cela augmente, de beaucoup, le temps d'exécution.

Si tu raisonnes dans l'absolu comme tu le fais, oui, mais : il faut aussi voir que les modifications dont tu parles sont des opérations arithmétiques très simples à réaliser pour un script/SGBD, comparativement à ce que tu devrais faire avec un autre modèle de stockage. A l'usage on se rend compte que c'est globalement très performant malgré tout.

ça fait plus d'un an et demi que j'en fait, si tu as compris, tu code et c'est tout, pas besoin de jeter de coups d'œil, de limiter la profondeur (truc foireux par excellence qui embête et frustrent les utilisateurs).
Le seul point négatif c'est les performances à l'exécution, si non, il y a que des avantages

Re all,

Merci à tous pour vos réponses,

bon code @+

Hey ,

Le seul point négatif c'est les performances à l'exécution, si non, il y a que des avantages

Euh … tu peux avancer une preuve à cette affirmation ?

Le rapport apports/embêtements est très loin de tendre vers zéro (comprendre, il est largement supérieur à 1, donc il est cool). Tu te retrouves avec un système abstrait fort puissant dans un système relationnel. Tu peux difficilement faire mieux avec tes contraintes (ou sinon, il faut vraiment chercher, mais ça risque d'être difficilement déployable). Je suis sûr qu'avec un bon système d'indexes et une structure de table intelligement choisie, les performances seront celles attendues.

Euh … tu peux avancer une preuve à cette affirmation ?

J'ai pas dit en quelles mesures, mais si on fait ça en PDO avec PHP, avec, pour chaque action une requête, c'est un peu plus lent, je referais un benchmark si tu veux, en revanche, certains SGBD(R)(O) offre des extensions qui permettent de traiter ça en natif, et là c'est franchement efficace, mais ça à l'inconvénient de pas être portable.

Oui c'est plus lent, c'est évidement, mais relit ma partie sur le rapport apports/embêtements.
C'est comme dire que la POO est plus lente que le fonctionnel. Il faut faire des choix un moment : soit on a des outils puissants mais un peu plus lent (car la puissance induit et introduit nécessairement une abstraction, donc des couches supplémentaires), soit on a des outils moins puissants mais plus rapides. C'est toujours le même débat .

Tout dépend de la profondeur potentielle de l'arbre. Il est vrai qu'à coder c'est assez chiant ... surtout quand on veut changer la parenté de nodes de l'arbre ou les déplacer entre elles. Mais à l'execution on gagne en performance quand on veut remonter ou descendre dans l'arbre.

Certes, je voulais juste préciser que l'implémentation faisais plus ou moins chuter les performances.
A noté que je suis à 100% pour cette méthodes de gestion, mais il demandait les avantages et les inconvénients, pour certaines implémentations cette pertes n'est pas négligeable, pour l'autre, il peut l'être, mais j'ai l'habitude de négliger le moins de choses possible.
Mais bon, le RI c'est bon, faut en manger.

Salut les gens,

Merci pour toutes ses réponses eh eh eh

J'y re-go, @+ et bon code

Moi j'y go d'agneau

bon => [ ]