voici un test sur un duron700 (une machine la plus faible que j'ai trouvé
avec HD déplorable 128mo ram .....) de openqm
GLOBAL FILE STATISTICS 11:55:17
....System .....Total .......... ...Average
.....Total ..this run ...Per sec ...per sec
Period 00:02:37 00:02:28
Opens 92 86 0 0.6
Reads 535310 535289 0 3616.8
Writes 2 1 0 0.0
Deletes 4 2 0 0.0
Clears 0 0 0 0.0
Selects 1 1 0 0.0
Splits 0 0 0 0.0
Merges 0 0 0 0.0
AK Reads 0 0 0 0.0
AK Writes 0 0 0 0.0
AK Deletes 0 0 0 0.0
Press any key to quit
la requête lancé pour le test contient la gestion de 90 items et l'équivalent
de 58 jointures en SQL le tout sur 5 fichiers multivalué
(en SQL il aurait fallu 63 tables)
Dr Thierry HOLZ
helios services
180 rue de la croix du chene
60250 HEILLES
www.openqm.com02.net
www.pick.com02.net
voici un test sur un duron700 (une machine la plus faible que j'ai trouvé
avec HD déplorable 128mo ram .....) de openqm
GLOBAL FILE STATISTICS 11:55:17
....System .....Total .......... ...Average
.....Total ..this run ...Per sec ...per sec
Period 00:02:37 00:02:28
Opens 92 86 0 0.6
Reads 535310 535289 0 3616.8
Writes 2 1 0 0.0
Deletes 4 2 0 0.0
Clears 0 0 0 0.0
Selects 1 1 0 0.0
Splits 0 0 0 0.0
Merges 0 0 0 0.0
AK Reads 0 0 0 0.0
AK Writes 0 0 0 0.0
AK Deletes 0 0 0 0.0
Press any key to quit
la requête lancé pour le test contient la gestion de 90 items et l'équivalent
de 58 jointures en SQL le tout sur 5 fichiers multivalué
(en SQL il aurait fallu 63 tables)
Dr Thierry HOLZ
helios services
180 rue de la croix du chene
60250 HEILLES
www.openqm.com02.net
www.pick.com02.net
voici un test sur un duron700 (une machine la plus faible que j'ai trouvé
avec HD déplorable 128mo ram .....) de openqm
GLOBAL FILE STATISTICS 11:55:17
....System .....Total .......... ...Average
.....Total ..this run ...Per sec ...per sec
Period 00:02:37 00:02:28
Opens 92 86 0 0.6
Reads 535310 535289 0 3616.8
Writes 2 1 0 0.0
Deletes 4 2 0 0.0
Clears 0 0 0 0.0
Selects 1 1 0 0.0
Splits 0 0 0 0.0
Merges 0 0 0 0.0
AK Reads 0 0 0 0.0
AK Writes 0 0 0 0.0
AK Deletes 0 0 0 0.0
Press any key to quit
la requête lancé pour le test contient la gestion de 90 items et l'équivalent
de 58 jointures en SQL le tout sur 5 fichiers multivalué
(en SQL il aurait fallu 63 tables)
Dr Thierry HOLZ
helios services
180 rue de la croix du chene
60250 HEILLES
www.openqm.com02.net
www.pick.com02.net
helios avait soumis l'idée :voici un test sur un duron700 (une machine la plus faible que j'ai
trouvé avec HD déplorable 128mo ram .....) de openqm
GLOBAL FILE STATISTICS 11:55:17
....System .....Total .......... ...Average
.....Total ..this run ...Per sec ...per sec
Period 00:02:37 00:02:28
Opens 92 86 0 0.6
Reads 535310 535289 0 3616.8
Writes 2 1 0 0.0
Deletes 4 2 0 0.0
Clears 0 0 0 0.0
Selects 1 1 0 0.0
Splits 0 0 0 0.0
Merges 0 0 0 0.0
AK Reads 0 0 0 0.0
AK Writes 0 0 0 0.0
AK Deletes 0 0 0 0.0
Press any key to quit
la requête lancé pour le test contient la gestion de 90 items et
l'équivalent de 58 jointures en SQL le tout sur 5 fichiers multivalué
(en SQL il aurait fallu 63 tables)
Dr Thierry HOLZ
helios services
180 rue de la croix du chene
60250 HEILLES
www.openqm.com02.net
www.pick.com02.net
Bonjour,
Est-ce que vous pouvez publier un petit jeu d'essais et la structure des
données ? Pour avoir un petit aperçu...
Cordialement
helios avait soumis l'idée :
voici un test sur un duron700 (une machine la plus faible que j'ai
trouvé avec HD déplorable 128mo ram .....) de openqm
GLOBAL FILE STATISTICS 11:55:17
....System .....Total .......... ...Average
.....Total ..this run ...Per sec ...per sec
Period 00:02:37 00:02:28
Opens 92 86 0 0.6
Reads 535310 535289 0 3616.8
Writes 2 1 0 0.0
Deletes 4 2 0 0.0
Clears 0 0 0 0.0
Selects 1 1 0 0.0
Splits 0 0 0 0.0
Merges 0 0 0 0.0
AK Reads 0 0 0 0.0
AK Writes 0 0 0 0.0
AK Deletes 0 0 0 0.0
Press any key to quit
la requête lancé pour le test contient la gestion de 90 items et
l'équivalent de 58 jointures en SQL le tout sur 5 fichiers multivalué
(en SQL il aurait fallu 63 tables)
Dr Thierry HOLZ
helios services
180 rue de la croix du chene
60250 HEILLES
www.openqm.com02.net
www.pick.com02.net
Bonjour,
Est-ce que vous pouvez publier un petit jeu d'essais et la structure des
données ? Pour avoir un petit aperçu...
Cordialement
helios avait soumis l'idée :voici un test sur un duron700 (une machine la plus faible que j'ai
trouvé avec HD déplorable 128mo ram .....) de openqm
GLOBAL FILE STATISTICS 11:55:17
....System .....Total .......... ...Average
.....Total ..this run ...Per sec ...per sec
Period 00:02:37 00:02:28
Opens 92 86 0 0.6
Reads 535310 535289 0 3616.8
Writes 2 1 0 0.0
Deletes 4 2 0 0.0
Clears 0 0 0 0.0
Selects 1 1 0 0.0
Splits 0 0 0 0.0
Merges 0 0 0 0.0
AK Reads 0 0 0 0.0
AK Writes 0 0 0 0.0
AK Deletes 0 0 0 0.0
Press any key to quit
la requête lancé pour le test contient la gestion de 90 items et
l'équivalent de 58 jointures en SQL le tout sur 5 fichiers multivalué
(en SQL il aurait fallu 63 tables)
Dr Thierry HOLZ
helios services
180 rue de la croix du chene
60250 HEILLES
www.openqm.com02.net
www.pick.com02.net
Bonjour,
Est-ce que vous pouvez publier un petit jeu d'essais et la structure des
données ? Pour avoir un petit aperçu...
Cordialement
Gilles TOURREAU a écrit :helios avait soumis l'idée :voici un test sur un duron700 (une machine la plus faible que j'ai trouvé
avec HD déplorable 128mo ram .....) de openqm
GLOBAL FILE STATISTICS 11:55:17
....System .....Total .......... ...Average
.....Total ..this run ...Per sec ...per sec
Period 00:02:37 00:02:28
Opens 92 86 0 0.6
Reads 535310 535289 0 3616.8
Writes 2 1 0 0.0
Deletes 4 2 0 0.0
Clears 0 0 0 0.0
Selects 1 1 0 0.0
Splits 0 0 0 0.0
Merges 0 0 0 0.0
AK Reads 0 0 0 0.0
AK Writes 0 0 0 0.0
AK Deletes 0 0 0 0.0
Press any key to quit
la requête lancé pour le test contient la gestion de 90 items et
l'équivalent de 58 jointures en SQL le tout sur 5 fichiers multivalué
(en SQL il aurait fallu 63 tables)
Dr Thierry HOLZ
helios services
180 rue de la croix du chene
60250 HEILLES
www.openqm.com02.net
www.pick.com02.net
Bonjour,
Est-ce que vous pouvez publier un petit jeu d'essais et la structure des
données ? Pour avoir un petit aperçu...
Cordialement
il a 5 fichiers MV
le fichier principal fait l'equivalent de 58 jointures SQL sur les 4 autres
les jointures etant vers des champs MV ceux ci sont chacun équivalent à une
table SQL
le fichier principal à 11430 articles , les 4 autres ont 1973, 519, 136 et
2245 articles
certain jointures renvois elles memes sur des jointures qui renvois sur des
jointures
la lecture des stat sont suffisament parlante pour voir la performance
style 535000 lectures en 150secondes une base SQL arrive a quel niveau sur
un duron 700 ?
Gilles TOURREAU a écrit :
helios avait soumis l'idée :
voici un test sur un duron700 (une machine la plus faible que j'ai trouvé
avec HD déplorable 128mo ram .....) de openqm
GLOBAL FILE STATISTICS 11:55:17
....System .....Total .......... ...Average
.....Total ..this run ...Per sec ...per sec
Period 00:02:37 00:02:28
Opens 92 86 0 0.6
Reads 535310 535289 0 3616.8
Writes 2 1 0 0.0
Deletes 4 2 0 0.0
Clears 0 0 0 0.0
Selects 1 1 0 0.0
Splits 0 0 0 0.0
Merges 0 0 0 0.0
AK Reads 0 0 0 0.0
AK Writes 0 0 0 0.0
AK Deletes 0 0 0 0.0
Press any key to quit
la requête lancé pour le test contient la gestion de 90 items et
l'équivalent de 58 jointures en SQL le tout sur 5 fichiers multivalué
(en SQL il aurait fallu 63 tables)
Dr Thierry HOLZ
helios services
180 rue de la croix du chene
60250 HEILLES
www.openqm.com02.net
www.pick.com02.net
Bonjour,
Est-ce que vous pouvez publier un petit jeu d'essais et la structure des
données ? Pour avoir un petit aperçu...
Cordialement
il a 5 fichiers MV
le fichier principal fait l'equivalent de 58 jointures SQL sur les 4 autres
les jointures etant vers des champs MV ceux ci sont chacun équivalent à une
table SQL
le fichier principal à 11430 articles , les 4 autres ont 1973, 519, 136 et
2245 articles
certain jointures renvois elles memes sur des jointures qui renvois sur des
jointures
la lecture des stat sont suffisament parlante pour voir la performance
style 535000 lectures en 150secondes une base SQL arrive a quel niveau sur
un duron 700 ?
Gilles TOURREAU a écrit :helios avait soumis l'idée :voici un test sur un duron700 (une machine la plus faible que j'ai trouvé
avec HD déplorable 128mo ram .....) de openqm
GLOBAL FILE STATISTICS 11:55:17
....System .....Total .......... ...Average
.....Total ..this run ...Per sec ...per sec
Period 00:02:37 00:02:28
Opens 92 86 0 0.6
Reads 535310 535289 0 3616.8
Writes 2 1 0 0.0
Deletes 4 2 0 0.0
Clears 0 0 0 0.0
Selects 1 1 0 0.0
Splits 0 0 0 0.0
Merges 0 0 0 0.0
AK Reads 0 0 0 0.0
AK Writes 0 0 0 0.0
AK Deletes 0 0 0 0.0
Press any key to quit
la requête lancé pour le test contient la gestion de 90 items et
l'équivalent de 58 jointures en SQL le tout sur 5 fichiers multivalué
(en SQL il aurait fallu 63 tables)
Dr Thierry HOLZ
helios services
180 rue de la croix du chene
60250 HEILLES
www.openqm.com02.net
www.pick.com02.net
Bonjour,
Est-ce que vous pouvez publier un petit jeu d'essais et la structure des
données ? Pour avoir un petit aperçu...
Cordialement
il a 5 fichiers MV
le fichier principal fait l'equivalent de 58 jointures SQL sur les 4 autres
les jointures etant vers des champs MV ceux ci sont chacun équivalent à une
table SQL
le fichier principal à 11430 articles , les 4 autres ont 1973, 519, 136 et
2245 articles
certain jointures renvois elles memes sur des jointures qui renvois sur des
jointures
la lecture des stat sont suffisament parlante pour voir la performance
style 535000 lectures en 150secondes une base SQL arrive a quel niveau sur
un duron 700 ?
helios avait prétendu :Gilles TOURREAU a écrit :helios avait soumis l'idée :voici un test sur un duron700 (une machine la plus faible que j'ai
trouvé avec HD déplorable 128mo ram .....) de openqm
GLOBAL FILE STATISTICS 11:55:17
....System .....Total .......... ...Average
.....Total ..this run ...Per sec ...per sec
Period 00:02:37 00:02:28
Opens 92 86 0 0.6
Reads 535310 535289 0 3616.8
Writes 2 1 0 0.0
Deletes 4 2 0 0.0
Clears 0 0 0 0.0
Selects 1 1 0 0.0
Splits 0 0 0 0.0
Merges 0 0 0 0.0
AK Reads 0 0 0 0.0
AK Writes 0 0 0 0.0
AK Deletes 0 0 0 0.0
Press any key to quit
la requête lancé pour le test contient la gestion de 90 items et
l'équivalent de 58 jointures en SQL le tout sur 5 fichiers multivalué
(en SQL il aurait fallu 63 tables)
Dr Thierry HOLZ
helios services
180 rue de la croix du chene
60250 HEILLES
www.openqm.com02.net
www.pick.com02.net
Bonjour,
Est-ce que vous pouvez publier un petit jeu d'essais et la structure
des données ? Pour avoir un petit aperçu...
Cordialement
il a 5 fichiers MV
le fichier principal fait l'equivalent de 58 jointures SQL sur les 4
autres les jointures etant vers des champs MV ceux ci sont chacun
équivalent à une table SQL
le fichier principal à 11430 articles , les 4 autres ont 1973, 519,
136 et 2245 articles
certain jointures renvois elles memes sur des jointures qui renvois
sur des jointures
la lecture des stat sont suffisament parlante pour voir la performance
style 535000 lectures en 150secondes une base SQL arrive a quel
niveau sur un duron 700 ?
Ca ok, mais pouvez expliquer qu'elle était le but de cette
implémentation ainsi que les structures utilisées...
Exemple :
"On souhaite mettre en place un système de facturation".
On à donc 3 tables :
- Client
* Nom
* Prénom
* etc...
- Facture
* IdFac
* N°
* Montant
* etc...
- Lignes
* IdFac
* Désignation
* etc...
Cordialement
helios avait prétendu :
Gilles TOURREAU a écrit :
helios avait soumis l'idée :
voici un test sur un duron700 (une machine la plus faible que j'ai
trouvé avec HD déplorable 128mo ram .....) de openqm
GLOBAL FILE STATISTICS 11:55:17
....System .....Total .......... ...Average
.....Total ..this run ...Per sec ...per sec
Period 00:02:37 00:02:28
Opens 92 86 0 0.6
Reads 535310 535289 0 3616.8
Writes 2 1 0 0.0
Deletes 4 2 0 0.0
Clears 0 0 0 0.0
Selects 1 1 0 0.0
Splits 0 0 0 0.0
Merges 0 0 0 0.0
AK Reads 0 0 0 0.0
AK Writes 0 0 0 0.0
AK Deletes 0 0 0 0.0
Press any key to quit
la requête lancé pour le test contient la gestion de 90 items et
l'équivalent de 58 jointures en SQL le tout sur 5 fichiers multivalué
(en SQL il aurait fallu 63 tables)
Dr Thierry HOLZ
helios services
180 rue de la croix du chene
60250 HEILLES
www.openqm.com02.net
www.pick.com02.net
Bonjour,
Est-ce que vous pouvez publier un petit jeu d'essais et la structure
des données ? Pour avoir un petit aperçu...
Cordialement
il a 5 fichiers MV
le fichier principal fait l'equivalent de 58 jointures SQL sur les 4
autres les jointures etant vers des champs MV ceux ci sont chacun
équivalent à une table SQL
le fichier principal à 11430 articles , les 4 autres ont 1973, 519,
136 et 2245 articles
certain jointures renvois elles memes sur des jointures qui renvois
sur des jointures
la lecture des stat sont suffisament parlante pour voir la performance
style 535000 lectures en 150secondes une base SQL arrive a quel
niveau sur un duron 700 ?
Ca ok, mais pouvez expliquer qu'elle était le but de cette
implémentation ainsi que les structures utilisées...
Exemple :
"On souhaite mettre en place un système de facturation".
On à donc 3 tables :
- Client
* Nom
* Prénom
* etc...
- Facture
* IdFac
* N°
* Montant
* etc...
- Lignes
* IdFac
* Désignation
* etc...
Cordialement
helios avait prétendu :Gilles TOURREAU a écrit :helios avait soumis l'idée :voici un test sur un duron700 (une machine la plus faible que j'ai
trouvé avec HD déplorable 128mo ram .....) de openqm
GLOBAL FILE STATISTICS 11:55:17
....System .....Total .......... ...Average
.....Total ..this run ...Per sec ...per sec
Period 00:02:37 00:02:28
Opens 92 86 0 0.6
Reads 535310 535289 0 3616.8
Writes 2 1 0 0.0
Deletes 4 2 0 0.0
Clears 0 0 0 0.0
Selects 1 1 0 0.0
Splits 0 0 0 0.0
Merges 0 0 0 0.0
AK Reads 0 0 0 0.0
AK Writes 0 0 0 0.0
AK Deletes 0 0 0 0.0
Press any key to quit
la requête lancé pour le test contient la gestion de 90 items et
l'équivalent de 58 jointures en SQL le tout sur 5 fichiers multivalué
(en SQL il aurait fallu 63 tables)
Dr Thierry HOLZ
helios services
180 rue de la croix du chene
60250 HEILLES
www.openqm.com02.net
www.pick.com02.net
Bonjour,
Est-ce que vous pouvez publier un petit jeu d'essais et la structure
des données ? Pour avoir un petit aperçu...
Cordialement
il a 5 fichiers MV
le fichier principal fait l'equivalent de 58 jointures SQL sur les 4
autres les jointures etant vers des champs MV ceux ci sont chacun
équivalent à une table SQL
le fichier principal à 11430 articles , les 4 autres ont 1973, 519,
136 et 2245 articles
certain jointures renvois elles memes sur des jointures qui renvois
sur des jointures
la lecture des stat sont suffisament parlante pour voir la performance
style 535000 lectures en 150secondes une base SQL arrive a quel
niveau sur un duron 700 ?
Ca ok, mais pouvez expliquer qu'elle était le but de cette
implémentation ainsi que les structures utilisées...
Exemple :
"On souhaite mettre en place un système de facturation".
On à donc 3 tables :
- Client
* Nom
* Prénom
* etc...
- Facture
* IdFac
* N°
* Montant
* etc...
- Lignes
* IdFac
* Désignation
* etc...
Cordialement
Gilles TOURREAU a écrit :helios avait prétendu :Gilles TOURREAU a écrit :helios avait soumis l'idée :voici un test sur un duron700 (une machine la plus faible que j'ai
trouvé avec HD déplorable 128mo ram .....) de openqm
GLOBAL FILE STATISTICS 11:55:17
....System .....Total .......... ...Average
.....Total ..this run ...Per sec ...per sec
Period 00:02:37 00:02:28
Opens 92 86 0 0.6
Reads 535310 535289 0 3616.8
Writes 2 1 0 0.0
Deletes 4 2 0 0.0
Clears 0 0 0 0.0
Selects 1 1 0 0.0
Splits 0 0 0 0.0
Merges 0 0 0 0.0
AK Reads 0 0 0 0.0
AK Writes 0 0 0 0.0
AK Deletes 0 0 0 0.0
Press any key to quit
la requête lancé pour le test contient la gestion de 90 items et
l'équivalent de 58 jointures en SQL le tout sur 5 fichiers multivalué
(en SQL il aurait fallu 63 tables)
Dr Thierry HOLZ
helios services
180 rue de la croix du chene
60250 HEILLES
www.openqm.com02.net
www.pick.com02.net
Bonjour,
Est-ce que vous pouvez publier un petit jeu d'essais et la structure des
données ? Pour avoir un petit aperçu...
Cordialement
il a 5 fichiers MV
le fichier principal fait l'equivalent de 58 jointures SQL sur les 4
autres les jointures etant vers des champs MV ceux ci sont chacun
équivalent à une table SQL
le fichier principal à 11430 articles , les 4 autres ont 1973, 519, 136
et 2245 articles
certain jointures renvois elles memes sur des jointures qui renvois sur
des jointures
la lecture des stat sont suffisament parlante pour voir la performance
style 535000 lectures en 150secondes une base SQL arrive a quel niveau
sur un duron 700 ?
Ca ok, mais pouvez expliquer qu'elle était le but de cette implémentation
ainsi que les structures utilisées...
Exemple :
"On souhaite mettre en place un système de facturation".
On à donc 3 tables :
- Client
* Nom
* Prénom
* etc...
- Facture
* IdFac
* N°
* Montant
* etc...
- Lignes
* IdFac
* Désignation
* etc...
Cordialement
cette implémentation était la gestion du EPASQY78 (gestion fonciere de la
communauté de commune de St quentin en Yveline)
donc il y a avait 11430 parcelles à gérer avec les historiques de vente achat
propriétaire notaire vendeur acheteur promoteur .......
cette implantation PICK à été migres vers XML dans le cadre d'une gestion
documentaire plus globale (j'étais le prestataire chargé de la migration)
Gilles TOURREAU a écrit :
helios avait prétendu :
Gilles TOURREAU a écrit :
helios avait soumis l'idée :
voici un test sur un duron700 (une machine la plus faible que j'ai
trouvé avec HD déplorable 128mo ram .....) de openqm
GLOBAL FILE STATISTICS 11:55:17
....System .....Total .......... ...Average
.....Total ..this run ...Per sec ...per sec
Period 00:02:37 00:02:28
Opens 92 86 0 0.6
Reads 535310 535289 0 3616.8
Writes 2 1 0 0.0
Deletes 4 2 0 0.0
Clears 0 0 0 0.0
Selects 1 1 0 0.0
Splits 0 0 0 0.0
Merges 0 0 0 0.0
AK Reads 0 0 0 0.0
AK Writes 0 0 0 0.0
AK Deletes 0 0 0 0.0
Press any key to quit
la requête lancé pour le test contient la gestion de 90 items et
l'équivalent de 58 jointures en SQL le tout sur 5 fichiers multivalué
(en SQL il aurait fallu 63 tables)
Dr Thierry HOLZ
helios services
180 rue de la croix du chene
60250 HEILLES
www.openqm.com02.net
www.pick.com02.net
Bonjour,
Est-ce que vous pouvez publier un petit jeu d'essais et la structure des
données ? Pour avoir un petit aperçu...
Cordialement
il a 5 fichiers MV
le fichier principal fait l'equivalent de 58 jointures SQL sur les 4
autres les jointures etant vers des champs MV ceux ci sont chacun
équivalent à une table SQL
le fichier principal à 11430 articles , les 4 autres ont 1973, 519, 136
et 2245 articles
certain jointures renvois elles memes sur des jointures qui renvois sur
des jointures
la lecture des stat sont suffisament parlante pour voir la performance
style 535000 lectures en 150secondes une base SQL arrive a quel niveau
sur un duron 700 ?
Ca ok, mais pouvez expliquer qu'elle était le but de cette implémentation
ainsi que les structures utilisées...
Exemple :
"On souhaite mettre en place un système de facturation".
On à donc 3 tables :
- Client
* Nom
* Prénom
* etc...
- Facture
* IdFac
* N°
* Montant
* etc...
- Lignes
* IdFac
* Désignation
* etc...
Cordialement
cette implémentation était la gestion du EPASQY78 (gestion fonciere de la
communauté de commune de St quentin en Yveline)
donc il y a avait 11430 parcelles à gérer avec les historiques de vente achat
propriétaire notaire vendeur acheteur promoteur .......
cette implantation PICK à été migres vers XML dans le cadre d'une gestion
documentaire plus globale (j'étais le prestataire chargé de la migration)
Gilles TOURREAU a écrit :helios avait prétendu :Gilles TOURREAU a écrit :helios avait soumis l'idée :voici un test sur un duron700 (une machine la plus faible que j'ai
trouvé avec HD déplorable 128mo ram .....) de openqm
GLOBAL FILE STATISTICS 11:55:17
....System .....Total .......... ...Average
.....Total ..this run ...Per sec ...per sec
Period 00:02:37 00:02:28
Opens 92 86 0 0.6
Reads 535310 535289 0 3616.8
Writes 2 1 0 0.0
Deletes 4 2 0 0.0
Clears 0 0 0 0.0
Selects 1 1 0 0.0
Splits 0 0 0 0.0
Merges 0 0 0 0.0
AK Reads 0 0 0 0.0
AK Writes 0 0 0 0.0
AK Deletes 0 0 0 0.0
Press any key to quit
la requête lancé pour le test contient la gestion de 90 items et
l'équivalent de 58 jointures en SQL le tout sur 5 fichiers multivalué
(en SQL il aurait fallu 63 tables)
Dr Thierry HOLZ
helios services
180 rue de la croix du chene
60250 HEILLES
www.openqm.com02.net
www.pick.com02.net
Bonjour,
Est-ce que vous pouvez publier un petit jeu d'essais et la structure des
données ? Pour avoir un petit aperçu...
Cordialement
il a 5 fichiers MV
le fichier principal fait l'equivalent de 58 jointures SQL sur les 4
autres les jointures etant vers des champs MV ceux ci sont chacun
équivalent à une table SQL
le fichier principal à 11430 articles , les 4 autres ont 1973, 519, 136
et 2245 articles
certain jointures renvois elles memes sur des jointures qui renvois sur
des jointures
la lecture des stat sont suffisament parlante pour voir la performance
style 535000 lectures en 150secondes une base SQL arrive a quel niveau
sur un duron 700 ?
Ca ok, mais pouvez expliquer qu'elle était le but de cette implémentation
ainsi que les structures utilisées...
Exemple :
"On souhaite mettre en place un système de facturation".
On à donc 3 tables :
- Client
* Nom
* Prénom
* etc...
- Facture
* IdFac
* N°
* Montant
* etc...
- Lignes
* IdFac
* Désignation
* etc...
Cordialement
cette implémentation était la gestion du EPASQY78 (gestion fonciere de la
communauté de commune de St quentin en Yveline)
donc il y a avait 11430 parcelles à gérer avec les historiques de vente achat
propriétaire notaire vendeur acheteur promoteur .......
cette implantation PICK à été migres vers XML dans le cadre d'une gestion
documentaire plus globale (j'étais le prestataire chargé de la migration)
cette implémentation était la gestion du EPASQY78 (gestion fonciere de
la communauté de commune de St quentin en Yveline)
donc il y a avait 11430 parcelles à gérer avec les historiques de vente
achat propriétaire notaire vendeur acheteur promoteur .......
cette implantation PICK à été migres vers XML dans le cadre d'une
gestion documentaire plus globale (j'étais le prestataire chargé de la
migration)
cette implémentation était la gestion du EPASQY78 (gestion fonciere de
la communauté de commune de St quentin en Yveline)
donc il y a avait 11430 parcelles à gérer avec les historiques de vente
achat propriétaire notaire vendeur acheteur promoteur .......
cette implantation PICK à été migres vers XML dans le cadre d'une
gestion documentaire plus globale (j'étais le prestataire chargé de la
migration)
cette implémentation était la gestion du EPASQY78 (gestion fonciere de
la communauté de commune de St quentin en Yveline)
donc il y a avait 11430 parcelles à gérer avec les historiques de vente
achat propriétaire notaire vendeur acheteur promoteur .......
cette implantation PICK à été migres vers XML dans le cadre d'une
gestion documentaire plus globale (j'étais le prestataire chargé de la
migration)
helios vient de nous annoncer :Gilles TOURREAU a écrit :helios avait prétendu :Gilles TOURREAU a écrit :helios avait soumis l'idée :voici un test sur un duron700 (une machine la plus faible que j'ai
trouvé avec HD déplorable 128mo ram .....) de openqm
GLOBAL FILE STATISTICS 11:55:17
....System .....Total .......... ...Average
.....Total ..this run ...Per sec ...per sec
Period 00:02:37 00:02:28
Opens 92 86 0 0.6
Reads 535310 535289 0 3616.8
Writes 2 1 0 0.0
Deletes 4 2 0 0.0
Clears 0 0 0 0.0
Selects 1 1 0 0.0
Splits 0 0 0 0.0
Merges 0 0 0 0.0
AK Reads 0 0 0 0.0
AK Writes 0 0 0 0.0
AK Deletes 0 0 0 0.0
Press any key to quit
la requête lancé pour le test contient la gestion de 90 items et
l'équivalent de 58 jointures en SQL le tout sur 5 fichiers multivalué
(en SQL il aurait fallu 63 tables)
Dr Thierry HOLZ
helios services
180 rue de la croix du chene
60250 HEILLES
www.openqm.com02.net
www.pick.com02.net
Bonjour,
Est-ce que vous pouvez publier un petit jeu d'essais et la
structure des données ? Pour avoir un petit aperçu...
Cordialement
il a 5 fichiers MV
le fichier principal fait l'equivalent de 58 jointures SQL sur les 4
autres les jointures etant vers des champs MV ceux ci sont chacun
équivalent à une table SQL
le fichier principal à 11430 articles , les 4 autres ont 1973, 519,
136 et 2245 articles
certain jointures renvois elles memes sur des jointures qui renvois
sur des jointures
la lecture des stat sont suffisament parlante pour voir la performance
style 535000 lectures en 150secondes une base SQL arrive a quel
niveau sur un duron 700 ?
Ca ok, mais pouvez expliquer qu'elle était le but de cette
implémentation ainsi que les structures utilisées...
Exemple :
"On souhaite mettre en place un système de facturation".
On à donc 3 tables :
- Client
* Nom
* Prénom
* etc...
- Facture
* IdFac
* N°
* Montant
* etc...
- Lignes
* IdFac
* Désignation
* etc...
Cordialement
cette implémentation était la gestion du EPASQY78 (gestion fonciere de
la communauté de commune de St quentin en Yveline)
donc il y a avait 11430 parcelles à gérer avec les historiques de
vente achat propriétaire notaire vendeur acheteur promoteur .......
cette implantation PICK à été migres vers XML dans le cadre d'une
gestion documentaire plus globale (j'étais le prestataire chargé de la
migration)
Et comment était donc organisé ces données ?
helios vient de nous annoncer :
Gilles TOURREAU a écrit :
helios avait prétendu :
Gilles TOURREAU a écrit :
helios avait soumis l'idée :
voici un test sur un duron700 (une machine la plus faible que j'ai
trouvé avec HD déplorable 128mo ram .....) de openqm
GLOBAL FILE STATISTICS 11:55:17
....System .....Total .......... ...Average
.....Total ..this run ...Per sec ...per sec
Period 00:02:37 00:02:28
Opens 92 86 0 0.6
Reads 535310 535289 0 3616.8
Writes 2 1 0 0.0
Deletes 4 2 0 0.0
Clears 0 0 0 0.0
Selects 1 1 0 0.0
Splits 0 0 0 0.0
Merges 0 0 0 0.0
AK Reads 0 0 0 0.0
AK Writes 0 0 0 0.0
AK Deletes 0 0 0 0.0
Press any key to quit
la requête lancé pour le test contient la gestion de 90 items et
l'équivalent de 58 jointures en SQL le tout sur 5 fichiers multivalué
(en SQL il aurait fallu 63 tables)
Dr Thierry HOLZ
helios services
180 rue de la croix du chene
60250 HEILLES
www.openqm.com02.net
www.pick.com02.net
Bonjour,
Est-ce que vous pouvez publier un petit jeu d'essais et la
structure des données ? Pour avoir un petit aperçu...
Cordialement
il a 5 fichiers MV
le fichier principal fait l'equivalent de 58 jointures SQL sur les 4
autres les jointures etant vers des champs MV ceux ci sont chacun
équivalent à une table SQL
le fichier principal à 11430 articles , les 4 autres ont 1973, 519,
136 et 2245 articles
certain jointures renvois elles memes sur des jointures qui renvois
sur des jointures
la lecture des stat sont suffisament parlante pour voir la performance
style 535000 lectures en 150secondes une base SQL arrive a quel
niveau sur un duron 700 ?
Ca ok, mais pouvez expliquer qu'elle était le but de cette
implémentation ainsi que les structures utilisées...
Exemple :
"On souhaite mettre en place un système de facturation".
On à donc 3 tables :
- Client
* Nom
* Prénom
* etc...
- Facture
* IdFac
* N°
* Montant
* etc...
- Lignes
* IdFac
* Désignation
* etc...
Cordialement
cette implémentation était la gestion du EPASQY78 (gestion fonciere de
la communauté de commune de St quentin en Yveline)
donc il y a avait 11430 parcelles à gérer avec les historiques de
vente achat propriétaire notaire vendeur acheteur promoteur .......
cette implantation PICK à été migres vers XML dans le cadre d'une
gestion documentaire plus globale (j'étais le prestataire chargé de la
migration)
Et comment était donc organisé ces données ?
helios vient de nous annoncer :Gilles TOURREAU a écrit :helios avait prétendu :Gilles TOURREAU a écrit :helios avait soumis l'idée :voici un test sur un duron700 (une machine la plus faible que j'ai
trouvé avec HD déplorable 128mo ram .....) de openqm
GLOBAL FILE STATISTICS 11:55:17
....System .....Total .......... ...Average
.....Total ..this run ...Per sec ...per sec
Period 00:02:37 00:02:28
Opens 92 86 0 0.6
Reads 535310 535289 0 3616.8
Writes 2 1 0 0.0
Deletes 4 2 0 0.0
Clears 0 0 0 0.0
Selects 1 1 0 0.0
Splits 0 0 0 0.0
Merges 0 0 0 0.0
AK Reads 0 0 0 0.0
AK Writes 0 0 0 0.0
AK Deletes 0 0 0 0.0
Press any key to quit
la requête lancé pour le test contient la gestion de 90 items et
l'équivalent de 58 jointures en SQL le tout sur 5 fichiers multivalué
(en SQL il aurait fallu 63 tables)
Dr Thierry HOLZ
helios services
180 rue de la croix du chene
60250 HEILLES
www.openqm.com02.net
www.pick.com02.net
Bonjour,
Est-ce que vous pouvez publier un petit jeu d'essais et la
structure des données ? Pour avoir un petit aperçu...
Cordialement
il a 5 fichiers MV
le fichier principal fait l'equivalent de 58 jointures SQL sur les 4
autres les jointures etant vers des champs MV ceux ci sont chacun
équivalent à une table SQL
le fichier principal à 11430 articles , les 4 autres ont 1973, 519,
136 et 2245 articles
certain jointures renvois elles memes sur des jointures qui renvois
sur des jointures
la lecture des stat sont suffisament parlante pour voir la performance
style 535000 lectures en 150secondes une base SQL arrive a quel
niveau sur un duron 700 ?
Ca ok, mais pouvez expliquer qu'elle était le but de cette
implémentation ainsi que les structures utilisées...
Exemple :
"On souhaite mettre en place un système de facturation".
On à donc 3 tables :
- Client
* Nom
* Prénom
* etc...
- Facture
* IdFac
* N°
* Montant
* etc...
- Lignes
* IdFac
* Désignation
* etc...
Cordialement
cette implémentation était la gestion du EPASQY78 (gestion fonciere de
la communauté de commune de St quentin en Yveline)
donc il y a avait 11430 parcelles à gérer avec les historiques de
vente achat propriétaire notaire vendeur acheteur promoteur .......
cette implantation PICK à été migres vers XML dans le cadre d'une
gestion documentaire plus globale (j'étais le prestataire chargé de la
migration)
Et comment était donc organisé ces données ?
helios a écrit :cette implémentation était la gestion du EPASQY78 (gestion fonciere de
la communauté de commune de St quentin en Yveline)
donc il y a avait 11430 parcelles à gérer avec les historiques de
vente achat propriétaire notaire vendeur acheteur promoteur .......
cette implantation PICK à été migres vers XML dans le cadre d'une
gestion documentaire plus globale (j'étais le prestataire chargé de la
migration)
S'il y avait l'équivalent de 58 jointures, j'aimerais comprendre quelles
seraient les 58 relations correspondantes et leur utilité dans un schéma
relationnel ? Dans la gestion financiere d'une communauté de commune,
j'arrive pas trop à comprendre comment on peut en arriver a avoir besoin
d'une requete qui concerne simultanément sur 58 relations et donc 58
jointures !?
Merci.
helios a écrit :
cette implémentation était la gestion du EPASQY78 (gestion fonciere de
la communauté de commune de St quentin en Yveline)
donc il y a avait 11430 parcelles à gérer avec les historiques de
vente achat propriétaire notaire vendeur acheteur promoteur .......
cette implantation PICK à été migres vers XML dans le cadre d'une
gestion documentaire plus globale (j'étais le prestataire chargé de la
migration)
S'il y avait l'équivalent de 58 jointures, j'aimerais comprendre quelles
seraient les 58 relations correspondantes et leur utilité dans un schéma
relationnel ? Dans la gestion financiere d'une communauté de commune,
j'arrive pas trop à comprendre comment on peut en arriver a avoir besoin
d'une requete qui concerne simultanément sur 58 relations et donc 58
jointures !?
Merci.
helios a écrit :cette implémentation était la gestion du EPASQY78 (gestion fonciere de
la communauté de commune de St quentin en Yveline)
donc il y a avait 11430 parcelles à gérer avec les historiques de
vente achat propriétaire notaire vendeur acheteur promoteur .......
cette implantation PICK à été migres vers XML dans le cadre d'une
gestion documentaire plus globale (j'étais le prestataire chargé de la
migration)
S'il y avait l'équivalent de 58 jointures, j'aimerais comprendre quelles
seraient les 58 relations correspondantes et leur utilité dans un schéma
relationnel ? Dans la gestion financiere d'une communauté de commune,
j'arrive pas trop à comprendre comment on peut en arriver a avoir besoin
d'une requete qui concerne simultanément sur 58 relations et donc 58
jointures !?
Merci.
Pif a écrit :
helios a écrit :cette implémentation était la gestion du EPASQY78 (gestion fonciere de la
communauté de commune de St quentin en Yveline)
donc il y a avait 11430 parcelles à gérer avec les historiques de vente
achat propriétaire notaire vendeur acheteur promoteur .......
cette implantation PICK à été migres vers XML dans le cadre d'une gestion
documentaire plus globale (j'étais le prestataire chargé de la migration)
S'il y avait l'équivalent de 58 jointures, j'aimerais comprendre quelles
seraient les 58 relations correspondantes et leur utilité dans un schéma
relationnel ? Dans la gestion financiere d'une communauté de commune,
j'arrive pas trop à comprendre comment on peut en arriver a avoir besoin
d'une requete qui concerne simultanément sur 58 relations et donc 58
jointures !?
Merci.
pour changer le format des fichiers de MV à XML il faut que la requete fasse
simultanement toutes les jointures de la base pour la conversion
Pif a écrit :
helios a écrit :
cette implémentation était la gestion du EPASQY78 (gestion fonciere de la
communauté de commune de St quentin en Yveline)
donc il y a avait 11430 parcelles à gérer avec les historiques de vente
achat propriétaire notaire vendeur acheteur promoteur .......
cette implantation PICK à été migres vers XML dans le cadre d'une gestion
documentaire plus globale (j'étais le prestataire chargé de la migration)
S'il y avait l'équivalent de 58 jointures, j'aimerais comprendre quelles
seraient les 58 relations correspondantes et leur utilité dans un schéma
relationnel ? Dans la gestion financiere d'une communauté de commune,
j'arrive pas trop à comprendre comment on peut en arriver a avoir besoin
d'une requete qui concerne simultanément sur 58 relations et donc 58
jointures !?
Merci.
pour changer le format des fichiers de MV à XML il faut que la requete fasse
simultanement toutes les jointures de la base pour la conversion
Pif a écrit :
helios a écrit :cette implémentation était la gestion du EPASQY78 (gestion fonciere de la
communauté de commune de St quentin en Yveline)
donc il y a avait 11430 parcelles à gérer avec les historiques de vente
achat propriétaire notaire vendeur acheteur promoteur .......
cette implantation PICK à été migres vers XML dans le cadre d'une gestion
documentaire plus globale (j'étais le prestataire chargé de la migration)
S'il y avait l'équivalent de 58 jointures, j'aimerais comprendre quelles
seraient les 58 relations correspondantes et leur utilité dans un schéma
relationnel ? Dans la gestion financiere d'une communauté de commune,
j'arrive pas trop à comprendre comment on peut en arriver a avoir besoin
d'une requete qui concerne simultanément sur 58 relations et donc 58
jointures !?
Merci.
pour changer le format des fichiers de MV à XML il faut que la requete fasse
simultanement toutes les jointures de la base pour la conversion
Gilles TOURREAU a écrit :helios vient de nous annoncer :Gilles TOURREAU a écrit :helios avait prétendu :Gilles TOURREAU a écrit :helios avait soumis l'idée :voici un test sur un duron700 (une machine la plus faible que j'ai
trouvé avec HD déplorable 128mo ram .....) de openqm
GLOBAL FILE STATISTICS 11:55:17
....System .....Total .......... ...Average
.....Total ..this run ...Per sec ...per sec
Period 00:02:37 00:02:28
Opens 92 86 0 0.6
Reads 535310 535289 0 3616.8
Writes 2 1 0 0.0
Deletes 4 2 0 0.0
Clears 0 0 0 0.0
Selects 1 1 0 0.0
Splits 0 0 0 0.0
Merges 0 0 0 0.0
AK Reads 0 0 0 0.0
AK Writes 0 0 0 0.0
AK Deletes 0 0 0 0.0
Press any key to quit
la requête lancé pour le test contient la gestion de 90 items et
l'équivalent de 58 jointures en SQL le tout sur 5 fichiers multivalué
(en SQL il aurait fallu 63 tables)
Dr Thierry HOLZ
helios services
180 rue de la croix du chene
60250 HEILLES
www.openqm.com02.net
www.pick.com02.net
Bonjour,
Est-ce que vous pouvez publier un petit jeu d'essais et la structure
des données ? Pour avoir un petit aperçu...
Cordialement
il a 5 fichiers MV
le fichier principal fait l'equivalent de 58 jointures SQL sur les 4
autres les jointures etant vers des champs MV ceux ci sont chacun
équivalent à une table SQL
le fichier principal à 11430 articles , les 4 autres ont 1973, 519, 136
et 2245 articles
certain jointures renvois elles memes sur des jointures qui renvois sur
des jointures
la lecture des stat sont suffisament parlante pour voir la performance
style 535000 lectures en 150secondes une base SQL arrive a quel niveau
sur un duron 700 ?
Ca ok, mais pouvez expliquer qu'elle était le but de cette implémentation
ainsi que les structures utilisées...
Exemple :
"On souhaite mettre en place un système de facturation".
On à donc 3 tables :
- Client
* Nom
* Prénom
* etc...
- Facture
* IdFac
* N°
* Montant
* etc...
- Lignes
* IdFac
* Désignation
* etc...
Cordialement
cette implémentation était la gestion du EPASQY78 (gestion fonciere de la
communauté de commune de St quentin en Yveline)
donc il y a avait 11430 parcelles à gérer avec les historiques de vente
achat propriétaire notaire vendeur acheteur promoteur .......
cette implantation PICK à été migres vers XML dans le cadre d'une gestion
documentaire plus globale (j'étais le prestataire chargé de la migration)
Et comment était donc organisé ces données ?
il y a plus de 500 champs au total à décrire
Gilles TOURREAU a écrit :
helios vient de nous annoncer :
Gilles TOURREAU a écrit :
helios avait prétendu :
Gilles TOURREAU a écrit :
helios avait soumis l'idée :
voici un test sur un duron700 (une machine la plus faible que j'ai
trouvé avec HD déplorable 128mo ram .....) de openqm
GLOBAL FILE STATISTICS 11:55:17
....System .....Total .......... ...Average
.....Total ..this run ...Per sec ...per sec
Period 00:02:37 00:02:28
Opens 92 86 0 0.6
Reads 535310 535289 0 3616.8
Writes 2 1 0 0.0
Deletes 4 2 0 0.0
Clears 0 0 0 0.0
Selects 1 1 0 0.0
Splits 0 0 0 0.0
Merges 0 0 0 0.0
AK Reads 0 0 0 0.0
AK Writes 0 0 0 0.0
AK Deletes 0 0 0 0.0
Press any key to quit
la requête lancé pour le test contient la gestion de 90 items et
l'équivalent de 58 jointures en SQL le tout sur 5 fichiers multivalué
(en SQL il aurait fallu 63 tables)
Dr Thierry HOLZ
helios services
180 rue de la croix du chene
60250 HEILLES
www.openqm.com02.net
www.pick.com02.net
Bonjour,
Est-ce que vous pouvez publier un petit jeu d'essais et la structure
des données ? Pour avoir un petit aperçu...
Cordialement
il a 5 fichiers MV
le fichier principal fait l'equivalent de 58 jointures SQL sur les 4
autres les jointures etant vers des champs MV ceux ci sont chacun
équivalent à une table SQL
le fichier principal à 11430 articles , les 4 autres ont 1973, 519, 136
et 2245 articles
certain jointures renvois elles memes sur des jointures qui renvois sur
des jointures
la lecture des stat sont suffisament parlante pour voir la performance
style 535000 lectures en 150secondes une base SQL arrive a quel niveau
sur un duron 700 ?
Ca ok, mais pouvez expliquer qu'elle était le but de cette implémentation
ainsi que les structures utilisées...
Exemple :
"On souhaite mettre en place un système de facturation".
On à donc 3 tables :
- Client
* Nom
* Prénom
* etc...
- Facture
* IdFac
* N°
* Montant
* etc...
- Lignes
* IdFac
* Désignation
* etc...
Cordialement
cette implémentation était la gestion du EPASQY78 (gestion fonciere de la
communauté de commune de St quentin en Yveline)
donc il y a avait 11430 parcelles à gérer avec les historiques de vente
achat propriétaire notaire vendeur acheteur promoteur .......
cette implantation PICK à été migres vers XML dans le cadre d'une gestion
documentaire plus globale (j'étais le prestataire chargé de la migration)
Et comment était donc organisé ces données ?
il y a plus de 500 champs au total à décrire
Gilles TOURREAU a écrit :helios vient de nous annoncer :Gilles TOURREAU a écrit :helios avait prétendu :Gilles TOURREAU a écrit :helios avait soumis l'idée :voici un test sur un duron700 (une machine la plus faible que j'ai
trouvé avec HD déplorable 128mo ram .....) de openqm
GLOBAL FILE STATISTICS 11:55:17
....System .....Total .......... ...Average
.....Total ..this run ...Per sec ...per sec
Period 00:02:37 00:02:28
Opens 92 86 0 0.6
Reads 535310 535289 0 3616.8
Writes 2 1 0 0.0
Deletes 4 2 0 0.0
Clears 0 0 0 0.0
Selects 1 1 0 0.0
Splits 0 0 0 0.0
Merges 0 0 0 0.0
AK Reads 0 0 0 0.0
AK Writes 0 0 0 0.0
AK Deletes 0 0 0 0.0
Press any key to quit
la requête lancé pour le test contient la gestion de 90 items et
l'équivalent de 58 jointures en SQL le tout sur 5 fichiers multivalué
(en SQL il aurait fallu 63 tables)
Dr Thierry HOLZ
helios services
180 rue de la croix du chene
60250 HEILLES
www.openqm.com02.net
www.pick.com02.net
Bonjour,
Est-ce que vous pouvez publier un petit jeu d'essais et la structure
des données ? Pour avoir un petit aperçu...
Cordialement
il a 5 fichiers MV
le fichier principal fait l'equivalent de 58 jointures SQL sur les 4
autres les jointures etant vers des champs MV ceux ci sont chacun
équivalent à une table SQL
le fichier principal à 11430 articles , les 4 autres ont 1973, 519, 136
et 2245 articles
certain jointures renvois elles memes sur des jointures qui renvois sur
des jointures
la lecture des stat sont suffisament parlante pour voir la performance
style 535000 lectures en 150secondes une base SQL arrive a quel niveau
sur un duron 700 ?
Ca ok, mais pouvez expliquer qu'elle était le but de cette implémentation
ainsi que les structures utilisées...
Exemple :
"On souhaite mettre en place un système de facturation".
On à donc 3 tables :
- Client
* Nom
* Prénom
* etc...
- Facture
* IdFac
* N°
* Montant
* etc...
- Lignes
* IdFac
* Désignation
* etc...
Cordialement
cette implémentation était la gestion du EPASQY78 (gestion fonciere de la
communauté de commune de St quentin en Yveline)
donc il y a avait 11430 parcelles à gérer avec les historiques de vente
achat propriétaire notaire vendeur acheteur promoteur .......
cette implantation PICK à été migres vers XML dans le cadre d'une gestion
documentaire plus globale (j'étais le prestataire chargé de la migration)
Et comment était donc organisé ces données ?
il y a plus de 500 champs au total à décrire