Voici un sujet d'un post "d'en face" qui m'interesse beaucoup: les arbres
par représentation intervallaire.
Si vous avez des idées constructives à ce sujet, je suis preneur (pas que
moi je pense)
> il existe une autre solution, la gestion d'arbres par représentation
intervallaire dont tu peux trouver une description complete en suivant le
lien:
> http://sqlpro.developpez.com/cours/arborescence/
> c'est super interessant et les avantages par rapport à l'auto-jointure (ce
que tu as fait avec
> FSF_Pere dans ton exemple) y sont décrits.
J'ai été intéressé par cette modélisation intervallaire, pour une gestion
d'articles / sous-articles; mais je l'ai abandonnée à cause des
ajouts/suppressions.
En effet, lors d'une insertion (ou suppression) il faut modifier TOUTES les
bornes !!!
sur une table qui comporte + de 2.000.000 de tuples, comme c'est mon cas, je
ne vois pas comment c'est "pensable".
A moins que je ne me trompe !
Merci de votre avis sur ce sujet très intéressant
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Francis DUHAUT
Faut envoyer ça à PCSOFT pour la mise en place dans une LST. C'est vrai que cela est très interressant.
"I.G.LOG" a écrit dans le message de news: 447ffbe8$0$20151$
Bonjour à tous
Voici un sujet d'un post "d'en face" qui m'interesse beaucoup: les arbres par représentation intervallaire. Si vous avez des idées constructives à ce sujet, je suis preneur (pas que moi je pense)
il existe une autre solution, la gestion d'arbres par représentation
intervallaire dont tu peux trouver une description complete en suivant le lien:
http://sqlpro.developpez.com/cours/arborescence/ c'est super interessant et les avantages par rapport à l'auto-jointure (ce
que tu as fait avec
FSF_Pere dans ton exemple) y sont décrits.
J'ai été intéressé par cette modélisation intervallaire, pour une gestion d'articles / sous-articles; mais je l'ai abandonnée à cause des ajouts/suppressions. En effet, lors d'une insertion (ou suppression) il faut modifier TOUTES les bornes !!! sur une table qui comporte + de 2.000.000 de tuples, comme c'est mon cas, je ne vois pas comment c'est "pensable". A moins que je ne me trompe ! Merci de votre avis sur ce sujet très intéressant
Faut envoyer ça à PCSOFT pour la mise en place dans une LST. C'est vrai que
cela est très interressant.
"I.G.LOG" <iglog@free.fr> a écrit dans le message de news:
447ffbe8$0$20151$ba4acef3@news.orange.fr...
Bonjour à tous
Voici un sujet d'un post "d'en face" qui m'interesse beaucoup: les arbres
par représentation intervallaire.
Si vous avez des idées constructives à ce sujet, je suis preneur (pas que
moi je pense)
il existe une autre solution, la gestion d'arbres par représentation
intervallaire dont tu peux trouver une description complete en suivant le
lien:
http://sqlpro.developpez.com/cours/arborescence/
c'est super interessant et les avantages par rapport à l'auto-jointure
(ce
que tu as fait avec
FSF_Pere dans ton exemple) y sont décrits.
J'ai été intéressé par cette modélisation intervallaire, pour une gestion
d'articles / sous-articles; mais je l'ai abandonnée à cause des
ajouts/suppressions.
En effet, lors d'une insertion (ou suppression) il faut modifier TOUTES
les
bornes !!!
sur une table qui comporte + de 2.000.000 de tuples, comme c'est mon cas,
je
ne vois pas comment c'est "pensable".
A moins que je ne me trompe !
Merci de votre avis sur ce sujet très intéressant
Faut envoyer ça à PCSOFT pour la mise en place dans une LST. C'est vrai que cela est très interressant.
"I.G.LOG" a écrit dans le message de news: 447ffbe8$0$20151$
Bonjour à tous
Voici un sujet d'un post "d'en face" qui m'interesse beaucoup: les arbres par représentation intervallaire. Si vous avez des idées constructives à ce sujet, je suis preneur (pas que moi je pense)
il existe une autre solution, la gestion d'arbres par représentation
intervallaire dont tu peux trouver une description complete en suivant le lien:
http://sqlpro.developpez.com/cours/arborescence/ c'est super interessant et les avantages par rapport à l'auto-jointure (ce
que tu as fait avec
FSF_Pere dans ton exemple) y sont décrits.
J'ai été intéressé par cette modélisation intervallaire, pour une gestion d'articles / sous-articles; mais je l'ai abandonnée à cause des ajouts/suppressions. En effet, lors d'une insertion (ou suppression) il faut modifier TOUTES les bornes !!! sur une table qui comporte + de 2.000.000 de tuples, comme c'est mon cas, je ne vois pas comment c'est "pensable". A moins que je ne me trompe ! Merci de votre avis sur ce sujet très intéressant
patrice
"I.G.LOG" a écrit dans le message de news:447ffbe8$0$20151$
J'ai été intéressé par cette modélisation intervallaire, pour une gestion d'articles / sous-articles; mais je l'ai abandonnée à cause des ajouts/suppressions. En effet, lors d'une insertion (ou suppression) il faut modifier TOUTES
les
bornes !!! sur une table qui comporte + de 2.000.000 de tuples, comme c'est mon cas,
je
ne vois pas comment c'est "pensable". A moins que je ne me trompe ! Merci de votre avis sur ce sujet très intéressant
tres interessant
peut être en prévoyant une marge, (on garde le 1 d'écart pour les feuilles , mais on ajoute une constante pour les noeuds) Je pense que les algos de recherche reste intacte, et l'insertion d'une feuille ne modifie que son noeud pere (tant que la marge n'est pas épuisée) la marge dépendrait de la profondeur et d'un nombre moyen de feuille, ca a l'air (a vue d'un tres gros pif) de marcher si la profondeur est connue et fixe et pas trop grande
"I.G.LOG" <iglog@free.fr> a écrit dans le message de
news:447ffbe8$0$20151$ba4acef3@news.orange.fr...
J'ai été intéressé par cette modélisation intervallaire, pour une gestion
d'articles / sous-articles; mais je l'ai abandonnée à cause des
ajouts/suppressions.
En effet, lors d'une insertion (ou suppression) il faut modifier TOUTES
les
bornes !!!
sur une table qui comporte + de 2.000.000 de tuples, comme c'est mon cas,
je
ne vois pas comment c'est "pensable".
A moins que je ne me trompe !
Merci de votre avis sur ce sujet très intéressant
tres interessant
peut être en prévoyant une marge, (on garde le 1 d'écart pour les feuilles ,
mais on ajoute une constante pour les noeuds)
Je pense que les algos de recherche reste intacte, et l'insertion d'une
feuille ne modifie que son noeud pere (tant que la marge n'est pas épuisée)
la marge dépendrait de la profondeur et d'un nombre moyen de feuille, ca a
l'air (a vue d'un tres gros pif) de marcher si la profondeur est connue et
fixe et pas trop grande
"I.G.LOG" a écrit dans le message de news:447ffbe8$0$20151$
J'ai été intéressé par cette modélisation intervallaire, pour une gestion d'articles / sous-articles; mais je l'ai abandonnée à cause des ajouts/suppressions. En effet, lors d'une insertion (ou suppression) il faut modifier TOUTES
les
bornes !!! sur une table qui comporte + de 2.000.000 de tuples, comme c'est mon cas,
je
ne vois pas comment c'est "pensable". A moins que je ne me trompe ! Merci de votre avis sur ce sujet très intéressant
tres interessant
peut être en prévoyant une marge, (on garde le 1 d'écart pour les feuilles , mais on ajoute une constante pour les noeuds) Je pense que les algos de recherche reste intacte, et l'insertion d'une feuille ne modifie que son noeud pere (tant que la marge n'est pas épuisée) la marge dépendrait de la profondeur et d'un nombre moyen de feuille, ca a l'air (a vue d'un tres gros pif) de marcher si la profondeur est connue et fixe et pas trop grande
Marc Benoit
Bonjour,
Très intéressant, c'est vrai que c'est à soumettre à PC SOFT pour un sujet de LST ...
I.G.LOG a écrit :
Bonjour à tous
Voici un sujet d'un post "d'en face" qui m'interesse beaucoup: les arbres par représentation intervallaire. Si vous avez des idées constructives à ce sujet, je suis preneur (pas que moi je pense)
il existe une autre solution, la gestion d'arbres par représentation
intervallaire dont tu peux trouver une description complete en suivant le lien:
http://sqlpro.developpez.com/cours/arborescence/ c'est super interessant et les avantages par rapport à l'auto-jointure (ce
que tu as fait avec
FSF_Pere dans ton exemple) y sont décrits.
J'ai été intéressé par cette modélisation intervallaire, pour une gestion d'articles / sous-articles; mais je l'ai abandonnée à cause des ajouts/suppressions. En effet, lors d'une insertion (ou suppression) il faut modifier TOUTES les bornes !!! sur une table qui comporte + de 2.000.000 de tuples, comme c'est mon cas, je ne vois pas comment c'est "pensable".
Peut être un thread qui effectue la "grosse modif" et qui, ensuite, signale qu'il a fini au prog principal ???
A moins que je ne me trompe ! Merci de votre avis sur ce sujet très intéressant
-- -------------------------------------------------------------------------- Pour me répondre, cliquez sur le lien ci dessous http://cerbermail.com/?GKl1n6oe9D --------------------------------------------------------------------------
Bonjour,
Très intéressant, c'est vrai que c'est à soumettre à PC SOFT pour un
sujet de LST ...
I.G.LOG a écrit :
Bonjour à tous
Voici un sujet d'un post "d'en face" qui m'interesse beaucoup: les arbres
par représentation intervallaire.
Si vous avez des idées constructives à ce sujet, je suis preneur (pas que
moi je pense)
il existe une autre solution, la gestion d'arbres par représentation
intervallaire dont tu peux trouver une description complete en suivant le
lien:
http://sqlpro.developpez.com/cours/arborescence/
c'est super interessant et les avantages par rapport à l'auto-jointure (ce
que tu as fait avec
FSF_Pere dans ton exemple) y sont décrits.
J'ai été intéressé par cette modélisation intervallaire, pour une gestion
d'articles / sous-articles; mais je l'ai abandonnée à cause des
ajouts/suppressions.
En effet, lors d'une insertion (ou suppression) il faut modifier TOUTES les
bornes !!!
sur une table qui comporte + de 2.000.000 de tuples, comme c'est mon cas, je
ne vois pas comment c'est "pensable".
Peut être un thread qui effectue la "grosse modif" et qui, ensuite,
signale qu'il a fini au prog principal ???
A moins que je ne me trompe !
Merci de votre avis sur ce sujet très intéressant
--
--------------------------------------------------------------------------
Pour me répondre, cliquez sur le lien ci dessous
http://cerbermail.com/?GKl1n6oe9D
--------------------------------------------------------------------------
Très intéressant, c'est vrai que c'est à soumettre à PC SOFT pour un sujet de LST ...
I.G.LOG a écrit :
Bonjour à tous
Voici un sujet d'un post "d'en face" qui m'interesse beaucoup: les arbres par représentation intervallaire. Si vous avez des idées constructives à ce sujet, je suis preneur (pas que moi je pense)
il existe une autre solution, la gestion d'arbres par représentation
intervallaire dont tu peux trouver une description complete en suivant le lien:
http://sqlpro.developpez.com/cours/arborescence/ c'est super interessant et les avantages par rapport à l'auto-jointure (ce
que tu as fait avec
FSF_Pere dans ton exemple) y sont décrits.
J'ai été intéressé par cette modélisation intervallaire, pour une gestion d'articles / sous-articles; mais je l'ai abandonnée à cause des ajouts/suppressions. En effet, lors d'une insertion (ou suppression) il faut modifier TOUTES les bornes !!! sur une table qui comporte + de 2.000.000 de tuples, comme c'est mon cas, je ne vois pas comment c'est "pensable".
Peut être un thread qui effectue la "grosse modif" et qui, ensuite, signale qu'il a fini au prog principal ???
A moins que je ne me trompe ! Merci de votre avis sur ce sujet très intéressant
-- -------------------------------------------------------------------------- Pour me répondre, cliquez sur le lien ci dessous http://cerbermail.com/?GKl1n6oe9D --------------------------------------------------------------------------
B. Neve
Si ce type de modélisation vous intéresse, je ne peux que vous recommander de consulter le produit nommé "Caché" à l'adresse suivante...
http://www.intersystems.fr
Cette base de données est créée sur une base hiérarchique sur laquelle l'on peut créer des tables SQL. On pourra donc mélanger dans un seul fichier aussi bien des factures que leurs lignes par exemple. L'avantage principal étant la vitesse... En effet, appeler une facture et ses détails à l'écran ne requiert plus qu'une seule lecture physique... Nous avons travaillé pendant des années avec des bases de données de ce type. La création de la base requiert une discipline nettement plus élevée que le principe "relationnel" mais une fois qu'elle est bien conçue, les résultats sont à la hauteur des attentes.
Benoît Nève
"Marc Benoit" a écrit dans le message de news: 448a62d4$0$890$
Bonjour,
Très intéressant, c'est vrai que c'est à soumettre à PC SOFT pour un sujet de LST ...
I.G.LOG a écrit :
Bonjour à tous
Voici un sujet d'un post "d'en face" qui m'interesse beaucoup: les arbres par représentation intervallaire. Si vous avez des idées constructives à ce sujet, je suis preneur (pas que moi je pense)
il existe une autre solution, la gestion d'arbres par représentation
intervallaire dont tu peux trouver une description complete en suivant le lien:
http://sqlpro.developpez.com/cours/arborescence/ c'est super interessant et les avantages par rapport à l'auto-jointure (ce
que tu as fait avec
FSF_Pere dans ton exemple) y sont décrits.
J'ai été intéressé par cette modélisation intervallaire, pour une gestion d'articles / sous-articles; mais je l'ai abandonnée à cause des ajouts/suppressions. En effet, lors d'une insertion (ou suppression) il faut modifier TOUTES les bornes !!! sur une table qui comporte + de 2.000.000 de tuples, comme c'est mon cas, je ne vois pas comment c'est "pensable".
Peut être un thread qui effectue la "grosse modif" et qui, ensuite, signale qu'il a fini au prog principal ???
A moins que je ne me trompe ! Merci de votre avis sur ce sujet très intéressant
-- -------------------------------------------------------------------------- Pour me répondre, cliquez sur le lien ci dessous http://cerbermail.com/?GKl1n6oe9D --------------------------------------------------------------------------
Si ce type de modélisation vous intéresse, je ne peux que vous recommander
de consulter le produit nommé "Caché" à l'adresse suivante...
http://www.intersystems.fr
Cette base de données est créée sur une base hiérarchique sur laquelle l'on
peut créer des tables SQL. On pourra donc mélanger dans un seul fichier
aussi bien des factures que leurs lignes par exemple. L'avantage principal
étant la vitesse... En effet, appeler une facture et ses détails à l'écran
ne requiert plus qu'une seule lecture physique... Nous avons travaillé
pendant des années avec des bases de données de ce type. La création de la
base requiert une discipline nettement plus élevée que le principe
"relationnel" mais une fois qu'elle est bien conçue, les résultats sont à la
hauteur des attentes.
Benoît Nève
"Marc Benoit" <marc.benoit.noSpam@wanadoo.fr> a écrit dans le message de
news: 448a62d4$0$890$ba4acef3@news.orange.fr...
Bonjour,
Très intéressant, c'est vrai que c'est à soumettre à PC SOFT pour un sujet
de LST ...
I.G.LOG a écrit :
Bonjour à tous
Voici un sujet d'un post "d'en face" qui m'interesse beaucoup: les arbres
par représentation intervallaire.
Si vous avez des idées constructives à ce sujet, je suis preneur (pas que
moi je pense)
il existe une autre solution, la gestion d'arbres par représentation
intervallaire dont tu peux trouver une description complete en suivant le
lien:
http://sqlpro.developpez.com/cours/arborescence/
c'est super interessant et les avantages par rapport à l'auto-jointure
(ce
que tu as fait avec
FSF_Pere dans ton exemple) y sont décrits.
J'ai été intéressé par cette modélisation intervallaire, pour une gestion
d'articles / sous-articles; mais je l'ai abandonnée à cause des
ajouts/suppressions.
En effet, lors d'une insertion (ou suppression) il faut modifier TOUTES
les
bornes !!!
sur une table qui comporte + de 2.000.000 de tuples, comme c'est mon cas,
je
ne vois pas comment c'est "pensable".
Peut être un thread qui effectue la "grosse modif" et qui, ensuite,
signale qu'il a fini au prog principal ???
A moins que je ne me trompe !
Merci de votre avis sur ce sujet très intéressant
--
--------------------------------------------------------------------------
Pour me répondre, cliquez sur le lien ci dessous
http://cerbermail.com/?GKl1n6oe9D
--------------------------------------------------------------------------
Si ce type de modélisation vous intéresse, je ne peux que vous recommander de consulter le produit nommé "Caché" à l'adresse suivante...
http://www.intersystems.fr
Cette base de données est créée sur une base hiérarchique sur laquelle l'on peut créer des tables SQL. On pourra donc mélanger dans un seul fichier aussi bien des factures que leurs lignes par exemple. L'avantage principal étant la vitesse... En effet, appeler une facture et ses détails à l'écran ne requiert plus qu'une seule lecture physique... Nous avons travaillé pendant des années avec des bases de données de ce type. La création de la base requiert une discipline nettement plus élevée que le principe "relationnel" mais une fois qu'elle est bien conçue, les résultats sont à la hauteur des attentes.
Benoît Nève
"Marc Benoit" a écrit dans le message de news: 448a62d4$0$890$
Bonjour,
Très intéressant, c'est vrai que c'est à soumettre à PC SOFT pour un sujet de LST ...
I.G.LOG a écrit :
Bonjour à tous
Voici un sujet d'un post "d'en face" qui m'interesse beaucoup: les arbres par représentation intervallaire. Si vous avez des idées constructives à ce sujet, je suis preneur (pas que moi je pense)
il existe une autre solution, la gestion d'arbres par représentation
intervallaire dont tu peux trouver une description complete en suivant le lien:
http://sqlpro.developpez.com/cours/arborescence/ c'est super interessant et les avantages par rapport à l'auto-jointure (ce
que tu as fait avec
FSF_Pere dans ton exemple) y sont décrits.
J'ai été intéressé par cette modélisation intervallaire, pour une gestion d'articles / sous-articles; mais je l'ai abandonnée à cause des ajouts/suppressions. En effet, lors d'une insertion (ou suppression) il faut modifier TOUTES les bornes !!! sur une table qui comporte + de 2.000.000 de tuples, comme c'est mon cas, je ne vois pas comment c'est "pensable".
Peut être un thread qui effectue la "grosse modif" et qui, ensuite, signale qu'il a fini au prog principal ???
A moins que je ne me trompe ! Merci de votre avis sur ce sujet très intéressant
-- -------------------------------------------------------------------------- Pour me répondre, cliquez sur le lien ci dessous http://cerbermail.com/?GKl1n6oe9D --------------------------------------------------------------------------
elecoest
B. Neve a écrit :
Si ce type de modélisation vous intéresse, je ne peux que vous recomm ander de consulter le produit nommé "Caché" à l'adresse suivante...
http://www.intersystems.fr
Na pas confondre une base OO avec une base Relationnelle dans laquelle on utilise une représentation intervallaire. ce n'est pas du tout la même chose.
Pour en revenir à notre gestion intervallaire. Je vient de terminer la transformation de l'exemple fourni sur la page en WinDev 7.5. Franchement c'est bluffant au niveau de la gestion de feuilles/filtres. Inconvénient c'est que l'arbre peut vitre être détruit si on ne gère pas les transactions lors des phase d'insert / delete vu que tous les éléments se gèrent les uns les autres.
L'affichage en TV est facilement appréhendable. Reste à cabler l'insertion dans le treeview et le drag & drop.
-- Emmanuel Lecoester
B. Neve a écrit :
Si ce type de modélisation vous intéresse, je ne peux que vous recomm ander
de consulter le produit nommé "Caché" à l'adresse suivante...
http://www.intersystems.fr
Na pas confondre une base OO avec une base Relationnelle dans laquelle
on utilise une représentation intervallaire. ce n'est pas du tout la
même chose.
Pour en revenir à notre gestion intervallaire. Je vient de terminer la
transformation de l'exemple fourni sur la page en WinDev 7.5.
Franchement c'est bluffant au niveau de la gestion de feuilles/filtres.
Inconvénient c'est que l'arbre peut vitre être détruit si on ne
gère pas les transactions lors des phase d'insert / delete vu que tous
les éléments se gèrent les uns les autres.
L'affichage en TV est facilement appréhendable. Reste à cabler
l'insertion dans le treeview et le drag & drop.
Si ce type de modélisation vous intéresse, je ne peux que vous recomm ander de consulter le produit nommé "Caché" à l'adresse suivante...
http://www.intersystems.fr
Na pas confondre une base OO avec une base Relationnelle dans laquelle on utilise une représentation intervallaire. ce n'est pas du tout la même chose.
Pour en revenir à notre gestion intervallaire. Je vient de terminer la transformation de l'exemple fourni sur la page en WinDev 7.5. Franchement c'est bluffant au niveau de la gestion de feuilles/filtres. Inconvénient c'est que l'arbre peut vitre être détruit si on ne gère pas les transactions lors des phase d'insert / delete vu que tous les éléments se gèrent les uns les autres.
L'affichage en TV est facilement appréhendable. Reste à cabler l'insertion dans le treeview et le drag & drop.
-- Emmanuel Lecoester
I.G.LOG
> Peut être un thread qui effectue la "grosse modif" et qui, ensuite, signale qu'il a fini au prog principal ???
Bonjour, Oui j'avais pensé au thread, pour éviter de bloquer le programme pendant la mise à jour. Quoiqu'il en soit, je ne pense pas que ca soit "réaliste" en exploitation, notamment si on utilise des objets chainés par exemple: dans ce cas, il faudrait aussi réinitailiser les objets en mémoire etc... Enfin, je vois beaucoup de contraintes lors d'ajout/suppression; bien malheureusement, car cette modélisation offre bien des avantages en lecture (une seule requete pour remonter toute une branche !!!). Et puis, est-ce que toutes les bases seront assez performantes sur des volumes importants ?
> Peut être un thread qui effectue la "grosse modif" et qui, ensuite,
signale qu'il a fini au prog principal ???
Bonjour,
Oui j'avais pensé au thread, pour éviter de bloquer le programme pendant la
mise à jour.
Quoiqu'il en soit, je ne pense pas que ca soit "réaliste" en exploitation,
notamment si on utilise des objets chainés par exemple: dans ce cas, il
faudrait aussi réinitailiser les objets en mémoire etc...
Enfin, je vois beaucoup de contraintes lors d'ajout/suppression; bien
malheureusement, car cette modélisation offre bien des avantages en lecture
(une seule requete pour remonter toute une branche !!!).
Et puis, est-ce que toutes les bases seront assez performantes sur des
volumes importants ?
> Peut être un thread qui effectue la "grosse modif" et qui, ensuite, signale qu'il a fini au prog principal ???
Bonjour, Oui j'avais pensé au thread, pour éviter de bloquer le programme pendant la mise à jour. Quoiqu'il en soit, je ne pense pas que ca soit "réaliste" en exploitation, notamment si on utilise des objets chainés par exemple: dans ce cas, il faudrait aussi réinitailiser les objets en mémoire etc... Enfin, je vois beaucoup de contraintes lors d'ajout/suppression; bien malheureusement, car cette modélisation offre bien des avantages en lecture (une seule requete pour remonter toute une branche !!!). Et puis, est-ce que toutes les bases seront assez performantes sur des volumes importants ?
I.G.LOG
> Pour en revenir à notre gestion intervallaire. Je vient de terminer la transformation de l'exemple fourni sur la page en WinDev 7.5. Franchement c'est bluffant au niveau de la gestion de feuilles/filtres. Inconvénient c'est que l'arbre peut vitre être détruit si on ne gère pas les transactions lors des phase d'insert / delete vu que tous es éléments se gèrent les uns les autres.
L'affichage en TV est facilement appréhendable. Reste à cabler l'insertion dans le treeview et le drag & drop.
Bonjour, Avez vous essayé avec des volumes importants ? j'ai abandonné cette modélisation à cause de l'ajout/suppression qui nécessite un update de toutes les bornes gauche et droites. Effectivement, il faut de toute façon gérer les modifs par transaction. mais est-ce bien réaliste sur de gros volumes ?
> Pour en revenir à notre gestion intervallaire. Je vient de terminer la
transformation de l'exemple fourni sur la page en WinDev 7.5.
Franchement c'est bluffant au niveau de la gestion de feuilles/filtres.
Inconvénient c'est que l'arbre peut vitre être détruit si on ne
gère pas les transactions lors des phase d'insert / delete vu que tous
es éléments se gèrent les uns les autres.
L'affichage en TV est facilement appréhendable. Reste à cabler
l'insertion dans le treeview et le drag & drop.
Bonjour,
Avez vous essayé avec des volumes importants ?
j'ai abandonné cette modélisation à cause de l'ajout/suppression qui
nécessite un update de toutes les bornes gauche et droites.
Effectivement, il faut de toute façon gérer les modifs par transaction. mais
est-ce bien réaliste sur de gros volumes ?
> Pour en revenir à notre gestion intervallaire. Je vient de terminer la transformation de l'exemple fourni sur la page en WinDev 7.5. Franchement c'est bluffant au niveau de la gestion de feuilles/filtres. Inconvénient c'est que l'arbre peut vitre être détruit si on ne gère pas les transactions lors des phase d'insert / delete vu que tous es éléments se gèrent les uns les autres.
L'affichage en TV est facilement appréhendable. Reste à cabler l'insertion dans le treeview et le drag & drop.
Bonjour, Avez vous essayé avec des volumes importants ? j'ai abandonné cette modélisation à cause de l'ajout/suppression qui nécessite un update de toutes les bornes gauche et droites. Effectivement, il faut de toute façon gérer les modifs par transaction. mais est-ce bien réaliste sur de gros volumes ?
elecoest
I.G.LOG a écrit :
> Pour en revenir à notre gestion intervallaire. Je vient de terminer la > transformation de l'exemple fourni sur la page en WinDev 7.5. > Franchement c'est bluffant au niveau de la gestion de feuilles/filtres. > Inconvénient c'est que l'arbre peut vitre être détruit si on ne > gère pas les transactions lors des phase d'insert / delete vu que tous > es éléments se gèrent les uns les autres. > > L'affichage en TV est facilement appréhendable. Reste à cabler > l'insertion dans le treeview et le drag & drop.
Bonjour, Avez vous essayé avec des volumes importants ?
Envoi moi un exemple avec 2 millions de lignes je te dirai ce que çà donne ^^
j'ai abandonné cette modélisation à cause de l'ajout/suppression qui nécessite un update de toutes les bornes gauche et droites. Effectivement, il faut de toute façon gérer les modifs par transactio n. mais est-ce bien réaliste sur de gros volumes ?
I.G.LOG a écrit :
> Pour en revenir à notre gestion intervallaire. Je vient de terminer la
> transformation de l'exemple fourni sur la page en WinDev 7.5.
> Franchement c'est bluffant au niveau de la gestion de feuilles/filtres.
> Inconvénient c'est que l'arbre peut vitre être détruit si on ne
> gère pas les transactions lors des phase d'insert / delete vu que tous
> es éléments se gèrent les uns les autres.
>
> L'affichage en TV est facilement appréhendable. Reste à cabler
> l'insertion dans le treeview et le drag & drop.
Bonjour,
Avez vous essayé avec des volumes importants ?
Envoi moi un exemple avec 2 millions de lignes je te dirai ce que çà
donne ^^
j'ai abandonné cette modélisation à cause de l'ajout/suppression qui
nécessite un update de toutes les bornes gauche et droites.
Effectivement, il faut de toute façon gérer les modifs par transactio n. mais
est-ce bien réaliste sur de gros volumes ?
> Pour en revenir à notre gestion intervallaire. Je vient de terminer la > transformation de l'exemple fourni sur la page en WinDev 7.5. > Franchement c'est bluffant au niveau de la gestion de feuilles/filtres. > Inconvénient c'est que l'arbre peut vitre être détruit si on ne > gère pas les transactions lors des phase d'insert / delete vu que tous > es éléments se gèrent les uns les autres. > > L'affichage en TV est facilement appréhendable. Reste à cabler > l'insertion dans le treeview et le drag & drop.
Bonjour, Avez vous essayé avec des volumes importants ?
Envoi moi un exemple avec 2 millions de lignes je te dirai ce que çà donne ^^
j'ai abandonné cette modélisation à cause de l'ajout/suppression qui nécessite un update de toutes les bornes gauche et droites. Effectivement, il faut de toute façon gérer les modifs par transactio n. mais est-ce bien réaliste sur de gros volumes ?
Christophe Charron
a écrit :
B. Neve a écrit :
Si ce type de modélisation vous intéresse, je ne peux que vous recommander de consulter le produit nommé "Caché" à l'adresse suivante...
http://www.intersystems.fr
Na pas confondre une base OO avec une base Relationnelle dans laquelle on utilise une représentation intervallaire. ce n'est pas du tout la même chose.
Pour en revenir à notre gestion intervallaire. Je vient de terminer la transformation de l'exemple fourni sur la page en WinDev 7.5. Franchement c'est bluffant au niveau de la gestion de feuilles/filtres. Inconvénient c'est que l'arbre peut vitre être détruit si on ne gère pas les transactions lors des phase d'insert / delete vu que tous les éléments se gèrent les uns les autres.
L'affichage en TV est facilement appréhendable. Reste à cabler l'insertion dans le treeview et le drag & drop.
-- Emmanuel Lecoester
Bonjour, avec quel SI as-tu fait tes tests ? Je suis interessé si MySQL ou PostgreSQL ...
-- Cordialement Christophe Charron
elecoest@gmail.com a écrit :
B. Neve a écrit :
Si ce type de modélisation vous intéresse, je ne peux que vous recommander
de consulter le produit nommé "Caché" à l'adresse suivante...
http://www.intersystems.fr
Na pas confondre une base OO avec une base Relationnelle dans laquelle
on utilise une représentation intervallaire. ce n'est pas du tout la
même chose.
Pour en revenir à notre gestion intervallaire. Je vient de terminer la
transformation de l'exemple fourni sur la page en WinDev 7.5.
Franchement c'est bluffant au niveau de la gestion de feuilles/filtres.
Inconvénient c'est que l'arbre peut vitre être détruit si on ne
gère pas les transactions lors des phase d'insert / delete vu que tous
les éléments se gèrent les uns les autres.
L'affichage en TV est facilement appréhendable. Reste à cabler
l'insertion dans le treeview et le drag & drop.
--
Emmanuel Lecoester
Bonjour,
avec quel SI as-tu fait tes tests ? Je suis interessé si MySQL ou
PostgreSQL ...
Si ce type de modélisation vous intéresse, je ne peux que vous recommander de consulter le produit nommé "Caché" à l'adresse suivante...
http://www.intersystems.fr
Na pas confondre une base OO avec une base Relationnelle dans laquelle on utilise une représentation intervallaire. ce n'est pas du tout la même chose.
Pour en revenir à notre gestion intervallaire. Je vient de terminer la transformation de l'exemple fourni sur la page en WinDev 7.5. Franchement c'est bluffant au niveau de la gestion de feuilles/filtres. Inconvénient c'est que l'arbre peut vitre être détruit si on ne gère pas les transactions lors des phase d'insert / delete vu que tous les éléments se gèrent les uns les autres.
L'affichage en TV est facilement appréhendable. Reste à cabler l'insertion dans le treeview et le drag & drop.
-- Emmanuel Lecoester
Bonjour, avec quel SI as-tu fait tes tests ? Je suis interessé si MySQL ou PostgreSQL ...
-- Cordialement Christophe Charron
elecoest
Christophe Charron a écrit :
a écrit : > B. Neve a écrit : > > >>Si ce type de modélisation vous intéresse, je ne peux que vous reco mmander >>de consulter le produit nommé "Caché" à l'adresse suivante... >> >>http://www.intersystems.fr > > > Na pas confondre une base OO avec une base Relationnelle dans laquelle > on utilise une représentation intervallaire. ce n'est pas du tout la > même chose. > > Pour en revenir à notre gestion intervallaire. Je vient de terminer la > transformation de l'exemple fourni sur la page en WinDev 7.5. > Franchement c'est bluffant au niveau de la gestion de feuilles/filtres. > Inconvénient c'est que l'arbre peut vitre être détruit si on ne > gère pas les transactions lors des phase d'insert / delete vu que tous > les éléments se gèrent les uns les autres. > > L'affichage en TV est facilement appréhendable. Reste à cabler > l'insertion dans le treeview et le drag & drop. > > -- > Emmanuel Lecoester > Bonjour, avec quel SI as-tu fait tes tests ? Je suis interessé si MySQL ou PostgreSQL ...
Avec HF 7.5. Je rech pour le moment une nomenclature assez volumineuse. Juste pour voir l'impact des update sur le temps d'insertion d'un nouvel element. si vous avez des pistes je suis preneur.
Christophe Charron a écrit :
elecoest@gmail.com a écrit :
> B. Neve a écrit :
>
>
>>Si ce type de modélisation vous intéresse, je ne peux que vous reco mmander
>>de consulter le produit nommé "Caché" à l'adresse suivante...
>>
>>http://www.intersystems.fr
>
>
> Na pas confondre une base OO avec une base Relationnelle dans laquelle
> on utilise une représentation intervallaire. ce n'est pas du tout la
> même chose.
>
> Pour en revenir à notre gestion intervallaire. Je vient de terminer la
> transformation de l'exemple fourni sur la page en WinDev 7.5.
> Franchement c'est bluffant au niveau de la gestion de feuilles/filtres.
> Inconvénient c'est que l'arbre peut vitre être détruit si on ne
> gère pas les transactions lors des phase d'insert / delete vu que tous
> les éléments se gèrent les uns les autres.
>
> L'affichage en TV est facilement appréhendable. Reste à cabler
> l'insertion dans le treeview et le drag & drop.
>
> --
> Emmanuel Lecoester
>
Bonjour,
avec quel SI as-tu fait tes tests ? Je suis interessé si MySQL ou
PostgreSQL ...
Avec HF 7.5. Je rech pour le moment une nomenclature assez volumineuse.
Juste pour voir l'impact des update sur le temps d'insertion d'un
nouvel element. si vous avez des pistes je suis preneur.
a écrit : > B. Neve a écrit : > > >>Si ce type de modélisation vous intéresse, je ne peux que vous reco mmander >>de consulter le produit nommé "Caché" à l'adresse suivante... >> >>http://www.intersystems.fr > > > Na pas confondre une base OO avec une base Relationnelle dans laquelle > on utilise une représentation intervallaire. ce n'est pas du tout la > même chose. > > Pour en revenir à notre gestion intervallaire. Je vient de terminer la > transformation de l'exemple fourni sur la page en WinDev 7.5. > Franchement c'est bluffant au niveau de la gestion de feuilles/filtres. > Inconvénient c'est que l'arbre peut vitre être détruit si on ne > gère pas les transactions lors des phase d'insert / delete vu que tous > les éléments se gèrent les uns les autres. > > L'affichage en TV est facilement appréhendable. Reste à cabler > l'insertion dans le treeview et le drag & drop. > > -- > Emmanuel Lecoester > Bonjour, avec quel SI as-tu fait tes tests ? Je suis interessé si MySQL ou PostgreSQL ...
Avec HF 7.5. Je rech pour le moment une nomenclature assez volumineuse. Juste pour voir l'impact des update sur le temps d'insertion d'un nouvel element. si vous avez des pistes je suis preneur.
