PC SOFT

FORUMS PROFESSIONNELS
WINDEVWEBDEV et WINDEV Mobile

Accueil → WINDEV (précédentes versions) → le comportement de la base de données de windev
le comportement de la base de données de windev
Débuté par CHRISTY, 01 juil. 2015 13:25 - 10 réponses
Membre enregistré
30 messages
Posté le 01 juillet 2015 - 13:25
Bonjour à toute l'équipe windev super logiciel de dev.

J'ai découvert windev dans une société et cela m'a beaucoup intérèssé. moi même j'avais commencé en delphi.
ma question est celle-ci
la base me semble sensible. déjà en classique lorsque c'est en classique à un niveau donné elle devient lent.
Maintenant en client/serveur à partir de combien d'enregistrements l'accès aux données dans un fichier devient lent?
je dis en client/serveur parce que lorsqu'on a migré de classique vers client/serveur l'accès devient rapide.
Il ne faut pas que l'on achète la licence développer des applications dans des grandes structures et qu'on aie après ce problème de lenteur.
Merci à vous
Posté le 01 juillet 2015 - 14:12
Bonjour Christy,

Ca n'est pas du à la base, mais plus vraisemblablement au code utilisé.
Avec les bonnes clés dans les fichiers et la bonne logique, peut importe
le nombre d'enregistrement. HF reste rapide.

Maintenant, si tu fais des recherches non optimisées, de type contient,
par exemple, sans gérer de dictionnaire, ca va forcément ralentir vu que
chaque enreg du fichier devra être lu...

Donc, une bonne logique, un bon code, et pas de problème

Cordialement


--
Fabrice Harari
Consultant WinDev, WebDev et WinDev Mobile International

Disponible : WXShowroom.com, WXReplication (open source)
Bientôt : WXEDM (open source)
Plus d'information sur http://fabriceharari.com



J'ai découvert windev dans une société et cela m'a beaucoup intérèssé.
moi même j'avais commencé en delphi.
ma question est celle-ci
la base me semble sensible. déjà en classique lorsque c'est en classique
à un niveau donné elle devient lent.



Maintenant en client/serveur à partir de combien d'enregistrements
l'accès aux données dans un fichier devient lent?
je dis en client/serveur parce que lorsqu'on a migré de classique vers
client/serveur l'accès devient rapide.
Il ne faut pas que l'on achète la licence développer des applications
dans des grandes structures et qu'on aie après ce problème de lenteur.
Merci à vous
Membre enregistré
30 messages
Posté le 02 juillet 2015 - 09:57
Merci Fabrice

une question. quels sont les incovénients d'une recherche multicritère? c'est à dire une requête avec plusieurs paramètres.
Posté le 02 juillet 2015 - 12:13
Bonjour Christy

Aucun inconvénient si une clé composée adaptée existe (et toujours si
les conditions sont des conditions optimisées, cad égale, commence par,
plus grand que, etc)...

Cordialement


--
Fabrice Harari
Consultant WinDev, WebDev et WinDev Mobile International

Disponible : WXShowroom.com, WXReplication (open source)
Bientôt : WXEDM (open source)
Plus d'information sur http://fabriceharari.com


On 7/2/2015 1:57 AM, CHRISTY wrote:
Merci Fabrice

une question. quels sont les incovénients d'une recherche multicritère?
c'est à dire une requête avec plusieurs paramètres.
Membre enregistré
30 messages
Posté le 03 juillet 2015 - 10:38
Fabrice tu es vraiment à notre disposition.
tu animes très bien ce forum et félicitation.
J'ai été aussi sur ton site

Si un fichier c-à-d une table contient plusieurs clés, cela pose problème?
Quelle est la base de données mieux indiquée pour windev?
HFSQL, SQL serveur, oracle, mySQL, etc.
Merci à tous
Posté le 03 juillet 2015 - 12:35
Les comparaisons entre MySQL / SQLServeur ... ... etc, chacun va avoir un point de vue différent.
Si tu veux des comparaisons entre ces outils, il y a des tas de forum qui en parlent. Et l'interfaçage avec Windev ne change RIEN à l'affaire.

Avec HF, il y a un truc qui est peu connu des débutants, c'est la fonction hReindexe().
Quand des performances se dégradent avec le temps, très souvent, un simple hReindexe() permet de retrouver des performances très correctes.
Posté le 03 juillet 2015 - 13:40
Bonjour Christy,

> Si un fichier c-à-d une table contient plusieurs clés, cela pose problème?

Non, pas du tout...

