Discussione sull’articolo "SQLite: Gestione nativa dei database SQL in MQL5" - pagina 9

Nuovo commento
 

Maxim Kuznetsov #:

SQLite è progettato per un thread o per uno scrittore e molti lettori. Molti scrittori non ne fanno uso, ma si tratta di altre basi che non sono "leggere".

Non si tratta di MQL - è solo il modo in cui è realmente e ovunque.

E questo è un altro motivo per cui mi piacerebbe vedere PostgreSQL funzionare.

 
JRandomTrader #:

E questo è un altro motivo per cui vorrei che PostgreSQL funzionasse.

Allora fatelo, qual è il problema? Permettete la DLL e usatela.

Non sono un utente di PostgreSQL, ma ho usato MySQL, MonetDB, SQL Relay e ODBC da mt5.

Quando c'è una necessità, è più facile e veloce farlo da soli che aspettare i favori della natura.

 
Maxim Kuznetsov #:

la velocità di interrogazione diminuirà e i requisiti di memoria aumenteranno....

ma tutto va bene :-)

SQLite è progettato per un thread o per uno scrittore e molti lettori. Molti scrittori non ne parlano, su di esso altre basi che non sono "leggere".

Non si tratta di MQL - è solo il modo in cui è realmente e ovunque.

Forse non sapete come preparare SQLite, non ci sono colli di bottiglia in esso, cioè come un singolo server TCP, che distrugge tutti i flussi in arrivo, questo server è in tutti gli altri database ...

SQLite è un dono, se è adeguatamente preparato, la velocità delle richieste di scrittura sarà superiore a Redis, e per quanto riguarda la lettura stessa, mentre quando si legge dalla base i thread non si bloccano l'un l'altro e tutto avviene il più velocemente possibile riposando nelle vostre risorse di sistema, vi è anche data la possibilità di distribuire il database in RAM, non importa come, quando si crea, e si può attraverso un software speciale per creare un disco in RAM e su di esso per posizionare il database e creare un link simbolico, se si utilizza ad esempio per i consulenti, che fornirà le prestazioni più elevate possibili.

E forse non capite perché la condivisione della cache è necessaria in SQLite..., è necessaria per risparmiare risorse di memoria per l'input output, in modo che gli Expert Advisor e gli script consumino meno memoria alla fine, e solo perché un thread separato è allocato per il loro lavoro, un thread separato non è allocato per gli indicatori.

Quando si utilizza la modalità di cache condivisa, la connessione con la base viene aperta per l'intero processo, non per thread separati, il che fa risparmiare risorse, ma di conseguenza porta a errori simili a quelli descritti in precedenza e la cache condivisa rallenta il lavoro della base.

La decisione degli sviluppatori di MQL da un lato è comprensibile per me, ma dall'altro non molto, in quanto ho molta esperienza con la piattaforma e non ho incontrato casi in cui qualcuno ha eseguito più di 200 thread contemporaneamente, in 1 nel terminale limite di 100 grafici, in modo da poter allegare 1 Expert Advisor e 1 script a ciascuno, ma è anche possibile eseguire servizi sul numero di servizi penso che non vi sia alcun limite, ma non è almeno conveniente e ad alta intensità di risorse in ogni caso, e se questi thread hanno aperto le proprie connessioni al database è una goccia nell'oceano di memoria relativamente allora.

Un tale uso del terminale è quantomeno scomodo, e al massimo non ha senso, perché uno sviluppatore competente realizzerà un Expert Advisor multicurrency come singolo thread, e non si impegnerà in queste sciocchezze.

Cari sviluppatori, per favore rimuovete la cache comune o fatemi capire cosa mi è sfuggito.

Ho tratto il succo di"SQLite Shared-Cache" dalla documentazione ufficiale:

"Questo può ridurre significativamente la quantità di memoria e di IO richiesti dal sistema".

Ecco il link, leggetelo.

 

In MetaEditor, questi pulsanti (tranne Esegui) per lavorare con il database non funzionano ancora?


Sono sempre bloccati.

 

Questa query non restituisce nulla:

