Discussione sull’articolo "Come accedere al database MySQL da MQL5 (MQL4)" - pagina 12
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
Esistono molte GUI/IDE di terze parti e sqlite stesso è solo un motore di database puro e un'API per incorporarlo nelle applicazioni...
L'API è davvero per tutto, anche per NET. Cercherò la GUI - potrebbe piacervi).
https://www.mql5.com/it/articles/862
Grazie, l'ho letto. C'è un'ottima osservazione da parte dell'autore dell'attuale articolo, che è arrivato,..... e ha rovinato tutto).
La possibilità di usarlo c'è ed è un bene. Un'altra cosa è che SQLite non dovrebbe essere usato per progetti seri. In ogni caso, non lo consiglio. Io stesso ho affrontato più di una volta il problema delle collisioni. Ad esempio, se un robot di trading è collegato a diversi grafici, ma utilizza la stessa base, e l'accesso è a una tabella di uso generale (ad esempio registrazione/modifica delle sessioni, conti), in ogni caso si otterrà un errore del tipo "tabella bloccata". E non importa se tutte le transazioni sono state completate, i cursori sono stati chiusi e il database è stato aperto in modalità condivisa. Questo problema è noto anche agli sviluppatori di SQLite.
A mio parere, MS Access è il migliore dei database con supporto SQL. Non importa quanto si possa rimproverare il popolo delle small-soft, ma io ho lasciato SQLite per MS Access e non me ne sono affatto pentito. Il driver OleDB Jet 4.0 è installato anche con Win98, in modo che i progetti funzionino su tutti i sistemi operativi Windows.
Ho già scritto in precedenza che Access è probabilmente il migliore, ed è quello che uso io. In caso estremo MS SQL Server, soprattutto ora che esiste una versione distribuita liberamente. E MySQL è troppo ingombrante, solo la distribuzione del server ~450 MB
Grazie, l'ho letto. C'è un'ottima osservazione da parte dell'autore dell'articolo attuale, che è arrivato,..... e ha rovinato tutto).
La possibilità di usarlo c'è ed è un bene. Un'altra cosa è che SQLite non dovrebbe essere usato per progetti seri. In ogni caso, non lo consiglio. Io stesso ho affrontato più di una volta il problema delle collisioni. Ad esempio, se un robot di trading è collegato a diversi grafici, ma utilizza la stessa base, e l'accesso è a una tabella di uso generale (ad esempio registrazione/modifica delle sessioni, conti), in ogni caso si otterrà un errore del tipo "tabella bloccata". E non importa se tutte le transazioni sono state completate, i cursori sono stati chiusi e il database è stato aperto in modalità condivisa. Questo problema è noto anche agli sviluppatori di SQLite.
A mio parere, MS Access è il migliore dei database con supporto SQL. Non importa quanto si possa rimproverare il popolo delle small-soft, ma io ho lasciato SQLite per MS Access e non me ne sono affatto pentito. Il driver OleDB Jet 4.0 è installato anche con Win98, in modo che i progetti funzionino su tutti i sistemi operativi Windows.
Ho già scritto in precedenza che Access è probabilmente il migliore. In caso estremo MS SQL Server, soprattutto ora che esiste una versione distribuita liberamente.
MS Access è una delle opzioni peggiori. Su VDS si muove a malapena. Quello che non si può dire di SQLite è che è molto veloce. C'è un problema (ma è lo stesso con MySQL e in generale con qualsiasi altro) - ora il modello è "un Expert Advisor=un trade e in più da qualche parte ci sono indicatori, grafico e terminale", ma può cambiare facilmente, inoltre tutto il codice base non è progettato per un lavoro competitivo, implica un uso monopolistico della risorsa, non c'è il blocco necessario, la sincronizzazione e così via. E tra l'altro rientra nella sezione delle perversioni - eseguire più di un Expert Advisor (anche se si tratta di istanze dello stesso) su un conto reale.
E se volete affidabilità con i plus - mettete Oracle (sarete sorpresi, ma per le esigenze dei robot è gratuito) e APEX, scrivete un connettore ad esso... E un'altra opzione - per guidare i dati attraverso Web-Request al modello REST.
PS/ perché discutere - finché MQ non distribuirà un connettore generalizzato per SQL tutti i tentativi di lavorare correttamente con i DBMS sono destinati a fallire. Questo è il caso in cui un componente non è realizzabile dalle forze della comunità.
E se volete un'affidabilità con dei vantaggi - mettete Oracle (sarete sorpresi, ma per le esigenze dei robot è gratuito) e APEX, scrivete un connettore ad esso... E un'altra opzione è quella di inviare i dati tramite Web-Request al modello REST.
Sì, conosco Oracle. Ho anche un paio di loro certificati in giro. Purtroppo non sono utili.
Per quanto riguarda Access, non è così lento. L'ho usato per tradurre le quotazioni in TS (connessione: terminale - base - TS). Cronologia, quotazioni attuali, stati, log, ecc. nel database. E questo per intrade. Non ci sono state lamentele sulla velocità del database.
Temo che SQLite non possa funzionare per un problema simile, per le ragioni indicate da Eugeniy Lugovoy.
Sì, conosco Oracle. Ho anche un paio di loro certificati in giro. Purtroppo non sono stati utili.
Per quanto riguarda Access, non è così lento. L'ho usato per tradurre le quotazioni in TS (connessione: terminale - base - TS). Cronologia, quotazioni attuali, stati, log, ecc. nel database. E questo per intrade. Non ci sono state lamentele sulla velocità del database.
Temo che SQLite non funzionerà per un problema simile, per le ragioni indicate da Eugeniy Lugovoy.
se non è un segreto, quale meccanismo è stato utilizzato in TC per leggere i dati da Assets?
TC - standard C# ADO.NET. Buffer C, loro aggiornamenti e scrittura sul database. Il terminale scrive i dati sul database tramite (non ricordo) - o ODBC, ma più probabilmente tramite Jet. Se siete interessati, vi darò un'occhiata più tardi. Terminal ha un'esportazione integrata verso il database (qualsiasi, se il driver è presente sul computer).
PS Sembra OLEDB
.
Un saluto a tutti! Ragazzi è da molto tempo che non guardo qui. Fa veramente caldo qui nelle discussioni :) Mi spiego meglio :)
Un paio di anni fa sono stato coinvolto in progetti in cui i requisiti erano molto diversi (analisi di mercato aggiuntiva da parte di software di terze parti, pubblicazione sul web con conservazione dello storico, applicazione di algoritmi genetici, emulazione del commercio, ecc. Poiché i requisiti erano diversi, la scelta del DBMS era corrispondente. Alla fine ho deciso di scrivere i driver MT4 RDBMS per ogni DBMS, in modo da utilizzare i driver nativi, ma non ODBC/OLEDB. Per esempio, per mysql - libmysql, per oracle - OCI/Instant client, per SQLite - la sua DLL con api, ma per i database Microsoft (Access/MS SQL) c'è solo l'opzione OLEDB. Tutto questo è stato scritto ed esiste fino ad ora, qui ho solo formato l'articolo per le basi MySQL, perché per lo spazio post-sovietico è ancora più vicino secondo la mia opinione soggettiva.
In generale, con i database ho lavorato abbastanza a lungo e densamente, e, l'emergere, lo sviluppo e la popolarità di SQLite non poteva che influenzarmi :) Ho scritto un rapper sotto la v3 e in un thread separato tutto va bene (cioè quando un grafico pesa l'EA), tuttavia, quando si testa su diversi grafici ho inaspettatamente ottenuto un blocco della tabella. Ho scritto appositamente gli EA di prova per aggiornare i dati (righe) solo dal proprio simbolo, cioè la tabella è la stessa, ma le righe sono diverse in modo da non causare il blocco. il risultato - blocco della tabella. E questo nonostante il fatto che il vrapper stesso utilizza mutex per eseguire le operazioni, cioè fino a quando un aggiornamento non è completato (+autocommit), l'altro non si avvia. in parole povere - il blocco di verificarsi da nessuna parte, se non all'interno del SQLite. Ho cercato nei forum e ho trovato che c'è effettivamente un problema del genere. Ho riscritto il ripper sotto OLEDB (la struttura di tutti i ripper è quasi identica, tranne che per i comandi per chiamare l'API del DBMS richiesto) e ho verificato su MS Access.... stessi script - nessun problema. MS SQL - nessun problema, PostgreSQL - nessun problema, connesso a Oracle - tutto ok.
Anche se è passato molto tempo, la sensazione di SQLite è rimasta... Non ho più fatto esperimenti. L'unico database simile (file e compatto con SQL) che ricordo era MSSQL Compact Edition, ma le mie mani non hanno raggiunto l'implementazione in questa direzione.
Alla fine mi sono rimasti due progetti - uno per MySQL (incluso MariaDB) e uno per OLEDB, che sebbene limiti le possibilità rispetto ai driver nativi (per esempio, lo stesso DBMS Oracle), sono abbastanza per implementare progetti di produzione. A questo proposito apprezzo la stabilità e le prestazioni della soluzione, oltre alla minimizzazione dei costi di manutenzione. Se in futuro sarà necessario passare a un altro DBMS, i costi saranno minimi: se si semplifica, è sufficiente riscrivere le query tenendo conto della sintassi del nuovo sottodatabase e, in generale, la logica del progetto non ne risentirà.
Grazie a tutti e buona fortuna!
Mi sono preso la briga di fare il "check out of the box": non funziona.
Saluti Pavel,
La prego di fornire le seguenti informazioni sul suo ambiente:
- Versione e bit del sistema operativo
- Versione, build e bitness del terminale
- Versione di MySQL
È piuttosto strano che il kernel non contenga una funzione per creare un mutex e che libmysql non contenga una funzione per determinare il numero di righe interessate dall'operazione...
Proverò a creare un ambiente simile e a verificare.
win 7 x64 - mt5 x64 ultima versione (v5 b1455)
Non riesco ad accedere a MySQL, ma non è un peccato.
Server: Localhost tramite socket UNIX
Tipo di server: Percona Server
Versione del server: 5.5.35-33.0-log - Percona Server (GPL), Release rel33.0, Revisione 611
Versione del protocollo: 10
Utente: ***
Codifica del server: UTF-8 Unicode (utf8)