Quelle est la base de données mieux indiquée pour windev?
HFSQL, SQL serveur, oracle, mySQL, etc.
Merci à tous


Ma préférence va à HFSQL. C'est la base native, donc la mieux intégrée
au langage. En plus :
- Elle fait la mise à jour automatique des fichiers de données quand on
change l'analyse, sans perte de données, bien sur (c'est la seule)
- Elle est dispo sur toutes les plateformes (windows, linux, android,
ios...) avec une compatibilité au niveau binaire (copie de fichiers
possible), c'est aussi la seule.
- elle est gratuite (pas la seule :-) )

Après l'utilisation de toutes les autres bases est possible, mais je ne
les utilise que quand une contrainte externe m'y oblige (partage de
données avec une autre appli, en général)

Cordialement


--
Fabrice Harari
Consultant WinDev, WebDev et WinDev Mobile International

Disponible : WXShowroom.com, WXReplication (open source)
Bientôt : WXEDM (open source)
Plus d'information sur http://fabriceharari.com
Membre enregistré
30 messages
Posté le 03 juillet 2015 - 13:47
Mr Joel merci
Mais tu me dis que HF suffit pour faire l'affaire?
Justement j'ai constaté ce problème d'indexe. HReindexe corrige proprement la base.
Mais c'est toujours à cause du caractère sensible de HF que je demande si les autres bases sont plus solides et sans difficulté avec les fonctions de windev
Merci Joel
Posté le 03 juillet 2015 - 14:09
Dans mon expérience (+ de 20 ans), HF n'est pas sensible...

Je n'ai eu des problèmes et besoin de réindexer que :

- en utilisation de HF classique en multiposte, du fait de l'évolution
de la gestion oplock dans windows
- quand on a des problèmes matériels (courant, réseau, etc)

Donc, j'ai corrigé les problèmes de configuration et/ou matériels, et je
n'ai pas mis le blame sur HF :-)

Cordialement


--
Fabrice Harari
Consultant WinDev, WebDev et WinDev Mobile International

Disponible : WXShowroom.com, WXReplication (open source)
Bientôt : WXEDM (open source)
Plus d'information sur http://fabriceharari.com


On 7/3/2015 5:47 AM, CHRISTY wrote:
Mr Joel merci
Mais tu me dis que HF suffit pour faire l'affaire?
Justement j'ai constaté ce problème d'indexe. HReindexe corrige
proprement la base.
Mais c'est toujours à cause du caractère sensible de HF que je demande
si les autres bases sont plus solides et sans difficulté avec les
fonctions de windev
Merci Joel
Membre enregistré
30 messages
Posté le 03 juillet 2015 - 14:31
Merci Fabrice
Je vois meiux dans tes propos.
Tu es vraiment un super man en windev
Posté le 03 juillet 2015 - 17:13
Quand je suggère d'utiliser hReindexe, ce n'est pas parce que les index seraient devenus faux ou corrompus. C'est tout simplement parce que quand on fait des ajouts ou des modifications sur un fichier, le moteur modifie les fichiers d'index , mais ces indexes sont de moins en moins optimums.

Pour illustrer le propos, imaginons une feuille de papier, où on écrit une phrase, et où on apporte des corrections à cette phrase, A chaque correction, on fait des ratures, et un jour, ça devient compliqué à lire.
Recopier la dernière version, sans ratures... sur une feuille vierge, ça facilite la lecture.
C'est pareil pour la fonction hReindexe().


cf la page http://doc.pcsoft.fr/fr-FR/?3044134&name=hstatcalcule_fonction pour avoir la même info, source PCSoft.

Et ce n'est pas une spécificité PCSoft. Même Oracle EXIGE que l'on fasse des réindexations régulièrement (compute statistics, gather statistics ... ).



Petite expérience que je viens de faire par curiosité.
Je crée un projet, j'ai un fichier HF dans ce projet, avec une seule colonne (Numérique 999 999 999, c'est à dire le numérique standard). Cette colonne est déclarée comme clé unique.

Je fais ce petit bout de code :
HCreation(fic_test)
POUR i = 1 A 100000
fic_test.n = i
HAjoute(fic_test)
FIN
HFerme(fic_test)


A ce stade , le fichier NDX a une taille de 9.6 Mo
Puis je réindexe le fichier :
HRéindexe( fic_test,hNdxNormal)


La taille du fichier .ndx tombe de 9.6 Mo a 2.8 Mo

J'ai fait d'autres expériences très intéressantes sur ces tailles d'index, mais ce n'est pas le sujet.