Discussion :

[Philippe Robert]

Nous disposons d'application développées en Windev avec Hyperfile (version 8) comme moteur de bases de données.

La Direction actuelle de notre service considère Hyperfile comme une base de données peu performante.

Est-ce vrai que chaque fois qu'une requête est effectuée sur une table hyperfile, l'entièreté de la table est ramenée sur le poste client générant ainsi une charge sur le réseau.

Est-ce que l'utilitaire WDMAP provoque des problèmes de performances lors de son utilisation ?

Quels sont vos avis à ce sujet ?

[danielsoft]

Votre direction a raison, concernant les données car il s'agit d'une base réseau

[vmolines]

Une base de données "fichiers" plus exactement (HF, Access) par opposition aux bases données client serveur (HF C/S, Oracle, SQL Server, MySQL, DB2, ...)

[danielsoft]

C'est exact, sauf que MySQL avec le moteur MyIsam est considéré également comme une base de données fichiers.

Il me semble que PCSOft concernant HF parle de base de données réseau.

[vmolines]

Non je persiste, MySQL est Client/Server que ce soit en moteur de table InnoDB ou MyISAM.

Le client envoie des instructions au moteur, ce dernier traite l'instruction et renvoie le résultat au client. En aucun cas le client ne manipule les données directement contrairement à un SGBD fichier.

[danielsoft]

Non je persiste, MySQL est Client/Server que ce soit en moteur de table InnoDB ou MyISAM.

Le client envoie des instructions au moteur, ce dernier traite l'instruction et renvoie le résultat au client. En aucun cas le client ne manipule les données directement contrairement à un SGBD fichier.

MySQL MyIsam est une base de type fichier en client/serveur
(cf http://sql.developpez.com)

Le HF dont on parle est une base de type fichier en réseau (elle est définie par ce nom par son éditeur).

[vmolines]

Si vous allez par là alors InnoDB est un SGBD fichier puisqu'il stocke les tables dans un ou plusieurs fichiers .IDB. C'est aussi le cas de SQL Server avec les fichiers .MDF.

Tout ceci pour montrer qu'il n'y a aucun intérêt à distinguer un moteur qui utilise un fichier ou une partition raw data pour stocker physiquement les données.

A contrario distinguer un moteur client/serveur a une réelle importance sur les fonctionnalités et les limitations du moteur. Faire du stockage physique un critère discriminant

Je n'entendrai jamais dire "Nous ne souhaitons pas un SGBD fichier" mais plutôt "Nous ne souhaitons pas un SGBD qui ne soit pas Client/Serveur".

Je pense que vous faites une distinction pas terminologiquement erronée mais inutile.

Au sujet des ressources que vous mentionnez, je cite volontiers un passage :

Notons d’ores et déjà une différence fondamentale : alors que dans un système à base de fichiers, c’est chaque poste de travail qui traite localement les données, dans un SGBD C/S, tous les traitements sont, en principe, effectués sur le serveur par le biais de requêtes.

C'est exactement l'amalgame que j'ai fait en disant qu'un SGBD fichier avait pour caractéristique le fait que c'est le(s) client(s) qui manipule(nt) directement les données alors que le SGBD C/S s'occupe des manipulations en traitant les ordres des clients.

Donc, dans le jargon, quand on dit SGBD "fichiers", on entend "non client/serveur" et non pas la technique de stockage utilisée.

[Elian]

Au sujet de WDMAP il n'y a aucune raison qu'il influence les performances, à moins que vous ne l'utilisiez pour des interrogations conséquentes : il est uniquement prévu pour le test et ne fait pas partie des outils de production.

Notez que WDMAP est un ancien module, la base Hyper File dispose maintenant d'un "centre de contrôle" qui permet de gérer les données, surtout lorsqu'elles sont exploitées en mode Client/Serveur qui est disponible depuis la version 10 (et même la version 9 en bêta à l'époque).

Vous avez un document accessible dans les FAQ de PC SOFT qui vous donnent de bons conseils pour les performances en réseau :
http://www.pcsoft.fr/st/telec/windev...eurWindows.pdf

[SQLpro]

Bonjour,

effectivement en ce qui concerne le classement, on peut ranger les SGBDR en deux catégories :

1) base de données "fichier" :
Access, Hyperfile, Foxpro, Paradox, dBase, SQLlite...
C'est à dire qu'il n'y a pas de serveur doté d'une intelligence capable de fouiller la base à la recherche de l'information et qui la renvoie au client.
Pour fonctionner ce type de SGBD est obligé d'envoyer aux clients les fichiers nécessaires à traiter la requête.
Par exemple pour une requête sur client/facture where client = 54 et DateFacture = 21/04/1999 il faut renvoyer au poste de travail tout le contenu des tables clients et facture et c'est le poste client qui traitera les données à la recherche des bonnes lignes.
Inconvénient : La trafic réseau est donc intense et la contention importante du fait que toute demande (y compris un SELECT) pose des verrous sur les objets requêtés. De plus chaque poste nécessite la mise en place d'un moteur SQL local.

Ce type de base est en voie d'abandon du fait qu'existe des bases de données C/S à bas coût voir gratuites bien plus performante.


2) base de données "client/serveur"
Oracle, SQL Server, Sybase ASA/ASE, IBM DB2, Firebird, Interbase, PostGreSQL
La base est stockée sur un serveur et les requêtes sont envoyé à un moteur SQL situé sur le serveur (intelligence centralisée). De ce fait, ne circule sur le réseau que les lignes de la réponse.

