Discussione sull’articolo "Come accedere al database MySQL da MQL5 (MQL4)" - pagina 29
Ti stai perdendo delle opportunità di trading:
- App di trading gratuite
- Oltre 8.000 segnali per il copy trading
- Notizie economiche per esplorare i mercati finanziari
Registrazione
Accedi
Accetti la politica del sito e le condizioni d’uso
Se non hai un account, registrati
grazie per il chiarimento. Non posso sapere tutto, per questo chiedo.
Ho trovato la soluzione per me stesso qui.
P.S: controllato per SELECT - funziona
La conversione dei risultati della query è consentita, ma non bisogna dimenticare che la definizione di utf8mb4 è a livello di tabella, cioè per tutti i campi viene utilizzato varchar per impostazione predefinita, e se nella query è presente una condizione su un campo di testo, MySQL cercherà di convertirlo implicitamente. E se si tiene conto del fatto che è possibile che sia stato costruito un indice su una colonna di testo, l'ottimizzatore potrebbe non rilevarlo durante la conversione... con conseguenti problemi di prestazioni della query.
c'è un campo descrizione. Qualcosa come "commenti", il campo non è necessario, basta una spiegazione testuale. Non ci sarà alcun indice.
MySQL fa utf8mb4 per impostazione predefinita. Puoi dirmi come specificare nel DDL la prossima volta? Cosa cambiare e in quale codifica
Qualche idea?
Continuo a ricevere questo errore:
Sei riuscito a risolvere questo problema Boaz?
C'è un modo per conoscere il numero di campi che possono essere recuperati dopo MySqlCursorFetchRow?
Forse qualche funzione nascosta come RowFieldsSize ...
Da quanto ho capito, se non c'è nessun campo, MySqlGetFieldAsString restituisce vuoto. Ma anche se Campo stringa contiene specificamente un campo vuoto, restituisce anche vuoto. In altre parole, non è sempre possibile risalire al numero di campi con la forza bruta.
Come stampella si può scoprire attraverso il comando sql prima, ma poi selezionare di nuovo, ma questo è già un Select inutile.
Si prega di sviluppare la libreria, molto utile. Naturalmente molto tempo fa un paio di mysql per costruire in mt
Query di inserimento e aggiornamento - limite di query di soli 16 kb?
Se la query è superiore a 16.000 caratteri, metatrader si blocca (si chiude). Se è inferiore, va bene.
Allego un esempio di UPDATE per 32.000 caratteri.
Campo per l'aggiornamento nel database - LONGTEXT
Query di inserimento e aggiornamento - solo 16kb di limite di query?
Se la query supera i 16.000 caratteri, metatrader si blocca (si chiude). Se è inferiore, va bene.
Allego un esempio di UPDATE per 32.000 caratteri.
Campo per l'aggiornamento nel database - LONGTEXT
Questo è più simile a un limite di dimensione della riga in MQL :-(
e si può scrivere in modo più compatto:
REPLACE d1 ("t", "o", "h", "l", "c") VALUES (time1,open1,high1,low1,close1), (time2,open2,high2,low2,close2) ....
e/o dividere in due query combinandole in un'unica transazione
Ad esempio, ho dati di 50 000 elementi e li aggiorno nella tabella ogni 0,1 sec (numeri). MT5 sarà in grado di prenderli da MySQL e aggiornarli ogni 0,1 sec? C'è qualche limitazione della funzionalità fornita in questo articolo sui KB per 1 query?
Ciao! Domanda per gli esperti - quanti dati e con quale frequenza posso leggere da MySQL a MT5?
Ad esempio, ho dati di 50 000 elementi e li aggiorno nella tabella ogni 0,1 sec (numeri). MT5 sarà in grado di prenderli da MySQL e aggiornarli ogni 0,1 sec? C'è qualche limitazione della funzionalità fornita in questo articolo su KB per 1 query?
Beh, la domanda è sicuramente interessante...
Devo dire che non ci sono limiti al numero di righe della query SELECT restituite.
Il limite di dimensione della query stessa è di 64 Kb. Quindi, se si sta cercando di aggiornare 50k righe di dati, è meglio dividerli in lotti, ad esempio 1000 righe ciascuno, e quindi inviare 50 query.
Per quanto riguarda la velocità di 100 ms, se il database si trova su un server e il terminale in cui si esegue MQL con una connessione al database è piuttosto remoto, è molto probabile che si verifichi una latenza di rete, nella misura del ping....
Ad esempio, se si ha un ping di 60 ms tra il server del database e il terminale, la risposta effettiva del server sarà ritardata = 60 ms (query) + tempo di elaborazione della query sul lato del database + 60 ms (risposta).
Questo progetto è solo un semplice wrapper per accedere alle funzionalità delle librerie dinamiche mysql.
L'insieme delle funzionalità è limitato alle principali funzioni praticamente utili, si può espandere, aggiungere ciò che serve, ad esempio aggiungere il supporto per le query asincrone, e poi si possono inviare tutte le 50 query su 1000 righe senza aspettare l'esecuzione di ciascuna a turno.
P.S.: su Github è possibile vedere i sorgenti della libreria e i limiti preimpostati(https://github.com/elugovoy/MQLMySQL-Project/tree/master/MQLMySQL).
P.P.S.: è anche possibile scaricare, modificare a propria discrezione, compilare e testare.
C'è un modo per conoscere il numero di campi che possono essere recuperati dopo MySqlCursorFetchRow?
Forse c'è qualche funzione nascosta come RowFieldsSize ...
Da quanto ho capito, se non c'è nessun campo, MySqlGetFieldAsString restituisce vuoto. Ma anche se String Field contiene specificamente un campo vuoto, restituisce anch'esso vuoto. In altre parole, non è sempre possibile rintracciare il numero di campi con la forza bruta.
Come stampella si può scoprire prima attraverso il comando sql, ma poi selezionare di nuovo, ma questa è già una selezione non necessaria.
Si prega di sviluppare la libreria, molto utile. Naturalmente, un paio di mysql dovrebbero essere integrati in mt già da tempo
Hm... e che tipo di query sono così difficili da determinare il numero di campi restituiti?
Di solito il comando SELECT elenca solo ciò che è necessario in una particolare situazione. Non usare SELECT *, ma seleziona solo ciò che ti serve :) è una pratica normale.
Non si devono fare stampelle, si può prendere il codice sorgente da Github e aggiungere un wrapper per la funzione mysql_fetch_fields() dell'API MySQL