"SQL ve MQL5: SQLite Veritabanı ile Çalışmak" makalesi için tartışma
Birkaç önemli ekleme var (ve iyileştirme önerileri:))
1. Yazar sqlite_open() işlevini kullanıyor, ancak açılış bayraklarıyla çalışabilen daha esnek bir sqlite_open_v2() işlevi var, bu da şu anlama geliyor: - veritabanı dosyasına erişim sınırlamasını kontrol etmek; - geçici bellek içi veritabanları oluşturmak; - veritabanıyla yalnızca yerel dosya sisteminde değil, URI ile çalışmak vb.
#define SQLITE_OPEN_READONLY 0x00000001 /* sqlite3_open_v2() için tamam */ #define SQLITE_OPEN_READWRITE 0x00000002 /* sqlite3_open_v2() için tamam */ #define SQLITE_OPEN_CREATE 0x00000004 /* sqlite3_open_v2() için tamam */ #define SQLITE_OPEN_DELETEONCLOSE 0x00000008 /* Yalnızca VFS */ #define SQLITE_OPEN_EXCLUSIVE 0x00000010 /* Yalnızca VFS */ #define SQLITE_OPEN_AUTOPROXY 0x00000020 /* Yalnızca VFS */ #define SQLITE_OPEN_URI 0x00000040 /* sqlite3_open_v2() için tamam */ #define SQLITE_OPEN_MEMORY 0x00000080 /* sqlite3_open_v2() için tamam */ #define SQLITE_OPEN_MAIN_DB 0x00000100 /* Yalnızca VFS */ #define SQLITE_OPEN_TEMP_DB 0x00000200 /* Yalnızca VFS */ #define SQLITE_OPEN_TRANSIENT_DB 0x00000400 /* Yalnızca VFS */ #define SQLITE_OPEN_MAIN_JOURNAL 0x00000800 /* Yalnızca VFS */ #define SQLITE_OPEN_TEMP_JOURNAL 0x00001000 /* Yalnızca VFS */ #define SQLITE_OPEN_SUBJOURNAL 0x00002000 /* Yalnızca VFS */ #define SQLITE_OPEN_MASTER_JOURNAL 0x00004000 /* Yalnızca VFS */ #define SQLITE_OPEN_NOMUTEX 0x00008000 /* sqlite3_open_v2() için tamam */ #define SQLITE_OPEN_FULLMUTEX 0x00010000 /* sqlite3_open_v2() için tamam */ #define SQLITE_OPEN_SHAREDCACHE 0x00020000 /* sqlite3_open_v2() için tamam */ #define SQLITE_OPEN_PRIVATECACHE 0x00040000 /* sqlite3_open_v2() için tamam */ #define SQLITE_OPEN_WAL 0x00080000 /* Yalnızca VFS */
2. Hesaplamalarda "ağır" bir gösterge kullandığında EA optimizasyonunu hızlandırma sorununu çözmek için sqlite kullanıyorum. Böyle bir durumda mantıksal çözüm, ilk çalıştırma sırasında veritabanındaki optimizasyon dönemi için gösterge okumalarını kaydetmek ve sonraki çalıştırmalar sırasında - zaten hesaplanmış okumaları doğrudan veritabanından çıkarmaktır. Dolayısıyla, sqlite motorunu "varsayılan biçimde" kullanırsanız, çok sayıda INSERT ve SELECT sorgusu gönderme işlemi çok zaman almaya başlar. Pratik olarak, çıkış yolunun 1) bellek içi veritabanı kullanmak olduğu bulunmuştur, ancak verileri daha sonra bırakmak istiyorsak bu her zaman iyi değildir ve 2) SQL motorunun #pragma-directives.
İkinci seçenek daha çok tercih edilir, çünkü veritabanını RAM'den diske dökme ihtiyacını ortadan kaldırır. Bu şu şekilde yapılır: veritabanında ilk tabloyu oluşturmadan önce aşağıdaki sorguları göndermek gerekir:
"PRAGMA temp_store = MEMORY;" "PRAGMA page_size = 65536;" "PRAGMA cache_size = 16384;" "PRAGMA journal_mode = OFF;" "PRAGMA locking_mode = EXCLUSIVE;" "PRAGMA synchronous = OFF;"
Peki, ve bundan sonra şunları yapabilirsiniz
"CREATE TABLE IF NOT EXISTS"vs.
Herkese iyi şanslar!
Birkaç önemli ekleme var (ve iyileştirme önerileri:))
1. Yazar sqlite_open() işlevini kullanmaktadır, ancak açılış bayraklarıyla çalışabilen daha esnek bir sqlite_open_v2() işlevi vardır, bu da şu anlama gelir: - veritabanı dosyasına erişim sınırlamasını kontrol etmek; - geçici bellek içi veritabanları oluşturmak; - veritabanıyla yalnızca yerel dosya sisteminde değil, URI ile çalışmak vb.
2. Hesaplamalarda "ağır" bir gösterge kullandığında EA optimizasyonunu hızlandırma sorununu çözmek için sqlite kullanıyorum. Böyle bir durumda mantıksal çözüm, ilk çalıştırma sırasında veritabanındaki optimizasyon dönemi için gösterge okumalarını kaydetmek ve sonraki çalıştırmalar sırasında - zaten hesaplanmış okumaları doğrudan veritabanından çıkarmaktır. Dolayısıyla, sqlite motorunu "varsayılan biçimde" kullanırsanız, çok sayıda INSERT ve SELECT sorgusu gönderme işlemi çok zaman almaya başlar. Pratikte, çözümün 1) bellek içi veritabanı kullanmak olduğu bulunmuştur, ancak bu, verileri daha sonra bırakmak istiyorsak her zaman iyi değildir ve 2) SQL motorunun #pragma-directives'i.
İkinci seçenek daha çok tercih edilir, çünkü veritabanını RAM'den diske dökme ihtiyacını ortadan kaldırır. Bu şu şekilde yapılır: veritabanında ilk tabloyu oluşturmadan önce aşağıdaki sorguları göndermelisiniz:
Peki, ondan sonra da
vs.
Herkese iyi şanslar!
Test cihazını çalıştırırken gösterge okumalarının verileri doğası gereği basit bir dizidir, sıralı erişime sahip bir akış, bu nedenle SQL tabanında kaydetmek ve okumak gereksizdir ve mantıklı değildir.
Aynı şey, makalenin yazarı tarafından SQLite uygulamasının bir örneği olarak önerilen ticari işlemlerin listesi için de söylenebilir.
Bu nedenle, ilişkisel, çok bağlantılı veri modellerini kullanmanın verimliliğinin öncelikle çözülmekte olan görevlere bağlı olduğunu ve bu örneklerde IMHO'nun yalnızca "kulaklarından çekilebileceğini" fark etmeliyiz.
.
Test cihazı çalışması sırasında okunan gösterge verileri doğası gereği basit bir dizidir, seri erişime sahip bir akımdır, bu nedenle SQL tabanına kaydedilmesi ve okunması gereksizdir ve mantıklı değildir.
Gereksiz ve mantıklı olmasa da tekrar okuyun: Uzman Danışmanı optimize etmek için
Kullanmak mümkündür ve iyidir. Başka bir şey de SQLite 'ın ciddi projeler için kullanılmaması gerektiğidir. Her halükarda tavsiye etmem. Ben kendim birden fazla kez çarpışma sorunuyla karşılaştım. Örneğin, bir ticaret robotu farklı grafiklere bağlıysa, ancak aynı tabanı kullanıyorsa ve erişim genel amaçlı bir tabloya (örneğin kayıt / değiştirme oturumları, hesaplar) ise, her durumda "tablo kilitli" gibi bir hata alırsınız. Ve tüm işlemlerin tamamlanmış, imleçlerin kapatılmış ve veritabanının paylaşımlı modda açılmış olması önemli değildir. Bu sorun SQLite geliştiricileri tarafından da bilinmektedir.
Bence MS Access, SQL destekli dosya veritabanlarının en iyisidir. Küçük yazılımcıları ne kadar azarlarsanız azarlayın, ben SQLite'ı MS Access için bıraktım ve bundan hiç pişman değilim. OleDB sürücüsü Jet 4.0 Win98'de bile yüklüdür, böylece projeler tüm OC Windows'larda çalışır.
Öncelikle çalışmalarınız için çok teşekkürler!
Başarıyla mql4'e taşıdım! (bazı #property strict, derleme hatalarını çözdü.)
Ve 32bit platform kullandığım için 64bit ile ilgili bazı import fonksiyonlarını yorumlamak ve silmek zorunda kaldım. Terrminal erken bağlama kullanır, bu nedenle 64 bit-dll de program yüklenirken yüklen meye çalışır. (kullanılmamasına rağmen, sadece 32bit.dll.).Bu hata yaptı.
Ama her neyse, uygulamanızı beğendim! (Keşke ben de sizinki kadar iyi bir program yazabilseydim)
Komut dosyası çalışmıyor, kutudan çıktığı gibi çalışmıyor, bu tür projeleri çöpe atıyor.
Konsolda https://s.mail.ru/9dWTNLqx6RT2/img-2015-11-10-20-15-44.png adresini verir
В таблице https://s.mail.ru/QZyK6HwhMvo9/img-2015-11-10-20-16-18.png
Код https://s.mail.ru/2ooLdMg5MrHP/img-2015-11-10-20-16-56.png
Komut dosyası çalışmıyor, kutudan çıktığı gibi çalışmıyor.
Ne yapacağınızı ve nasıl yapacağınızı anlamıyorsanız kılavuzu tüttürün.
- Ücretsiz alım-satım uygulamaları
- İşlem kopyalama için 8.000'den fazla sinyal
- Finansal piyasaları keşfetmek için ekonomik haberler
Gizlilik ve Veri Koruma Politikasını ve MQL5.com Kullanım Şartlarını kabul edersiniz
Yeni makale SQL ve MQL5: SQLite Veritabanı ile Çalışmak yayınlandı:
Bu makale, projelerinde SQL kullanmak isteyen geliştiricilere yöneliktir. SQLite'ın işlevselliğini ve avantajlarını açıklar. Makale, SQLite işlevleri hakkında özel bilgi gerektirmez, ancak SQL'in minimum düzeyde anlaşılması faydalı olacaktır.
Script dosyası hesaba uygulandıktan sonra, hesap anlaşmalarını anında tabloya ekler.
İstatistikler terminal günlüğünde görüntülenir
Komut dosyasıyla oynayabilirsiniz: BEGIN, ROLLBACK ve COMMIT içeren satırları yorumlayın. Hesabınızda yüzlerce fırsat varsa farkı hemen göreceksiniz. Bu arada some tests adresine göre, SQLite işlemleeri MySQL veya PostgreSQL'den daha hızlı çalışıyor.
Yazar: ---