Avantage : le trafic réseau est minime et le verrouillage moindre (on peut choisir des verrous de page de ligne...

Inconvénient, nécessite un serveur robuste et de grande capacité (les SGBDR nécessite des serveurs ayant BEAUCOUP de ressources notamment en RAM et en disque).

*** STOCKAGE ***

En régle général les SGBDR fichiers stockent les données des tables à raison d'une table = 1 ou plusieurs fichiers distinct. C'est le cas de de dBase, Paradox... Exception : Access qui stocke toutes les tables (et même toutes les IHM) dans un seul fichier.
Le découpage 1 table = 1 ou + sieurs fichiers est souvent basé sur le modèle XBase et on comprend pourquoi :
dans Access pour faire la requête Client/facture il vous envoyer tout le fichier contenant toutes les tables sur le poste client afin de traiter la demande.
Voila pourquoi Microsoft recommande de ne pas dépasser 10 utilisateurs et 200 à 300 Mo de données. En pratique je dirais plutôt qu'à partir de 3 utilisateur Access s'effondre. En revanche j'ai vu des applications avec 50 utilisateurs et de quelques giga octets de données tourner parfaitement sous Paradox et il y a des années (1993....).
Pour un SGBDR C/S cette volumétrie relève de la rigolade... Pour information la base de données Euridile du registre du commerce c'est près de 1 To avec des pointes à 30 000 utilisateurs simultanés.

Les SGBDR C/S stockent leurs données dans un seul fichier ou un groupe de fichiers (lorsque par,exemple la base étant très grosse, un seul disque ne suffit pas). Dès lors la structuration interne de ces fichiers (comment les tables sont organisées à l'intérieur de cet unique fichier) relève de la seule responsabilité de l'éditeur de SGBDR. L'avantage du "mono fichier" est de minimiser les ressources (moins de fichiers ouvert, c'est moins de ressources système à gérer).
Autre avantage le traitement des transactions et donc la pose des verrous indispensable aux transactions peu se faire sur des granules interne au fichier appelées pages ce qui est plus rapide que de s'intéresser à la ligne.

Cas de MySQL :
MySQL est un peu un hybride car il est bien C/S, mais stocke ses tables à raison d'une table par fichier.
L'inconvénient majeur de ce modèle est qu'il ne facilite pas la gestion des transactions (qui sont arrivées très tardivement dans MySQL et se relèvent peu rapide...) et rend très difficile une sauvegarde consistante de la base de données (risque sévère de non respect de l'intégrité des données de la base).
En effet il n'y a toujours pas moyen de faire une sauvegarde consistante à chaud sur MySQL, alors que cela se pratique sur tous les SGBDR C/S...
Même la prochaine version n'intégrera toujours pas ce service !

A +

[danielsoft]

Bonjour,

concernant MySQL et les sauvegardes à chaud, il n'y a pas de problème si tu utilises InnoDB et l'argument --single-transaction lors de la sauvegarde.

Il existe une solution assez efficace qui permet de faire des sauvegardes incrémentales en utilisant les log binaires. Tu fais un "flush-logs" qui va te créer un nouveau fichier binaire, il suffit de copier tous les fichiers binaires avant celui qui vient d'être créé.

@+

[ExpertWD]

Hello

Je réponds à ce message parce que j'ai lu dans ce thread des erreurs.

1- au niveau philosophie, les bases 'ISAM' ont encore un grand avenir devant elles , pour les applications 'stand alone', installée en locale, qui fonctionnent sur PC unique. Il n'y a rien à installer (pas de serveur), aucune administration,....
Utile sur PC de bureau et pour toute application embarquée. Ce type de base ne devrait donc jamais disparaitre.
Pour les petits réseaux (inférieurs à 20 postes), cette technologie a l'avantage de ne nécessiter quasiement aucune administration

2- Dans le cas d'une requête, même la version 'classic' de HyperFile (la version la plus ancienne,l'ISAM) ne ramène bien entendu pas le contenu entier de la "table" sur le PC pour effectuer une sélection ! Une requête renvoie l'ensemble du 'résultat' sur le client, pas l'ensemble de la table !!!
pour obtenir des temps de réponse rapide il faut bien programmer les accès, et utiliser des clés d'index discriminantes. Un développeur Windev a à sa dispo des ordres très pointus pour faire cela, les fameux hLitRecherche et les filtres. Windev dispose également d'un outil qui indique les clés d'index manquantes dans la description, très utile aux débutants.

Mais jamais une table entière n'est rapatriée sur le poste client, aucune application ne serait utilisable si HyperFile classic (et les bases ISAM en générale) fonctionnait ainsi !!

Concernant Hyper file, il existe en 3 versions distincte :
- La version 'Classic', qui est un ISAM.
- La version 'Mobile', destinées aux matériels sous Windows CE et Windows Mobile
- La version 'Client/Serveur'.
Cette version client/serveur propose par exemple les procédures stockées, ou la sauvegarde à chaud par exemple.

Point intéressant , les 3 versions sont compatibles entre elles. Il est par exemple possible de copier les fichiers de données d'un type de base vers une autre , ce qui est très utile par exemple lorsque l'on édite un logiciel destiné à différentes cibles.
Un détail : Lors des roadshows, PC Soft à présenté HyperFile client/ serveur sur une base de données qui contennait plus de 10 milliards d'enregistrements: tojours bon à savoir

Il me semblait important d'apporter ces précisions sur Hyper file.

[Emmanuel Lecoester]

Hello

Je réponds à ce message parce que j'ai lu dans ce thread des erreurs.

1- au niveau philosophie, les bases 'ISAM' ont encore un grand avenir devant elles , pour les applications 'stand alone', installée en locale, qui fonctionnent sur PC unique. Il n'y a rien à installer (pas de serveur), aucune administration,....

+1

Utile sur PC de bureau et pour toute application embarquée. Ce type de base ne devrait donc jamais disparaitre.

Pas sur avec l'apparation des bases de données gratuites et open-source.

Pour les petits réseaux (inférieurs à 20 postes), cette technologie a l'avantage de ne nécessiter quasiement aucune administration

Pas sur car si l'application est gourmande en terme de requêtes, le réseau en prend un coup.

2- Dans le cas d'une requête, même la version 'classic' de HyperFile (la version la plus ancienne,l'ISAM) ne ramène bien entendu pas le contenu entier de la "table" sur le PC pour effectuer une sélection ! Une requête renvoie l'ensemble du 'résultat' sur le client, pas l'ensemble de la table !!!
pour obtenir des temps de réponse rapide il faut bien programmer les accès, et utiliser des clés d'index discriminantes. Un développeur Windev a à sa dispo des ordres très pointus pour faire cela, les fameux hLitRecherche et les filtres. Windev dispose également d'un outil qui indique les clés d'index manquantes dans la description, très utile aux débutants.
Mais jamais une table entière n'est rapatriée sur le poste client, aucune application ne serait utilisable si HyperFile classic (et les bases ISAM en générale) fonctionnait ainsi !!

