|
| HFSQL Retour d'expérience |
| Iniciado por THIERRY TILLIER, 09,ago. 2018 17:23 - 30 respuestas |
| |
| | | |
|
| |
Miembro registrado
1.173 mensajes |
|
| Publicado el 09,agosto 2018 - 17:23 |
Bonjour,
Des questions de performance HFSQL reviennent fréquemment sur le forum. Or, PCSoft vente la rapidité de son serveur de données. J'ouvre donc ce poste pour avoir un retour de vos expériences.
Quels avantages voyez-vous à HFSQL ?
Quels désavantages voyez-vous à HFSQL ?
Préférez-vous un autre SGDB ? si oui pourquoi ?
En cas de choix d'un autre SGDB, la mise à jour se fait-elle simplement ?
Avez-vous suivi la formation PCSoft sur HFSQL ?
Personnellement je préfère HFSQL pour sa simplicité, mais j'avoue rester perplexe sur la rapidité qui n'est pas celle attendue.
Merci de votre participation et bon dév.
Thierry |
| |
| |
| | | |
|
| | |
| |
Miembro registrado
1.640 mensajes |
|
| Publicado el 09,agosto 2018 - 17:56 |
Bonjour,
Franchement... je ne comprend pas trop les critiques.
Nous avons une base article de près de 2 Millions d'articles, en WEBDEV, une recherche sur les clés est quasi instantané ... (Il n'y a pas de jointure... Avoir avec !) |
| |
| |
| | | |
|
| | |
| |
Miembro registrado
1.173 mensajes |
|
| Publicado el 09,agosto 2018 - 18:06 |
Bonjour François,
Ne considérez pas mes propos comme des critiques, je cherche simplement à améliorer la qualité de mon travail.
Le problème que j'évoque est peut-être dû au nombre de jointures sur mes tables.. |
| |
| |
| | | |
|
| | |
| |
Miembro registrado
1.640 mensajes |
|
| Publicado el 09,agosto 2018 - 21:54 |
Non je parlais des critiques "en général"  |
| |
| |
| | | |
|
| | |
| |
| Publicado el 09,agosto 2018 - 22:00 |
bonjour
je dirais pauvre en sql
et voir postgres gratuit avec le le psql
mais après cela dépend de l'appli |
| |
| |
| | | |
|
| | |
| |
Miembro registrado
2.682 mensajes |
|
| Publicado el 10,agosto 2018 - 08:22 |
Bonjour,
Avoir une table unique sans jointure et afficher instantanément les données recherchées, toutes les bases de données savent le faire. Le problème survient en général soit sur des requêtes un peu complexes, sur des insert un peu conséquent ou encore sur des update portant sur de nombreuses lignes.
Personnellement je suis passé sur des SGBD comme SQL Server ou postgresql qui lui est gratuit. Nous avons fait un comparatif il y a un semaine de cela à peu près avec d'autres utilisateurs de ce forum. La mise à jour d'un champ sur 15 millions de lignes. HFSQL n'a jamais réussi à le faire et à planté au bout de 45 minutes avec une erreur sur la taille du journal de transactions. Postgresql a mis 9 minutes et SQL Server 4'30''.
Le SQL de HFSQL est bien moins évolué que ses concurrents cités ci-avant, les sous-requêtes en sont à leur balbutiement et ne sont vraiment pas efficaces. Ca a peut-être évolué depuis mais je n'essaye même plus. Certaines requêtes plantent tout simplement et il faut trouver une solution pour contourner le problème (j'ai eu le cas sur des calculs sur des longitude et latitude). Un "select * into table1 from table2" ne fonctionne pas. c'est pourtant très pratique.
Les triggers lui font défaut. On ne peut pas avoir les valeurs avant la modification des données et les valeurs après la modification pour faire une journalisation des modifications effectuées. Il existe bien une journalisation, mais je l'ai utilisée dans les anciennes versions, j'ai eu des ralentissements incroyables de l'ordre de 30 secondes pour ajouter un enregistrement. On m'avait répondu à l'époque qu'il faut vider les journaux tous les jours. Bref c'était pas au point. Aujourd'hui ça fonctionne peut-être je ne sais pas je n'ai plus jamais réitéré l'expérience.
Les procédures stockées, j'en ai très peu fait avec HFSQL donc je ne me prononcerai pas.
Le gros avantage de HFSQL est son intégration aux produits PC Soft bien évidemment. Les ordres Hxxx sont efficaces mais peuvent parfois te faire tourner en rond. Du style tu as filtré ton fichier et tu as oublié de retirer le filtre et tu ne comprends pas pourquoi tu ne retrouves pas tes informations (c'est du vécu...).
si tu n'as pas de grosses requêtes, pas d'utilisation de triggers, tu peux imaginer passer à HFSQL mais avec l'accès natif de postgresql est à mon sens la meilleure alternative à HFSQL en gratuit.
--
Cordialement,
Philippe SAINT-BERTIN |
| |
| |
| | | |
|
| | |
| |
Miembro registrado
299 mensajes |
|
| Publicado el 10,agosto 2018 - 16:13 |
Pour ma part j'ai tranché une bonne fois.
J'utilise SQL Serveur chaque fois que je le peux, ACCESS pour les petites solutions qui doivent être facilement installables.
J'ai écrit une classe qui gère l'ODBC
Les temps de réponse sont corrects, je n'ai pas de souci et surtout pas d'environnement de données établissant un lien entre le logiciel et les données. |
| |
| |
| | | |
|
| | |
| |
Miembro registrado
1.173 mensajes |
|
| Publicado el 11,agosto 2018 - 10:34 |
Merci à tous pour vos réponses.
Toutefois, quelqu'un a-t-il suivi la formation de PCsoft sur HFSQL et constater un bénéfice? |
| |
| |
| | | |
|
| | |
| |
Miembro registrado
299 mensajes |
|
| Publicado el 11,agosto 2018 - 15:14 |
"quelqu'un a-t-il suivi la formation de PCsoft sur HFSQL"
Oui en 2015 aux Champs Elysées.
Je ne pense pas y avoir appris grand-chose : le plan du cours est pré-établi et on n'en dérive pas quelque soit votre question. Cela dit on y voit les 'bonnes pratiques' sous l'angle de l'éditeur et c'est toujours utile.
Ensuite on se forge sa propre philosophie en fonction de ce que l'on voit sur le terrain comme je l'ai fait pour ma part avec l'accès aux données. Cette démarche est la même pour beaucoup de langages. |
| |
| |
| | | |
|
| | |
| |
Miembro registrado
1.173 mensajes |
|
| Publicado el 12,agosto 2018 - 18:10 |
@Philippe SAINT-BERTIN
à quelle version d'HFSQL vous êtes-vous arrêté ? |
| |
| |
| | | |
|
| | |
| |
Miembro registrado
2.682 mensajes |
|
| Publicado el 12,agosto 2018 - 19:29 |
Je continue de travailler avec HFSQL pour des petits projets qui ne demandent rien d'exceptionnel, Les problèmes de requête don je parle sont toujours d'actualité et la réponse du ST m'a laissé perplexe. Un select into n'est toujours pas possible (je viens de tester).
Je suis en version 23 et je passerai probablement à la 24 en fin d'année, mais un doute sur l'évolution du SGBD.
Mon conseil, si ton projet est un peu conséquent, passe sur autre chose, PostgreSQL, SQL Server, MariaDB, MySQL, ... Essaye quand même de rester sur un moteur qui évolue en permanence.
--
Cordialement,
Philippe SAINT-BERTIN |
| |
| |
| | | |
|
| | |
| |
| Publicado el 16,agosto 2018 - 08:44 |
Bonjour
Perso j'ai travaillé en HFSQL sur des DB de +- 15.000.000 de records et je n'ai pas eu les problèmes de crash durant un query update à partir du moment où j'utilise toujours une clé pour effectuer une update même si cil impacte tout les records de la table ( et c'est le comportement par défaut également en MYSQL qui refuse sans modifier les paramètres d'exécuter un UPDATE ou DELETE sur une table sans préciser de clé )
En ce qui concerne les DB j'utilise HFSQL, MYSQL, SQLServer et parfois ORACLE mais la plupart du temps je commence avec HFSQL mais j'utilise des un framework et des fonctions SQL qui sont 100% compatibles sur les 3 bases ( sauf oracle ) que je viens de citer ( ce qui implique aucune proc stockée ni trigger server en 2018 il y a d'autres chose à faire que cela pour rendre une application performante ) comme cela en cas de montée en charge ou de demande du client ont sait basculer facilement sur une autre DB
Mais je vais dire qu'en général pour la plupart de mes clients ( entre 30 et 50 postes dont une gestion de production ) HFSQL fait le job sans problème aucun client ne se plaint des temps de réponses mais si on me parle de 100 postes par exemple je propose directement SQLServer, de toute façon à cette taille le client l'utilise déjà la plupart du temps
Bon Dev
Marc Fastré
www.marc-fastre.be |
| |
| |
| | | |
|
| | |
| |
Miembro registrado
2.682 mensajes |
|
| Publicado el 17,agosto 2018 - 11:39 |
@Marc Fastré: L'utilisation d'une clé pour un update n'est absolument pas obligatoire en SQL et encore heureux. Si je veux faire une update de toutes mes lignes, je n'ai pas à lui dire sur quelle clé je veux qu'il update. La moteur fait de la lecture séquentiel et met à jour les données, ce que ne sait pas faire HFSQL à priori sur de gros volumes de données.
Le fait d'utiliser du SQL compatible pour tous les systèmes est, à mon sens, ultra pénalisant, surtout si tu te bases sur HFSQL qui est relativement pauvre à ce niveau. Mais je comprends tout à fait le principe et l'intérêt pour tes logiciels. Cependant choisir un SGBD ne se fait pas que selon le nombre de client, mais selon la complexité technique de ta base et de ce que tu veux déléguer comme tâches à ton serveur.
--
Cordialement,
Philippe SAINT-BERTIN |
| |
| |
| | | |
|
| | |
| |
| Publicado el 17,agosto 2018 - 13:46 |
@Philippe, MYSQL refuse de faire un update ou delete sans clé sans certains privilèges qu'il faut définir dans de workbench ( en tout cas dans la version que j'utilise chez 2 clients ) mais c'est plutôt une question de sécurité que de limitation
La complexité technique à mon niveau elle est principalement codée dans des classes métiers qui permettent justement de répartir la charge sur chaque machine ( avec une partie des données "statiques" chargée à la première utilisation ) , le serveur n'ayant qu'à se contenter de mette à jour distribuer les données qui sont chargées dans des objets métiers qui font leur job en mémoire, d'où le nombre d'utilisateur...
les spaghettis de proc stockée et de trigger métiers qui s' emmêlent les pinceaux, les formats date / heure spécifiques.. merci, on m'appelle assez pour ce genre de développements qui déjantent pour savoir que ce n'est pas une solution,... au plus on est indépendant d'une DB, au mieux ont doit bien penser et structurer le développement : gage de qualité
Maintenant chacun fait sont lit comme il se couche, si tu n'en es pas satisfait c'est judicieux de la faire savoir , comme il me semble judicieux de faire savoir que perso j'en suis globalement satisfait ( sans qu'il soit parfait, il faut parfois trouver des astuces mais pareil avec MYSQL par ex qui ne supporte pas les FULL JOIN ), et pour des volumes conséquents également
Bon Dev
Marc Fastré
www.marc-fastre.be |
| |
| |
| | | |
|
| | |
| |
Miembro registrado
2.682 mensajes |
|
| Publicado el 17,agosto 2018 - 14:44 |
@Marc Fastré: Pas de soucis, je comprends bien ton fonctionnement. Perso je n'utilises pas MySQL ou très peu. J'ai eu à l'utiliser une fois en tout et pour tout chez un client qui avait ça comme base, donc je ne peux pas juger.
Après les procédures stockées, c'est tout de même pratique, mais c'est comme tout, il ne faut pas en abuser. Et un trigger bien ficelé n'a pas plus de raisons de planter ou de faire n'importe quoi qu'une classe mal faite. N'y vois pas là une attaque de ma part, c'est juste un point de vue.
Perso avec un client, je définis un SGD qui convient à son projet et je n'en sors pas sauf cas très exceptionnel où je me serais trompé. Je touche du bois, ça ne m'est encore jamais arrivé.
Je suis d'ailleurs tout à fait d'accord avec toi qu'il faut savoir rester aussi indépendant que possible d'un SGBD. Cependant, mon choix ira toujours quelque chose de rapide et sur lequel je ne suis pas ou peu limité si j'ai envi de faire quelque chose.
En tout cas fort intéressant comme échange.
--
Cordialement,
Philippe SAINT-BERTIN |
| |
| |
| | | |
|
| | |
| |
| Publicado el 17,agosto 2018 - 15:34 |
Philippe SB a écrit :
@Marc Fastré: Pas de soucis, je comprends bien ton fonctionnement. Perso je n'utilises pas MySQL ou très peu. J'ai eu à l'utiliser une fois en tout et pour tout chez un client qui avait ça comme base, donc je ne peux pas juger.
Après les procédures stockées, c'est tout de même pratique, mais c'est comme tout, il ne faut pas en abuser. Et un trigger bien ficelé n'a pas plus de raisons de planter ou de faire n'importe quoi qu'une classe mal faite. N'y vois pas là une attaque de ma part, c'est juste un point de vue.
Perso avec un client, je définis un SGD qui convient à son projet et je n'en sors pas sauf cas très exceptionnel où je me serais trompé. Je touche du bois, ça ne m'est encore jamais arrivé.
Je suis d'ailleurs tout à fait d'accord avec toi qu'il faut savoir rester aussi indépendant que possible d'un SGBD. Cependant, mon choix ira toujours quelque chose de rapide et sur lequel je ne suis pas ou peu limité si j'ai envi de faire quelque chose.
En tout cas fort intéressant comme échange.
--
Cordialement,
Philippe SAINT-BERTIN
Pas de soucis je ne vois pas cela comme une critique bien au contraire mais il y a d'autre façon de coder ajd qui permettent de s'affranchir de la puissance de la DB, mais en effet une classe mal cela peut arriver aussi mais le concept d'abstraction veulent que l'impact est plus limité et surtout le debug plus facile
Pour moi mes proc stockées et les triggers n'ont pas leur place dans le flux métier, le problème c'est que l'on en fait 1,2,3, puis 10,20,50 ( 200,300...) et patatra c'est l'embardée on ne sait plus qui appelle quoi et bonjour le debug et les effets de bord quand tu en est arrivé là si tu touche à un truc il y a un autre qui pète systématiquement
Par contre ok pour des calculs de stats et autres job bach qui sont effectués en différés, là c'est très opportun .
Mais J'ai déjà bloqué avec HFSQL, dernièrement j'ai du faire deux requêtes pour me décoincer ( avec hlitrecherchepremier de la premiere sur la seconde ), … alors qu'un collègue plus balaise m'a fait la requête sur SQL server que j'ai testé avec une réplique de la DB HF… j'ai testé les 2 manières sur SQL server et le requête unique ( plus lmourde ) prenait légèrement plus de temps que les deux requêtes séparées, comme quoi...
Bon Dev
Marc fastré
www.marc-fastre.be |
| |
| |
| | | |
|
| | |
| |
Miembro registrado
299 mensajes |
|
| Publicado el 18,agosto 2018 - 23:18 |
Je pense qu'il faut distinguer les triggers et les procédures stockées.
Pour les premiers, effectivement, il faut avoir une documentation à jour sinon on s'étonne de voir les résultats évoluer sans y avoir fait référence.
Par contre les procédures stockées ne sont ni un gadget ni une solution contournable. J'ai eu l'occasion de travailler sur de très gros volumes de données dépassant les 60 millions de lignes. Pour certains traitements nous utilisions des procédures stockées pour gérer l'ensemble du traitement au niveau du serveur et éviter des flux réseau.
Personnellement je n'ai rien contre HFSQL. Toutefois je préfère toujours des solutions plus standards comme Oracle ou SQL Serveur. Un jour ou l'autre les données de l'application que l'on construit peuvent devoir être partagées avec d'autres outils et ce sera alors un obstacle de moins pour la mise en œuvre même si il existe des interfaces.
Indépendamment de cela dans nos CV des noms connus pèsent plus lourd qu'un système propriétaire. C'est ainsi et nous n'y pouvons rien., idem pour trouver les compétences. |
| |
| |
| | | |
|
| | |
| |
| Publicado el 19,agosto 2018 - 10:10 |
@Michel, Le soucis, ce que je vois régulièrement, ce sont des triggers qui appellent des proc stockée ou fonctions qui forcément déclenchent d'autre triggers qui appellent d'autres proc stockées.... la documentation ? elle se trouvent dans la tête des développeurs qui se gardent bien ( ou qui ne savent plus ) expliquer le fonctionnement... job protection !
J'ai vu une fois une entreprise qui a été rachetée qui a du migrer une partie de ses données mysql vers SQLServer, il a fallu réécrire toutes les dites proc stockées.
Mais pour une database dont tu parles je n'utiliserait pas HFSQL c'est clair perso c'est dans le cadre d'une cinquantaine de d'utilisateur simultanés ( et sans contexte HF indépendant !!! ) pour une entreprise qui fonctionne entièrement avec des solutions PCSOFT ou pour une application complètement indépendante sinon je passe sur un produit plus standard ( d'où l'avantage de n'utiliser que du SQL compatible qui fonctionne sur toutes les bases )
En ce qui concerne le volume échangé c'est parfois étonnant ce que tu peux gagner par exemple en chargeant une seule fois si nécessaire certaines tables de paramètres statiques ( utilisateurs, langues, pays, devise, conditionnement, promotions, familles, code divers .... ) en mémoire ( avec reload si modifiés par un autre poste ) en y faisant des requêtes ( hxxx ou requête sur datasource ) et surtout en contrôlant les modifications réelle des records avant de l'envoyer au serveur, bien souvent on balance des UPDATE sans qu'une rubrique du fichier aie été réellement modifiée ( En MVP c'est qq chose qu'il est absolument nécessaire à faire sinon bcp de trafic généré pour rien )
Bon Dev ( et dimanche )
Marc Fastré
www.marc-fastre.be |
| |
| |
| | | |
|
| | |
| |
Miembro registrado
1.173 mensajes |
|
| Publicado el 23,agosto 2018 - 13:44 |
Merci à tous pour votre participation, vos expériences diverses sont riches d'enseignements.
J'ai une base de données complexes (pilotage + planning) avec 24 tables et la plus grosse fait 30 000 lignes après un an d'utilisation (HFSQL CS). Je travaille aussi en ntiers avec des classes. Le temps de réponses est très correct en affichage en fait, chose curieuse, le plus long c'est le remplissage du champ planning (4-5 secondes) en programmation. J'affiche une partie des ressources sans borne sur les dates, je pense qu'à terme je vais devoir en mettre.
Comme l'a fait remarqué Philippe, les mises à jours (pour moi des mises à jours en cascades) sont assez longues. Pour palier ce manque de performance je ne vois pas d'autres alternatives que des procédures stockées pour faire ces updates.
Autre question sur HFSQL. Jusqu'à combien de bases de données (simples) on peut mettre sans altérer les performances du serveur HFSQL ? |
| |
| |
| | | |
|
| | |
| |
Miembro registrado
189 mensajes |
|
| Publicado el 24,agosto 2018 - 09:06 |
Bonjour à tous.
Pour ma part, j'utilise régulièrement le très pratique HFSQL classic en évitant les jointures qui sont la bête noire de ce SGBD, mais dès qu'il faut du C/S, j'utilise MySQL ou si possible SQL Server. Comme Marc, je reste dans du grand standard pour pouvoir migrer facilement d'un SGBD à un autre. J'ai même développé une couche d'abstraction de la BD.
Les procédures stockées sont parfois utiles pour des rasions de performances, mais je les évite également. Je m'en sers surtout en développement WEB pour des calculs de distances sur de nombreux enregistrements, le gain est alors phénoménal.
Jamais de trigger non plus, même s'ils sont une solution pratique dans certains cas.
Jean-Marc |
| |
| |
| | | |
|
| | |
| |
| Publicado el 24,agosto 2018 - 09:49 |
THIERRY TILLIER a écrit :
Merci à tous pour votre participation, vos expériences diverses sont riches d'enseignements.
J'ai une base de données complexes (pilotage + planning) avec 24 tables et la plus grosse fait 30 000 lignes après un an d'utilisation (HFSQL CS). Je travaille aussi en ntiers avec des classes. Le temps de réponses est très correct en affichage en fait, chose curieuse, le plus long c'est le remplissage du champ planning (4-5 secondes) en programmation. J'affiche une partie des ressources sans borne sur les dates, je pense qu'à terme je vais devoir en mettre.
Comme l'a fait remarqué Philippe, les mises à jours (pour moi des mises à jours en cascades) sont assez longues. Pour palier ce manque de performance je ne vois pas d'autres alternatives que des procédures stockées pour faire ces updates.
Autre question sur HFSQL. Jusqu'à combien de bases de données (simples) on peut mettre sans altérer les performances du serveur HFSQL ?
je pense qu'avec des bases de données 'complexes" de 24 tables avec 30.000 lignes par an pour la plus grosse tu ne dois pas trop t'inquiéter pour la montée en charge de ton HF/SQL, sauf il tourne sur un tablette 
Bon Dev
Marc Fastré
www.marc-fastre.be |
| |
| |
| | | |
|
| | |
| |
Miembro registrado
339 mensajes |
|
| Publicado el 09,febrero 2019 - 15:24 |
Bonjour,
Je n'ai pas une expérience avec SQL Server.
Je vous prie de me guider a propos ces 3 questions
- Existe il une notion de types Horodatage, Rubrique calculé dans SQL SERVER ?
- Comment bloquer un enregistrement (avec accés natif)
- Comment sauvegarder la BD
Merci d'avance.
Amine |
| |
| |
| | | |
|
| | |
| |
Miembro registrado
299 mensajes |
|
| Publicado el 09,febrero 2019 - 19:22 |
"en évitant les jointures qui sont la bête noire de ce SGBD"
Why ?
J'ai repris un logiciel utilisant du HFSQL classique. Impossible de modifier : trop d'historique, trop de volume.
J'effectue des jointures dans des requêtes : Join, ou Left Join. Pour l'instant pas de difficultés (du moins à ce niveau)
Ce qui est bizarre c'est la façon dont WinDev rajoute des parenthèses dans les clauses Where mais cela fonctionne
C'est au niveau des contraintes dans l'analyse qu'il peut y avoir des soucis ? |
| |
| |
| | | |
|
| | |
| |
Miembro registrado
2.682 mensajes |
|
| Publicado el 09,febrero 2019 - 19:24 |
Bonjour,
Il n'existe pas, à ma connaissance, de rubrique horodatage comma dans HFSQL. Cependant la rubrique horodatage n'est jamais qu'une collen de type datetime en sql server ayant la valeur "default current_timestamp".
Il est tout à fait possible de créer une colonne calculée.
Je ne connais pas l'accès natif, il faut lire l'aide à ce sujet.
Pour la sauvegarde il faut lire l'aide, internet est ton meilleur ami.
--
Cordialement,
Philippe SAINT-BERTIN |
| |
| |
| | | |
|
| | |
| |
Miembro registrado
189 mensajes |
|
| Publicado el 12,febrero 2019 - 19:24 |
MICHEL a écrit :
"en évitant les jointures qui sont la bête noire de ce SGBD"
Why ?
J'ai repris un logiciel utilisant du HFSQL classique. Impossible de modifier : trop d'historique, trop de volume.
J'effectue des jointures dans des requêtes : Join, ou Left Join. Pour l'instant pas de difficultés (du moins à ce niveau)
Ce qui est bizarre c'est la façon dont WinDev rajoute des parenthèses dans les clauses Where mais cela fonctionne
C'est au niveau des contraintes dans l'analyse qu'il peut y avoir des soucis ?
Parce que les performances s'écroulent |
| |
| |
| | | |
|
| | |
| |
Miembro registrado
24 mensajes |
|
| Publicado el 16,febrero 2019 - 18:23 |
Ca va faire plus de 6 ans que je le pratique HFSQL. Son intégration aux outils PC SOFT et sa portabilité sont un vrai bonheur, aucun doute sur ce point.
Bonheur qu'on paye au prix fort: chaque applicatif que j'ai vu et dont la BDD s'est mise à grossir (ce qui est un peu le principe d'une BDD) a aussi vu ses performances s'écrouler.
Et souvent, ce n'est pas la faute de HFSQL: c'est tout simplement mal codé, et/ou mal désigné niveau analyse.
Par contre on explique pas pourquoi quand on testes certaines requêtes sur mySQL on obtient des temps de réponse bien plus rapides sur la même base transposée sur un serveur mySQL. De manière générale, HFSQL reste lent.
Evidemment, je ne parle pas des JOIN: quelques JOIN, et HFSQL est par terre, bon ça, c'est acté depuis longtemps dans le milieu.
Lorsqu'on me parle de gros volumes, je pose un frein à HFSQL car je ne l'ai jamais vu encaisser des volumes importants sans mettre un temps incommensurable. |
| |
| |
| | | |
|
| | |
| |
Miembro registrado
2.682 mensajes |
|
| Publicado el 17,febrero 2019 - 22:20 |
Pourtant au TDF, ils font une requête sur plein de milliards d’enregistrements et l'affichage est instantané...  (va comprendre...)
--
Cordialement,
Philippe SAINT-BERTIN |
| |
| |
| | | |
|
| | |
| |
| Publicado el 18,febrero 2019 - 08:56 |
Le 17/02/2019 à 21:20, Philippe SB a écrit :
Pourtant au TDF, ils font une requête sur plein de milliards d’enregistrements et l'affichage est instantané... (va comprendre...) -- Cordialement, Philippe SAINT-BERTIN
C'est instantané... oui il rapatrie maximum une vingtaine
d'enregistrement et mettons même un centaine...
je suppose quand même que leurs clés est très bien faites
mais le hic si tu dois rapatrier des milliers ... là il y aura des
problèmes.. comme dans toutes bases de données.
Attention avec MYSQL ... c'est pas gratuit!!!
Sauf si tu fais de l'open source... donc c'est aussi un solide critère.
pour ma part je suis très content de HF/SQL et j'ai quand même de
grosses basses de données qui marche depuis ... dix ou 20 ans
Le client/Serveur de PCSOFT rien à redire cla me convient. Je ne dis pas
qu'il n'y a pas mieux mais pour mes besoins ... |
| |
| |
| | | |
|
| | |
| |
Miembro registrado
954 mensajes |
|
| Publicado el 20,febrero 2019 - 13:37 |
| |
| |
| | | |
|
| | |
| |
| Publicado el 20,febrero 2019 - 15:28 |
Bonjour
Et comment accédez vous aux donneees d’une bdd postgressl? |
| |
| |
| | | |
|
| | |
| |
Miembro registrado
1.640 mensajes |
|
| Publicado el 20,febrero 2019 - 16:20 |
| @Alain : Je pense que tu devrais ouvrir un autre sujet pour ca, ce n'est pas vraiment le sujet ici |
| |
| |
| | | |
|
| | | | |
| | |
|