Discussion de l'article "Comment accéder à la base de données MySQL à partir de MQL5 (MQL4)" - page 29
Vous manquez des opportunités de trading :
- Applications de trading gratuites
- Plus de 8 000 signaux à copier
- Actualités économiques pour explorer les marchés financiers
Inscription
Se connecter
Vous acceptez la politique du site Web et les conditions d'utilisation
Si vous n'avez pas de compte, veuillez vous inscrire
merci pour la clarification. Je ne peux pas tout savoir, c'est pourquoi je pose la question.
J'ai trouvé la solution ici.
P.S. : J'ai vérifié pour SELECT - cela fonctionne.
La conversion des résultats de requête est autorisée, mais il ne faut pas oublier que la définition de l'utf8mb4 se fait au niveau de la table, c'est-à-dire que pour tous les champs, varchar sera utilisé par défaut, et si vous avez une condition sur un champ texte dans votre requête, MySQL essaiera de le convertir implicitement. Et si vous prenez en compte le fait que vous pouvez avoir un index construit sur une colonne de texte, alors l'optimiseur peut ne pas l'identifier lors d'une telle conversion... d'où des problèmes de performance de la requête.
il existe un champ de description. Quelque chose comme "commentaires", le champ n'est pas nécessaire, juste une explication textuelle. Il n'y aura pas d'index.
MySQL utf8mb4 le fait par défaut. Pouvez-vous me dire comment le spécifier dans la DDL la prochaine fois ? Que changer et à quel encodage ?
Des idées ?
Je continue à obtenir cette erreur :
Avez-vous réussi à résoudre ce problème, Boaz ?
Existe-t-il un moyen de connaître le nombre de champs qui peuvent être récupérés après MySqlCursorFetchRow ?
Peut-être une fonction cachée comme RowFieldsSize ...
Si je comprends bien, s'il n'y a pas de champ, MySqlGetFieldAsString renvoie un champ vide. Mais si la chaîne Field contient spécifiquement un champ vide, elle renvoie également un champ vide. En d'autres termes, il n'est pas toujours possible de déterminer le nombre de champs par la force brute.
Comme béquille, on peut d'abord trouver par la commande sql, puis sélectionner à nouveau, mais c'est déjà un Select inutile.
S'il vous plaît, développez la bibliothèque, c'est très utile. Bien sûr, il y a longtemps, quelques mysql à intégrer dans mt.
Requête d'insertion et de mise à jour - seulement 16 kb de limite de requête ?
Si la requête est supérieure à 16.000 caractères, metatrader se bloque (se ferme). Si elle est inférieure, tout va bien.
Je joins un exemple d'UPDATE pour 32.000 caractères.
Champ de mise à jour dans la base de données - LONGTEXT
Requête d'insertion et de mise à jour - seulement 16kb de limite de requête ?
Si la requête est supérieure à 16.000 caractères, metatrader se bloque (se ferme). Si elle est inférieure, tout va bien.
Je joins un exemple d'UPDATE pour 32.000 caractères.
Champ de mise à jour dans la base de données - LONGTEXT
C'est plus comme une limite de taille de ligne dans MQL :-(
et vous pouvez écrire de manière plus compacte :
REPLACE d1 ("t", "o", "h", "l", "c") VALUES (time1,open1,high1,low1,close1), (time2,open2,high2,low2,close2) ....
et/ou divisée en deux requêtes en les combinant en une seule transaction
Par exemple, j'ai des données 50 000 éléments et je les mets à jour dans la table toutes les 0,1 sec (nombres). Est-ce que MT5 pourra les récupérer de MySQL et les mettre à jour toutes les 0,1 sec ? Y a-t-il une limitation de la fonctionnalité donnée dans cet article sur le KB per 1 query ?
Bonjour ! Question pour les experts - combien de données et à quelle fréquence puis-je lire de MySQL vers MT5 ?
Par exemple, j'ai des données 50 000 éléments et je les mets à jour dans la table toutes les 0,1 sec (nombres). Est-ce que MT5 pourra les récupérer de MySQL et les mettre à jour toutes les 0,1 sec ? Y a-t-il une limitation de la fonctionnalité donnée dans cet article sur KB for 1 query ?
La question est certainement intéressante...
Je dois dire qu'il n'y a pas de limite au nombre de lignes de la requête SELECT renvoyées.
La limite de taille pour la requête elle-même est de 64 Ko. Par conséquent, si vous essayez de mettre à jour 50 000 lignes de données, il est préférable de les diviser en lots, disons 1000 lignes chacun, et d'envoyer ainsi 50 requêtes.
En ce qui concerne la vitesse de 100 ms, si la base de données se trouve sur un serveur et que le terminal sur lequel vous exécutez MQL avec une connexion à la base de données est quelque peu éloigné, il est fort probable que vous rencontriez une latence réseau, de l'ordre du ping.....
Par exemple, si vous avez un ping de 60 ms entre le serveur de base de données et le terminal, la réponse réelle du serveur sera retardée = 60 ms (requête) + temps de traitement de la requête du côté de la base de données + 60 ms (réponse).
Ce projet n'est qu'une simple enveloppe permettant d'accéder aux fonctionnalités des bibliothèques mysql dynamiques.
L'ensemble des fonctionnalités est limité aux principales fonctions utiles en pratique, vous pouvez les étendre, ajouter ce dont vous avez besoin, par exemple ajouter le support des requêtes asynchrones, et alors vous pourrez envoyer les 50 requêtes sur 1000 lignes sans attendre l'exécution de chacune d'entre elles à tour de rôle.
P.S. : sur Github, vous pouvez voir les sources de la bibliothèque et les limites prédéfinies(https://github.com/elugovoy/MQLMySQL-Project/tree/master/MQLMySQL).
P.P.S. : vous pouvez également télécharger, modifier à votre guise, compiler et tester.
Existe-t-il un moyen de connaître le nombre de champs qui peuvent être récupérés après MySqlCursorFetchRow ?
Il y a peut-être une fonction cachée comme RowFieldsSize ...
Si je comprends bien, s'il n'y a pas de champ, MySqlGetFieldAsString renvoie un champ vide. Mais également si String Field contient spécifiquement un champ vide, il renvoie également un champ vide. En d'autres termes, il n'est pas toujours possible de déterminer le nombre de champs par force brute.
Comme béquille, on peut d'abord trouver la réponse par la commande sql, puis sélectionner à nouveau, mais c'est déjà une sélection inutile.
Il faut développer la bibliothèque, c'est très utile. Bien sûr, un couple de mysql devrait être intégré dans mt depuis longtemps
Hm... Et quel type de requête est si délicat pour vous qu'il est nécessaire de déterminer le nombre de champs retournés par celle-ci ?
En général, dans la commande SELECT, il ne faut lister que ce qui est nécessaire dans une situation particulière. N'utilisez pas SELECT *, ne sélectionnez que ce dont vous avez besoin :) c'est une pratique normale.
Vous ne devriez pas faire des béquilles, vous pouvez prendre le code source de Github et ajouter un wrapper pour la fonction mysql_fetch_fields() de l'API MySQL.