Exact, les HFiltre, HlitRecherche aident grandement mais étaient peu utilisés dans les applications qui "ramaient"

Concernant Hyper file, il existe en 3 versions distincte :
- La version 'Classic', qui est un ISAM.
- La version 'Mobile', destinées aux matériels sous Windows CE et Windows Mobile
- La version 'Client/Serveur'.
Cette version client/serveur propose par exemple les procédures stockées, ou la sauvegarde à chaud par exemple.

Précise la version pour chaque affirmation car l'apparition des P/S, des triggers base de données ne sont pas apparus en même temps que HF C/S. Si on part du principe que tu t'adresses à des personnes ayant toutes WD12, tout est vrai .

Point intéressant , les 3 versions sont compatibles entre elles. Il est par exemple possible de copier les fichiers de données d'un type de base vers une autre , ce qui est très utile par exemple lorsque l'on édite un logiciel destiné à différentes cibles.

Exact, mes amis belges m'ont permis de découvrir ce point.

Un détail : Lors des roadshows, PC Soft à présenté HyperFile client/ serveur sur une base de données qui contennait plus de 10 milliards d'enregistrements: tojours bon à savoir

La tu touches à la grande question... Comment gérer de la volumétrie dans un SGBD. Les SGDB permettant de gérer des milliards de lignes se comptent sur les doigts d'une main et HF n'en fait pas partie . Mais ne t'inquiètes pas HF sait parfaitement gérer le million de lignes ce qui est grandement suffisant

