Discussion de l'article "Comment accéder à la base de données MySQL à partir de MQL5 (MQL4)" - page 12
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
Il existe de nombreux GUI/IDE tiers pour cela - et sqlite lui-même n'est qu'un pur moteur de base de données et une API pour l'intégrer dans des applications...
L'API est vraiment pour tout, y compris pour NET. Je vais chercher l'interface graphique - elle pourrait vous plaire).
https://www.mql5.com/fr/articles/862
Merci, je l'ai lu. L'auteur de l'article actuel, qui est arrivé, ....., et qui a tout gâché, y a fait une très bonne remarque. et a tout gâché).
La possibilité de l'utiliser est là et c'est bien. Une autre chose est que SQLite ne devrait pas être utilisé pour des projets sérieux. En tout cas, je ne le recommande pas. J'ai moi-même été confronté au problème des collisions plus d'une fois. Par exemple, si un robot de trading est attaché à différents graphiques, mais utilise la même base, et que l'accès se fait à une table à usage général (par exemple les sessions d'enregistrement/de changement, les comptes), vous obtiendrez dans tous les cas une erreur du type "table verrouillée". Et peu importe que toutes les transactions soient terminées, que les curseurs soient fermés et que la base de données ait été ouverte en mode partagé. Ce problème est également connu des développeurs de SQLite.
À mon avis, MS Access est la meilleure des bases de données de fichiers avec support SQL. Vous avez beau gronder les adeptes des petits logiciels, j'ai quitté SQLite pour MS Access et je ne le regrette pas du tout. Le pilote OleDB Jet 4.0 est installé même avec Win98, de sorte que les projets fonctionnent sur tous les systèmes d'exploitation Windows.
J'ai déjà écrit plus haut qu'Access est probablement le meilleur, et c'est ce que j'utilise. Dans le cas extrême, MS SQL Server, surtout maintenant qu'il existe une version distribuée gratuitement. Et MySQL est trop encombrant, seulement la distribution du serveur ~450 MB
Merci, je l'ai lu. L'auteur de l'article actuel, qui est arrivé, ....., et qui a tout gâché, a soulevé un très bon point. et a tout gâché).
La possibilité de l'utiliser existe et c'est une bonne chose. Une autre chose est que SQLite ne devrait pas être utilisé pour des projets sérieux. En tout cas, je ne le recommande pas. J'ai moi-même été confronté au problème des collisions plus d'une fois. Par exemple, si un robot de trading est attaché à différents graphiques, mais utilise la même base, et que l'adresse est celle d'une table à usage général (par exemple les sessions d'enregistrement/de changement, les comptes), vous obtiendrez dans tous les cas une erreur du type "table verrouillée". Et peu importe que toutes les transactions soient terminées, que les curseurs soient fermés et que la base de données ait été ouverte en mode partagé. Ce problème est également connu des développeurs de SQLite.
À mon avis, MS Access est la meilleure des bases de données de fichiers avec support SQL. Vous avez beau gronder les adeptes des petits logiciels, j'ai quitté SQLite pour MS Access et je ne le regrette pas du tout. Le pilote OleDB Jet 4.0 est installé même avec Win98, de sorte que les projets fonctionnent sur tous les systèmes d'exploitation Windows.
J'ai déjà écrit plus haut qu'Access est probablement le meilleur. Dans le cas extrême, MS SQL Server, surtout maintenant qu'il existe une version distribuée gratuitement.
MS Access est l'une des pires options. Sur le SDV, il bouge à peine. Ce que l'on ne peut pas dire de SQLite, c'est qu'il est très rapide. Il y a un problème (mais c'est la même chose avec MySQL et en général avec n'importe quel autre) - maintenant le modèle est "un conseiller expert = une transaction et en plus quelque part il y a des indicateurs, un graphique et un terminal", mais cela peut facilement changer, en plus tout dans la base de code n'est pas conçu pour un travail compétitif, cela implique une utilisation monopolistique de la ressource, il n'y a pas de blocage nécessaire, de synchronisation et ainsi de suite. Et d'ailleurs, cela fait partie de la section des perversions - de faire fonctionner plus d'un Expert Advisor (même si ce sont des instances du même) sur un compte réel.
Et si vous voulez de la fiabilité avec des peluches - mettez Oracle (vous serez surpris, mais pour les besoins des robots c'est gratuit) et APEX, écrivez un connecteur pour cela... Et une autre option - conduire les données par Web-Request vers le modèle REST.
PS/ pourquoi argumenter - tant que MQ ne déploiera pas un connecteur généralisé pour SQL, toutes les tentatives de travailler correctement avec les SGBD sont vouées à l'échec. C'est justement le cas lorsqu'un composant n'est pas réalisable par les forces de la communauté.
Et si vous voulez de la fiabilité avec des avantages - mettez Oracle (vous serez surpris, mais pour les besoins des robots c'est gratuit) et APEX, écrivez un connecteur pour lui... Une autre option est de conduire les données à travers Web-Request vers le modèle REST.
Oui, je connais Oracle. J'ai même quelques uns de leurs certificats qui traînent. Malheureusement, ils ne sont pas utiles.
Quant à Access, il n'est pas si lent. Je l'ai utilisé pour traduire des citations en TS (connexion : terminal - base - TS). Historique, cotations actuelles, états, logs, etc. dans la base de données. Et ceci pour intrade. Il n'y a pas eu de plaintes concernant la vitesse de la base de données.
Je crains que SQLite ne fonctionne pas pour un problème similaire, pour les raisons évoquées par Eugeniy Lugovoy.
Oui, je connais Oracle. J'ai même quelques uns de leurs certificats qui traînent. Malheureusement, ils n'ont pas été utiles.
Quant à Access, il n'est pas si lent. Je l'ai utilisé pour traduire des citations en TS (connexion : terminal - base - TS). Historique, cotations actuelles, états, logs, etc. dans la base de données. Et ceci pour intrade. Il n'y a pas eu de plaintes concernant la vitesse de la base de données.
Je crains que SQLite ne fonctionne pas pour un problème similaire, pour les raisons énoncées par Eugeniy Lugovoy.
si ce n'est pas un secret, quel mécanisme a été utilisé dans TC pour lire les données de Assets ?
TC - C# ADO.NET standard. Les tampons C, leurs mises à jour et l'écriture dans la base de données. Le terminal écrit les données dans la base de données via (je ne me souviens plus) - soit ODBC, mais plus probablement via Jet. Je regarderai plus tard si cela vous intéresse. Terminal a une exportation intégrée vers la base de données (n'importe laquelle, si le pilote est sur l'ordinateur).
PS On dirait OLEDB
.
Bonjour à tous ! Cela fait longtemps que je n'ai pas jeté un coup d'œil ici. Il fait vraiment chaud ici sur les discussions :) Permettez-moi de m'expliquer :)
Il y a quelques années, j'ai été impliqué dans des projets dont les exigences étaient très différentes (analyse supplémentaire du marché par un logiciel tiers, publication sur le web avec conservation de l'historique, application d'algorithmes génétiques, émulation commerciale, etc. Comme les exigences étaient différentes, le choix du SGBD correspondait. Finalement, j'ai décidé d'écrire des pilotes MT4 RDBMS pour chaque SGBD afin d'utiliser des pilotes natifs, mais pas ODBC/OLEDB. Par exemple, pour mysql - libmysql, pour oracle - OCI/Instant client, pour SQLite - sa DLL avec api, mais pour les bases de données Microsoft (Access/MS SQL) il n'y a que l'option OLEDB. Tout cela a été écrit et existe jusqu'à présent, je me suis contenté de rédiger l'article pour les bases MySQL, car pour l'espace post-soviétique, elles sont encore plus proches, selon mon opinion subjective.
En général, avec les bases de données j'ai travaillé assez longtemps et densément, et, l'émergence, le développement et la popularité de SQLite ne pouvait pas ne pas m'affecter :) J'ai écrit un rappeur sous v3 et dans un fil séparé tout est ok (i.e. quand un graphique pèse EA), cependant, en testant sur plusieurs graphiques j'ai obtenu de façon inattendue un verrouillage de table. J'ai spécialement écrit des EA de test pour mettre à jour les données (lignes) uniquement par leur propre symbole, c'est-à-dire que la table est la même mais les lignes sont différentes afin de ne pas causer de blocage. Et ce malgré le fait que le vrapper lui-même utilise des mutex pour effectuer des opérations, c'est-à-dire que tant qu'une mise à jour n'est pas terminée (+autocommit), l'autre ne démarre pas. en clair - le verrou ne se produit nulle part, sauf à l'intérieur de SQLite. J'ai cherché sur les forums et j'ai trouvé qu'il y avait effectivement un tel problème. J'ai réécrit le ripper sous OLEDB (la structure de tous les rippers est presque identique, à l'exception des commandes pour appeler l'API du SGBD requis) et j'ai vérifié sur MS Access..... mêmes scripts - aucun problème. MS SQL - aucun problème, PostgreSQL - aucun problème, connecté à Oracle - tout va bien également.
Et bien que ce soit il y a longtemps, l'impression de SQLite est restée ... Je n'ai plus expérimenté. La seule base de données similaire (fichier et compact avec SQL) dont je me souvienne était MSSQL Compact Edition, mais mes mains n'ont pas atteint l'implémentation dans cette direction.
En fin de compte, il me reste deux projets - un pour MySQL (y compris MariaDB) et un pour OLEDB, qui bien que limitant les possibilités par rapport aux pilotes natifs (par exemple, le même SGBD Oracle), sont tout à fait suffisants pour mettre en œuvre des projets de production. A cet égard, j'accorde de l'importance à la stabilité et à la performance de la solution, ainsi qu'à la minimisation des coûts de maintenance. En effet, s'il est nécessaire de passer à un autre SGBD dans le futur, les coûts seront minimes - si vous simplifiez, vous n'aurez qu'à réécrire les requêtes en tenant compte de la syntaxe de la nouvelle sous-base de données, et en général, la logique du projet ne sera pas affectée.
Merci à tous et bonne chance !
J'ai pris la peine d'effectuer un "check out of the box" - cela ne fonctionne pas.
Bonjour Pavel,
Veuillez fournir les informations suivantes sur votre environnement :
- Version et bitness du système d'exploitation
- Version, build et bitness du terminal
- Version de MySQL
Il est assez étrange que le noyau ne contienne pas de fonction pour créer un mutex, et que la librairie MySQL ne contienne pas de fonction pour déterminer le nombre de lignes affectées par l'opération...
Je vais essayer de créer un environnement similaire et vérifier.
win 7 x64 - mt5 x64 dernière version (v5 b1455)
Je n'arrive pas à accéder à MySQL, mais ce n'est pas dommage.
Serveur : Localhost via socket UNIX
Type de serveur : Percona Server
Version du serveur : 5.5.35-33.0-log - Percona Server (GPL), Release rel33.0, Revision 611
Version du protocole : 10
Utilisateur : ***
Encodage du serveur : UTF-8 Unicode (utf8)