Discussion :

[romson2]

Salut à tous. J'aimerais savoir pourquoi utiliser Hyper File SQL par rapport aux autres bases de données telles que oracle mysql ou sql serveur. Je sais que Hyper File est fourni en standard avec Windev et j'aimerai aussi savoir s'il est possible d'installer HF SQL sans installer WinDev, si oui comment? Merci d'avance

[Emmanuel Lecoester]

HyperFile est intégré à la suite WinDev. Son utilisation est gratuite (nombre de serveurs, pas de limitation de base) et est soumise à l'utilisation d'une licence de la suite WinDev.

En espérant avoir répondu à la question.

[Bowen]

Son utilisation est bien adaptée à une application windev.
Il est possible de l'utiliser à partir d'une autre application (telle que access chez nous).
Je ne l'utiliserais pas par contre si le programme principal n'est pas windev. ça obligerait à passer par des accès ODBC qui ralentiraient les traitements.
Il n'est pas parfait, et comporte encore quelques bugs de jeunesse (notamment dans les procédures stockées complexes) mais suffit pour une application pas trop grosse (40 users).
Il a surtout l'avantage financier de pourvoir être posé sur un vrai gros serveur, avec plusieurs processeurs, sans surcoût de licence.

[romson2]

Mais est ce que HyperFile SQL à des limites si oui pourrez vous m'en énumérer qu'elle que une

[Bowen]

Alors pour les limites :

1. Les executions de requêtes sont particulièrement longues. Il vaut mieux s'en passer dans la plupart des cas. (par contre les lectures de fichiers on une vitesse tout à fait raisonnable)
   [Les executions de requêtes avec de multiples jointures sont carrément trop longues (sur de petits fichiers ça va, mais quand on tape sur des 200 000 lignes, ce n'est plus le cas).
2. Quelques bugs trouvés chez moi :
   
   1. Une requête avec un SUM() dans le select (et uniquement un SUM()) qui me renvoie plusieurs lignes. (le problème ne se pose que sur une requête complexe)
   2. Les parcours de fichiers dans les procédures stockées n'est pas toujours bon. (un HLitRecherchePremier avec un critère sur une requête déclarée et executée dans la procédure : les critères du HLitRecherchePremier sont pris en compte aléatoirement)
3. La charge serveur : Je trouve que le moteur Manta consomme plus de ressources que ses grands concurrents (Oracle ou SQL server) pour ne pas fournir les données plus rapidement.

Évidemment, pour juger parfaitement de mes dires, il faudrait que je teste le même projet sur une base concurrente.

Mais le moteur présente également plein de souplesses, telles que pouvoir utiliser du WLangage dans les procédures stockées, la modification automatique des structures de données...

Le développement doit être pensé différemment, il faut par exemple privilégier des lectures de fichier et et des accès directs à des jointures.
Ex. : Afficher toutes les commandes client dont une ligne n'est pas livrée :

Code en SQL :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
SELECT CC_ID
FROM CC
WHERE CC_ID IN (
  SELECT CCL_CC_ID
  FROM CC
  WHERE CC_Livre = 0
)

sera beaucoup moins rapide que

Code en WLangage :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
BOUCLE
    SI HLitPremier(CCL, CCL_Cle, [CC.CC_ID, 0]     //ou CCL_Cle est une clé composée de CCL_CC_ID et CCL_Livre
A FAIRE TANT QUE HLitSuivant(CC)

Bref, je pense que c'est suffisant pour l'utilisation que j'en ai, même si j'ai certaines fonctions assez gourmandes.