Il me semblait important d'apporter ces précisions sur Hyper file.

[danielsoft]

Pour compléter la réponse Elecoest

Hello
2- Dans le cas d'une requête, même la version 'classic' de HyperFile (la version la plus ancienne,l'ISAM) ne ramène bien entendu pas le contenu entier de la "table" sur le PC pour effectuer une sélection ! Une requête renvoie l'ensemble du 'résultat' sur le client, pas l'ensemble de la table !!!

Faux, il suffit de brancher un sniffer sur le réseau pour voir qu'on a bien plus que le contenu de la requête.

pour obtenir des temps de réponse rapide il faut bien programmer les accès, et utiliser des clés d'index discriminantes. Un développeur Windev a à sa dispo des ordres très pointus pour faire cela, les fameux hLitRecherche et les filtres. Windev dispose également d'un outil qui indique les clés d'index manquantes dans la description, très utile aux débutants.

Mais jamais une table entière n'est rapatriée sur le poste client, aucune application ne serait utilisable si HyperFile classic (et les bases ISAM en générale) fonctionnait ainsi !!

Effectivement on ne va pas ramener toute la table, mais l'index et une partie de la table ce qui est pire.

Concernant les fonctions très pointues, rien ne vaut une bonne requête SQL qui permet de maitriser ce qu'on fait.

cf
http://groups.google.fr/group/fr.com...054b4912ddde5#

Point intéressant , les 3 versions sont compatibles entre elles.