PRAGMA foreign_keys;

Il tentativo di includere una FOREIGN KEY fallisce:

    string query = "PRAGMA foreign_keys=ON;";
    if(!DatabaseExecute(m_db_handle, query)) {
      Print(__FUNCTION__, " > Query failed with code: ", GetLastError());
    }

La documentazione contiene queste informazioni: https: //www.sqlite.org/foreignkeys.html#fk_enable

Tip: If the command "PRAGMA foreign_keys" returns no data instead of a single row containing "0" or "1", then the version of SQLite you are using does not support foreign keys (either because it is older than 3.6.19 or

perché è stata compilata con SQLITE_OMIT_FOREIGN_KEY o SQLITE_OMIT_TRIGGER definiti).

SQLITE_OMIT_TRIGGER

Definendo questa opzione si omette il supporto per gli oggetti TRIGGER. In questo caso non sono disponibili né il comando CREATE TRIGGER né il comando DROP TRIGGER e il tentativo di eseguire uno di questi due comandi provocherà un errore di parsing. Questa opzione disabilita anche l'applicazione deivincoli di chiave esterna, poiché il codice che implementa i trigger e che viene omesso da questa opzione è utilizzato anche per implementarele azioni di chiave esterna.

SQLITE_OMIT_FOREIGN_KEY

Se questa opzione è definita, la sintassi dei vincoli di chiave esterna non viene riconosciuta.


Non c'è nulla di sbagliato nella versione:

//---

Come abilitare la FOREIGN KEY?

 
Anatoli Kazharski #:

Questa query non restituisce nulla:

Il tentativo di includere una FOREIGN KEY fallisce:

La documentazione contiene queste informazioni: https: //www.sqlite.org/foreignkeys.html#fk_enable


Non c'è nulla di sbagliato nella versione:

//---

Come abilitare la CHIAVE ESTERNA?

La FOREIGN KEY è abilitata per impostazione predefinita, non si utilizza SQLITE_OMIT_FOREIGN_KEY o SQLITE_OMIT_TRIGGER.

PRAGMA foreign_keys=ON; non deve essere utilizzato.


.

Per verificare le prestazioni si può prendere l'esempio https://www.sqlite.org/foreignkeys.html.

CREATE TABLE artist(
  artistid    INTEGER PRIMARY KEY, 
  artistname  TEXT
);

CREATE TABLE track(
  trackid     INTEGER, 
  trackname   TEXT, 
  trackartist INTEGER,
  FOREIGN KEY(trackartist) REFERENCES artist(artistid)
);

Quando si lavora nell'editor, tutto funziona correttamente senza errori.

 
Renat Fatkhullin #:

La FOREIGN KEY è abilitata per impostazione predefinita, non si utilizza SQLITE_OMIT_FOREIGN_KEY o SQLITE_OMIT_TRIGGER.

PRAGMA foreign_keys=ON; non deve essere utilizzato.


Per verificare le prestazioni si può prendere l'esempio https://www.sqlite.org/foreignkeys.html.

Quando si lavora nell'editor, tutto funziona correttamente senza errori.

Grazie per la risposta!

Per qualche motivo non ottengo il risultato che mi aspetto:

//---

Dov'è l'errore?

E questo è ciò che vorrei fare anch'io:

Forum sul trading, sui sistemi di trading automatico e sul test delle strategie di trading

Discussione dell'articolo "SQLite: lavoro nativo con i database SQL in MQL5".

Anatoli Kazharski, 2022.10.05 01:54 AM

In MetaEditor questi pulsanti (tranne Esegui) per lavorare con il database non funzionano ancora?


Sono sempre bloccati.

 

Chiedete a qualcuno di riprodurre l'esempio precedente.

L'ultima riga della tabella delle tracce (evidenziata) non deve essere aggiunta.

 

Ho testato lo stesso schema in SQLiteStudio e tutto funziona correttamente.

Ecco come dovrebbe apparire l'avviso quando si cerca di aggiungere una riga con un ID che non esiste nella tabella padre:


 
Grazie, lo controlleremo.
123456789101112
Nuovo commento