"MQL5'ten (MQL4) MySQL Veritabanına Nasıl Erişilir" makalesi için tartışma - sayfa 12
Alım-satım fırsatlarını kaçırıyorsunuz:
- Ücretsiz alım-satım uygulamaları
- İşlem kopyalama için 8.000'den fazla sinyal
- Finansal piyasaları keşfetmek için ekonomik haberler
Kayıt
Giriş yap
Gizlilik ve Veri Koruma Politikasını ve MQL5.com Kullanım Şartlarını kabul edersiniz
Hesabınız yoksa, lütfen kaydolun
Bunun için pek çok üçüncü taraf GUI/IDE vardır - ve sqlite'ın kendisi sadece saf bir veritabanı motoru ve onu uygulamalara yerleştirmek için API'dir...
API, NET dahil olmak üzere gerçekten her şey içindir. GUI'ye bakacağım - hoşunuza gidebilir).
https://www.mql5.com/tr/articles/862
Teşekkürler, okudum. Şu anki makalenin yazarının çok iyi bir tespiti var, kendisi geldi,..... ve her şeyi mahvetti).
Kullanma olasılığı var ve bu iyi bir şey. Başka bir şey de SQLite'ın ciddi projeler için kullanılmaması gerektiğidir. Her durumda, bunu 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 ile bile yüklenir, böylece projeler tüm OC Windows'ta çalışır.
Access'in muhtemelen en iyisi olduğunu daha önce yazmıştım, ki ben de bunu kullanıyorum. Aşırı durumda MS SQL Server, özellikle şimdi serbestçe dağıtılan bir sürümü var. Ve MySQL çok hantal, sadece sunucu dağıtımı ~450 MB
Teşekkürler, okudum. Şu anki makalenin yazarının çok iyi bir tespiti var, kim geldi,..... ve her şeyi mahvetti).
Kullanma olasılığı var ve bu iyi bir şey. Başka bir şey de SQLite'ın ciddi projeler için kullanılmaması gerektiğidir. Her durumda, bunu 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 ile bile yüklenir, böylece projeler tüm OC Windows'ta çalışır.
Access'in muhtemelen gerçekten en iyisi olduğunu daha önce yazmıştım. En uç durumda MS SQL Server, özellikle de artık serbestçe dağıtılan bir sürümü var.
MS Access en kötü seçeneklerden biridir. VDS üzerinde zar zor hareket ediyor. Aynı SQLite hakkında ne söylenemez - çok hızlıdır. Bir sorun var (ancak MySQL ve genel olarak diğerleri ile aynı) - şimdi model "bir Uzman Danışman = bir ticaret ve artı bir yerde göstergeler, grafik ve terminal var", ancak kolayca değişebilir, ayrıca kod tabanındaki her şey rekabetçi çalışma için tasarlanmamıştır, kaynağın tekel kullanımı anlamına gelir, gerekli engelleme, senkronizasyon vb. yoktur. Ve bu arada, sapkınlıklar bölümünden - gerçek bir hesapta birden fazla Uzman Danışmanı (aynı örnek olsalar bile) çalıştırmak.
Ve eğer peluşlarla güvenilirlik istiyorsanız - Oracle (şaşıracaksınız, ancak robotların ihtiyaçları için ücretsizdir) ve APEX'i koyun, ona bir bağlayıcı yazın ... Ve başka bir seçenek - verileri Web-Request aracılığıyla REST modeline yönlendirmek.
Not: Neden tartışalım - MQ SQL'e genelleştirilmiş bir bağlayıcı sunmayana kadar DBMS ile doğru şekilde çalışmaya yönelik tüm girişimler başarısızlığa mahkumdur. Bu, bir bileşenin topluluk güçleri tarafından gerçekleştirilemediği durumdur
Artılarla birlikte güvenilirlik istiyorsanız - Oracle (şaşıracaksınız, ancak robotların ihtiyaçları için ücretsizdir) ve APEX'i koyun, ona bir bağlayıcı yazın ... Ve başka bir seçenek de verileri Web-Request aracılığıyla REST modeline yönlendirmektir.
Evet, Oracle'ı biliyorum. Hatta etrafta birkaç sertifikaları bile var. Ne yazık ki kullanışlı değiller.
Access'e gelince, o kadar da yavaş değil. Alıntıları TS'ye çevirmek için kullandım (bağlantı: terminal - base - TS). Veritabanında geçmiş, güncel kotasyonlar, durumlar, günlükler vb. Ve bu intrade için. Veritabanı hızı hakkında hiçbir şikayet yoktu.
Eugeniy Lugovoy tarafından belirtilen nedenlerden dolayı SQLite'ın benzer bir sorun ifadesi için çalışmayacağından korkuyorum.
Evet, Oracle'ı biliyorum. Hatta birkaç sertifikaları bile var. Ne yazık ki işe yaramadılar.
Access 'e gelince, o kadar da yavaş değil. Alıntıları TS'ye çevirmek için kullandım (bağlantı: terminal - base - TS). Veritabanında geçmiş, güncel kotasyonlar, durumlar, günlükler vb. Ve bu intrade için. Veritabanı hızı hakkında hiçbir şikayet yoktu.
Korkarım ki SQLite, Eugeniy Lugovoy tarafından belirtilen nedenlerden dolayı benzer bir sorun ifadesi için çalışmayacaktır.
eğer bu bir sır değilse, TC'de Varlıklardan veri okumak için hangi mekanizma kullanıldı?
TC - standart C# ADO.NET. C tamponları, bunların güncellemeleri ve veritabanına yazılması. Terminal, verileri veritabanına (hatırlayamıyorum) - ODBC aracılığıyla, ancak daha büyük olasılıkla Jet aracılığıyla yazar. Eğer ilgilenirseniz daha sonra bakarım. Terminalin veritabanına dahili aktarımı vardır (sürücü bilgisayardaysa herhangi biri).
Not: OLEDB gibi görünüyor
.
Herkese selamlar! Arkadaşlar uzun zamandır buraya bakmamıştım. Burada tartışmalar gerçekten çok sıcak :) Kendimi açıklamama izin verin :)
Birkaç yıl önce, gereksinimlerin oldukça farklı olduğu projelerde yer aldım (üçüncü taraf yazılımlar tarafından ek piyasa analizi, geçmişi koruyarak web'de yayınlama, genetik algoritmaların uygulanması, ticaret emülasyonu, vb), ancak verilerin veritabanında olması uygun oldu. Gereksinimler farklı olduğu için DBMS seçimi de buna karşılık geliyordu. Ve sonunda, ODBC/OLEDB yerine yerel sürücüleri kullanmak için her DBMS için MT4 RDBMS sürücüleri yazmaya karar verdim. Yani mysql için - libmysql, oracle için - OCI/Instant client, SQLite için - api ile DLL, ancak Microsoft veritabanları (Access/MS SQL) için sadece OLEDB seçeneği var. Tüm bunlar şimdiye kadar yazıldı ve mevcut, burada sadece MySQL tabanları için makale oluşturdum, çünkü Sovyet sonrası alan için benim öznel görüşüme göre hala daha yakın.
Genel olarak, veritabanları ile yeterince uzun ve yoğun çalıştım ve SQLite'ın ortaya çıkışı, gelişimi ve popülaritesi beni etkilemeden edemedi :) V3 altında bir rapçi yazdım ve ayrı bir iş parçacığında her şey yolunda (yani bir grafik EA ağırlığında olduğunda), ancak birkaç grafik üzerinde test ederken beklenmedik bir şekilde bir tablo kilidi aldım. Verileri (satırları) yalnızca kendi sembolüyle güncellemek için özel olarak test EA'ları yazdım, yani tablo aynı ancak satırlar loc'a neden olmamak için farklı. sonuç - tablo loc. Ve bu, vrapper'ın kendisinin işlemleri gerçekleştirmek için muteksler kullanmasına rağmen, yani bir güncelleme tamamlanana kadar (+autocommit), diğeri başlamayacaktır. basitçe söylemek gerekirse - loc, SQLite'ın kendisi dışında hiçbir yerde gerçekleşmez. Forumları araştırdım ve gerçekten de böyle bir sorun olduğunu gördüm. Ripper'ı OLEDB altında yeniden yazdım (gerekli DBMS'nin API'sini çağırmak için komutlar dışında tüm ripper'ların yapısı neredeyse aynıdır) ve MS Access.... üzerinde kontrol ettim aynı komut dosyaları - sorun yok. MS SQL - sorun yok, PostgreSQL - sorun yok, Oracle'a bağlı - hepsi de tamam.
Ve oldukça uzun zaman önce olmasına rağmen, SQLite hissi kaldı ... Daha fazla deneme yapmadım. Hatırladığım tek benzer veritabanı (SQL ile dosya ve kompakt) MSSQL Compact Edition idi, ancak ellerim bu yönde uygulamaya ulaşmadı.
Sonunda iki projem kaldı - biri MySQL (MariaDB dahil) ve diğeri OLEDB için, yerel sürücülere kıyasla olasılıkları sınırlasa da (örneğin, aynı DBMS Oracle), ancak üretim projelerini uygulamak için oldukça yeterli. Bu bağlamda, çözümün kararlılığına + performansına ve ayrıca bakım maliyetlerinin en aza indirilmesine değer veriyorum. Gelecekte başka bir DBMS'ye geçmek gerekirse, maliyetler minimum olacaktır - basitleştirirseniz, yalnızca yeni alt veritabanının sözdizimini dikkate alarak sorguları yeniden yazmanız gerekir ve genel olarak projenin mantığı etkilenmeyecektir.
Hepinize teşekkürler ve iyi şanslar!
"Kutunun dışını kontrol etme" zahmetine katlandım - çalışmıyor.
Selamlar Pavel,
Lütfen ortamınız hakkında aşağıdaki bilgileri sağlayın:
- İşletim sisteminin sürümü ve bitliği
- Terminalin sürümü, yapısı ve bitliği
- MySQL sürümü
Çekirdeğin muteks oluşturmak için bir fonksiyon içermemesi ve libmysql'in işlemden etkilenen satır sayısını belirlemek için bir fonksiyon içermemesi oldukça garip...
Benzer bir ortam oluşturup kontrol etmeye çalışacağım.
win 7 x64 - mt5 x64 son sürüm (v5 b1455)
MySQL'e ulaşamıyorum, ama bu üzücü değil.
Sunucu: UNIX soketi üzerinden localhost
Sunucu türü: Percona Server
Sunucu Sürümü: 5.5.35-33.0-log - Percona Server (GPL), Sürüm rel33.0, Revizyon 611
Protokol Sürümü: 10
Kullanıcı: ***
Sunucu kodlaması: UTF-8 Unicode (utf8)