Il s'agit d'un intérêt uniquement dans le cadre de la suite d'outil de l'éditeur.
Il s'agit à mon avis d'un inconvénient majeur de lier un outil à une base propriétaire (sauf si on s'appelle Microsoft, Sun, IBM, Oracle)

Un détail : Lors des roadshows, PC Soft à présenté HyperFile client/ serveur sur une base de données qui contennait plus de 10 milliards d'enregistrements: tojours bon à savoir

Cela ne veut strictement rien dire.
Lorsqu'on voit que des moteurs comme innodb peuvent avoir des problèmes de performances sur des tables des qu'on dépasse le million de lignes.

Il faut vraiment faire attention avec ce type d'annonces, qui me paraissent dangereuses, gérer une base de quelques milliers d'enregistrements, n'a rien avoir avec gérer des millions d'enregistrements, et encore moins des milliards.

[ExpertWD]

Hello,
Pour ce qui est des données ramenées sur le poste client en Hyper FIle ISAM, je garantis que les temps de réponse sont bons avec un reseau 'normal', 20 opératrices paralèles sur une appli de facturation/encaissement.
Table client d'environ 500.000 enregistrements, table 'ligne de commandes' de plusieurs millions de lignes (et lappli possède 20 ou 30 tables annexes: produits, banques etc). L'appli était 'historiquement' en Hyper FIle ISAM, avec des temps de réponses 'immédiats' (y compris pour les recherches lors d'appels des clients ), et elle est passé en Client/Serveur avec la version 11.
Le client/serveur a surtout apporté des éditions de stats plus rapides (passé de 15-20 à 3 secondes pour l'état comparatif de chiffre d'affaires détaillé - familles, sous familles etc- sur plusieurs années).
Bien entendu, les clés composées adéquates ont été définies dans l'analyse (très très important pour de bonnes performances en ISAM).

[Gilles_69]

Toutes ces explications sont extrêmement intéressantes et montrent à quel point même les spécialistes peuvent ne pas être d'accord entre eux. Imaginez pour nous béotiens !
Pour revenir au sujet de base, pensez-vous que HF bien configuré pour une volumétrie moyenne (qqs centaines de tables, qqs Go de données, 50 utilisateurs) puisse être la solution ? Doit-on s'orienter sur HF C/S ? Que pensez-vous des performances par rapport à MySQL ?

[Emmanuel Lecoester]

Toutes ces explications sont extrêmement intéressantes et montrent à quel point même les spécialistes peuvent ne pas être d'accord entre eux. Imaginez pour nous béotiens !

Exactement. C'est parfois ce qui arrive chez des clients ou le client à un experte et le prestataire aussi et les 2 se rejettent la "faute".

Pour revenir au sujet de base, pensez-vous que HF bien configuré pour une volumétrie moyenne (qqs centaines de tables, qqs Go de données, 50 utilisateurs) puisse être la solution ?

HF classic non : voir précédemment ce qui a été dit par WDExpert.

Doit-on s'orienter sur HF C/S ?

Oui sachant qu'il sera toujours possible de faire du classic pour les petites structures.

Que pensez-vous des performances par rapport à MySQL ?

L'accès MySQL étant natif et gratuit chez PC-Soft, vous pourrez tester par vous même.

Voici des questions que je posais toujours (en vrac) : on parle de 100 tables qui évoluent tous les jours ? si oui en quelle volumétrie ? c'est de l'ajout simple ou des delete/update de masse ? 50 utilisateurs actifs ? ou 50 utilisateurs en lecture ? une base en Go c'est une infrastructure derrière : sauvegarde sur bande quotidienne + hebdo + mensuelle avec des rétentions spécifiques ? Disponibilités de la base 24-7 ? si oui besoin de sauvegarde à chaud...

Concernant le choix du SGBD, personnellement je prêche toujours pour une ouverture du SI : technologies différentes (serveur linux, postes client W32, outil de dev X, base de données Y). Cela permet de ne pas s'enfermer.

Il existe un comparatif fait par fadace sur les possibilités de chaque SGBD (HyperFile n'en fait pas partie).

[Wazzock]

Bonjour
Veuillez m'excuser de déterrer ce topic mais après avoir utiliser la fonction recherche du forum, cela m'a semblé être le thread le plus approprié pour poser mes questions.
Je suis en charge de la sélection d'un nouveau logiciel de gestion pour la société que je gère et un des logiciels qui retient mon attention est en HF SQL (TCI Gest - https://www.erp-tcigest.fr/base_de_donnees.html)

Après avoir réalisé plusieurs démonstrations des fonctionnalités de ce logiciel, il semble correspondre à mes besoins.
Or, mon informaticien m'indique qu'il n'est pas très fan car il considère le HF SQL comme une base de donnée trop lente pour le volume de donnée que nous avons.
Au niveau du contexte, nous avons besoin d'avoir une trentaine de personnes connectées au logiciel en même temps sur notre siège social + une dizaine de postes à distance.
A ce jour nous utilisons un ERP appelé Gestimum qui fonctionne sur MS SQL Server et c'est ce type de base de donnée qui a la préférence de mon informaticien car c'est celui lui plus rapide, les sauvegardes sont plus facilement administrable et notamment on peut remonter grâce aux logs à l'écriture près afin de faire une restauration en cas de disfonctionnement.
Notre ERP est également connecté à plusieurs applications externes type caisse magasin, sites e-commerce, marketplaces, CRM.

Ce que j'ai lu sur le forum dans les différents sujets et sur d'autres sites, c'est finalement si je comprends bien que MS SQL Server est un client serveur, donc il traite plus rapidement les requêtes et cela est d'autant plus visible lorsque les données sont importantes. Les sujets consultés étaient anciens (2006/2009) sont je voudrais savoir si HF SQL souffre toujours de ce problème de BDD orienté fichier plutôt que client server?
Notre société n'est pas relié à la fibre et utilisons donc plusieurs boxs agrégés avec une Over The Box OVH pour obtenir une connexion internet satisfaisante.

De mon côté je cherche à être objectif dans la mesure ou je souhaite sélectionner un ERP qui correspond aux fonctionnalités requisess par nos activités, de la manière la plus ergonomique plus ergonomiques pour mes collaborateurs. je ne veux pas éliminer un prétendant ERP simplement car contrairement aux autres il est HF SQL et qu'on ne le connait pas.
Selon moi, l'informaticien, comme les autres collaborateurs de l'entreprise, peut remettre son travail en question et se former sur les procédures du nouvel outils s'il est plus performant. Donc je ne veux pas l'éliminer simplement sur le fait que les procédures de sauvegarde sont déjà faites sur SQL Server et c'est plus confortable car j'imagine que les sauvegardes de BDD doivent également pouvoir se faire sur HF SQL.

Pourriez-vous donc svp m'éclairer sur vos connaissances de ce type de base de donnée et sur les performances qu'elle peut délivrer.

[frenchsting]

Bonjour,

HF SQL (ou HFCS), fonctionne plutôt bien. Il y a pour moi plusieurs questions importantes :
- Quelle sera la puissance du serveur (HDD et RAM notamment) ?
- Quelle sera la volumétrie de la BDD ?
- Quels sont les tailles des enregistrements ?
- Quel sera le "niveau" de lecture / écriture des utilisateurs ?

Pour les 3 derniers points, j'essaye une petite explication (grossière pour bien me faire comprendre) :
- Une BDD avec des tables de plusieurs millions d'enregistrements sera plus lente qu'avec des tables de 3 enregistrements
- Une table avec 3 rubriques (id, code, libellé par ex) sera plus lente qu'une table avec 300 rubriques (id, code, libellé, largeur, hauteur, poids,.... par ex)
- Si les utilisateurs font une opération par minute et par utilisateur (30 en tout d'après ton explication), ou une opération par heure (0,5 en tout dans ton cas).

Est-ce que l'éditeur concerné t'a donné des infos quant au dimensionnement et aux limites de son ERP ?

Pour les sauvegardes, il est possible de planifier le SGBD pour les faire. Sinon, un système externe (Iperius, Cobian, ...), c'est très bien aussi.

[kunnskap]

Pour commencer si l’éditeur du logiciel ne propose pas de mode HF C/S sur son appli, passez votre chemin. Je parle bien de HFSQL Client/Serveur, et non pas d’une base HFSQL Classic en réseau, ça c’est à bannir en multiposte/multiuser. Il faut donc bien s’assurer de ce qu’il propose, le HF Classic en réseau et le HF C/S ce n’est pas la même chose et ça peu engendrer bien des problèmes.

Pour les sauvegardes, certes HFSQL a moins d’option que SQL Server, mais ce n’est pas forcément un frein. Donc je ne tiens pas compte de ce critère, il est toujours possible de sauver la machine elle même si c’est nécessaire, et de mettre en place un PRA adapté.

Et ensuite pour la volumétrie, il y a volume et volume. Si il faut adresser des millions/milliards de ligne, SQL Server s’impose.
Demandez aussi à l’éditeur si il peut se brancher sur autre chose que HF? Il est tout à fait possible de développer des applis Windev qui utilisent autre chose que HFSQL. Il est même possible de n’utiliser HFSQL que pour une partie de la base et d’utiliser d’autres SGBDR pour des fichiers dont on sait qu’ils vont être très très gros.

Mais dans tous les cas, si l’éditeur à un code pourri qui fait des POUR TOUT sur les tables, que ce soit C/S ou pas, ça va ramer. Et là vous n’y pouvez rien. Il y a un peu d’inconnu dans l’histoire, forcément.

[tatayo]

Bonjour,
Pour que le test soit vraiment représentatif, il faudrait aussi créer "l'entête" du ticket de vente avec des contraintes d'intégrité vers le magasin, le client, une contrainte d'intégrité entre l'entête et les lignes, entre les lignes et la table article.

Avec bien sûr des tables magasin, article, client bien remplies (quelques dizaines de milliers de lignes minimum pour les deux dernières).

Sinon on est très loin de la "vrai vie" d'une base de données.

Tatayo.