Discussão do artigo "Como acessar o banco de dados MySQL a partir do MQL5 (MQL4)" - página 12
Você está perdendo oportunidades de negociação:
- Aplicativos de negociação gratuitos
- 8 000+ sinais para cópia
- Notícias econômicas para análise dos mercados financeiros
Registro
Login
Você concorda com a política do site e com os termos de uso
Se você não tem uma conta, por favor registre-se
Há muitas GUIs/IDEs de terceiros para ele, e o próprio sqlite é apenas um mecanismo de banco de dados puro e uma API para incorporá-lo em aplicativos...
A API é realmente para tudo, inclusive para a NET. Vou procurar a GUI - talvez você goste dela).
https://www.mql5.com/pt/articles/862
Obrigado, eu o li. Há uma observação muito boa do autor do artigo atual, que apareceu, ..... e estragou tudo).
A possibilidade de usá-lo existe e isso é bom. Outra coisa é que o SQLite não deve ser usado em projetos sérios. Em todo caso, eu não o recomendaria. Eu mesmo já enfrentei o problema de colisões com ele mais de uma vez. Por exemplo, se um robô de negociação estiver conectado a diferentes gráficos, mas usar a mesma base, e o acesso for a uma tabela de uso geral (digamos, sessões de registro/alteração, contas), em qualquer caso, você receberá um erro como "tabela bloqueada". E não importa se todas as transações foram concluídas, se os cursores foram fechados e se o banco de dados foi aberto no modo compartilhado. Esse problema também é conhecido pelos desenvolvedores do SQLite.
Na minha opinião, o MS Access é o melhor dos bancos de dados de arquivos com suporte a SQL. Não importa o quanto você repreenda o pessoal da pequena software, mas eu troquei o SQLite pelo MS Access e não me arrependo nem um pouco. O driver Jet 4.0 do OleDB é instalado até mesmo no Win98, de modo que os projetos funcionam em todos os Windows OC.
Já escrevi anteriormente que o Access é provavelmente o melhor, que é o que eu uso. Em casos extremos, o MS SQL Server, especialmente agora que existe uma versão distribuída gratuitamente. E o MySQL é muito volumoso, somente a distribuição do servidor tem ~450 MB
Obrigado, eu li o artigo. O autor do artigo atual, que entrou no site ..... e arruinou tudo).
A possibilidade de usá-lo existe e isso é bom. Outra coisa é que o SQLite não deve ser usado em projetos sérios. Em todo caso, eu não o recomendaria. Eu mesmo já enfrentei o problema de colisões com ele mais de uma vez. Por exemplo, se um robô de negociação estiver conectado a diferentes gráficos, mas usar a mesma base, e o acesso for a uma tabela de uso geral (digamos, sessões de registro/alteração, contas), em qualquer caso, você receberá um erro como "tabela bloqueada". E não importa se todas as transações foram concluídas, se os cursores foram fechados e se o banco de dados foi aberto no modo compartilhado. Esse problema também é conhecido pelos desenvolvedores do SQLite.
Na minha opinião, o MS Access é o melhor dos bancos de dados de arquivos com suporte a SQL. Não importa o quanto você repreenda o pessoal da pequena software, mas eu troquei o SQLite pelo MS Access e não me arrependo nem um pouco. O driver Jet 4.0 do OleDB é instalado até mesmo no Win98, de modo que os projetos funcionam em todos os Windows OC.
Já escrevi anteriormente que o Access é provavelmente o melhor. Em casos extremos, o MS SQL Server, especialmente agora que existe uma versão distribuída gratuitamente.
O MS Access é uma das piores opções. No VDS, ele mal se move. O que não pode ser dito sobre o mesmo SQLite - ele é muito rápido. Há um problema (mas é o mesmo com o MySQL e, em geral, com qualquer outro) - agora o modelo é "um Expert Advisor = uma operação e, além disso, em algum lugar há indicadores, gráfico e terminal", mas isso pode mudar facilmente, além disso, tudo na base de código não é projetado para o trabalho competitivo, implica o uso monopolista do recurso, não há bloqueio necessário, sincronização e assim por diante. E, a propósito, é da seção de perversões - executar mais de um Expert Advisor (mesmo que sejam instâncias do mesmo) em uma conta real.
E, se você quiser confiabilidade com os bonecos, coloque o Oracle (você ficará surpreso, mas, para as necessidades dos robôs, ele é gratuito) e o APEX, escreva um conector para ele... E outra opção - direcionar os dados por meio de solicitação da Web para o modelo REST.
PS/ por que argumentar - até que o MQ não lance um conector generalizado para o SQL, todas as tentativas de trabalhar corretamente com o DBMS estão fadadas ao fracasso. É exatamente esse o caso quando um componente não pode ser realizado pelas forças da comunidade
E se quiser confiabilidade com vantagens, coloque o Oracle (você ficará surpreso, mas, para as necessidades dos robôs, ele é gratuito) e o APEX, escreva um conector para ele... E outra opção é direcionar os dados por meio de solicitação da Web para o modelo REST.
Sim, eu conheço a Oracle. Tenho até alguns de seus certificados espalhados por aí. Infelizmente, eles não são úteis.
Quanto ao Access, ele não é tão lento. Eu o utilizei para traduzir citações em TS (conexão: terminal - base - TS). Histórico, cotações atuais, estados, registros, etc. no banco de dados. E isso é para a Intrade. Não houve reclamações sobre a velocidade do banco de dados.
Receio que o SQLite não funcione para uma declaração de problema semelhante, pelos motivos expostos por Eugeniy Lugovoy.
Sim, eu conheço a Oracle. Tenho até alguns de seus certificados espalhados por aí. Infelizmente, eles não foram úteis.
Quanto ao Access, ele não é tão lento. Eu o utilizei para traduzir cotações para TS (conexão: terminal - base - TS). Histórico, cotações atuais, estados, registros, etc. no banco de dados. E isso é para a Intrade. Não houve reclamações sobre a velocidade do banco de dados.
Receio que o SQLite não funcione para uma declaração de problema semelhante, pelos motivos declarados por Eugeniy Lugovoy.
Se não for um segredo, qual mecanismo foi usado no TC para ler os dados do Assets?
TC - padrão C# ADO.NET. Buffers em C, suas atualizações e gravação no banco de dados. O Terminal grava dados no banco de dados via (não me lembro) - ODBC, mas é mais provável que seja via Jet. Se tiver interesse, darei uma olhada mais tarde. O Terminal tem exportação embutida para o banco de dados (qualquer um, se o driver estiver no computador).
PS Parece ser OLEDB
.
Saudações a todos! Pessoal, faz muito tempo que não dou uma olhada aqui. Está muito quente aqui nas discussões :) Vou me explicar :)
Há alguns anos, participei de projetos em que os requisitos eram bem diferentes (análise de mercado adicional por software de terceiros, publicação na Web com preservação do histórico, aplicação de algoritmos genéticos, emulação de negociação etc.), mas era conveniente ter os dados no banco de dados. Como os requisitos eram diferentes, a escolha do DBMS era correspondente. E, no final, decidi escrever drivers MT4 RDBMS para cada DBMS a fim de usar drivers nativos, mas não ODBC/OLEDB. Ou seja, para o mysql - libmysql, para o oracle - OCI/Instant client, para o SQLite - sua DLL com API, mas para os bancos de dados da Microsoft (Access/MS SQL) há apenas a opção OLEDB. Tudo isso já foi escrito e existe até agora. Aqui eu apenas formei o artigo para bases MySQL, porque para o espaço pós-soviético ele ainda está mais próximo, em minha opinião subjetiva.
Em geral, trabalhei com bancos de dados por tempo suficiente e densamente, e o surgimento, o desenvolvimento e a popularidade do SQLite não poderiam deixar de me afetar :) Escrevi um rapper na v3 e, em um thread separado, tudo está bem (ou seja, quando um gráfico pesa o EA), no entanto, ao testar em vários gráficos, inesperadamente obtive um bloqueio de tabela. Escrevi EAs de teste especialmente para atualizar os dados (linhas) apenas por seu próprio símbolo, ou seja, a tabela é a mesma, mas as linhas são diferentes para não causar travamento. o resultado - travamento da tabela. E isso ocorre apesar do fato de que o próprio vrapper usa mutexes para executar operações, ou seja, até que uma atualização não seja concluída (+autocommit), a outra não será iniciada. Pesquisei nos fóruns e descobri que esse problema existe de fato. Reescrevi o ripper no OLEDB (a estrutura de todos os rippers é quase idêntica, exceto pelos comandos para chamar a API do DBMS necessário) e verifiquei no MS Access.... mesmos scripts - sem problemas. MS SQL - sem problemas, PostgreSQL - sem problemas, conectado ao Oracle - também tudo ok.
E, embora tenha sido há muito tempo, a sensação do SQLite permaneceu ... Não fiz mais nenhum experimento. O único banco de dados semelhante (arquivo e compacto com SQL) de que me lembro era o MSSQL Compact Edition, mas minhas mãos não alcançaram a implementação nessa direção.
No final, restaram dois projetos - um para MySQL (incluindo MariaDB) e outro para OLEDB, que, embora limitem as possibilidades em comparação com drivers nativos (por exemplo, o mesmo DBMS Oracle), são suficientes para implementar projetos de produção. Nesse aspecto, valorizo a estabilidade + desempenho da solução, bem como a minimização dos custos de manutenção. Bem, se for necessário mudar para outro DBMS no futuro, os custos serão mínimos - se você simplificar, só precisará reescrever as consultas levando em conta a sintaxe do novo subdatabase e, em geral, a lógica do projeto não será afetada.
Obrigado a todos e boa sorte!
Eu me dei ao trabalho de "verificar fora da caixa" - isso não funciona.
Saudações, Pavel,
Forneça as seguintes informações sobre seu ambiente:
- Versão e bitness do sistema operacional
- Versão, compilação e bitness do terminal
- Versão do MySQL
É bastante estranho que o kernel não contenha uma função para criar um mutex e que a libmysql não contenha uma função para determinar o número de linhas afetadas pela operação...
Tentarei criar um ambiente semelhante e verificarei.
win 7 x64 - mt5 x64 versão mais recente (v5 b1455)
Não consigo acessar o MySQL, mas isso não é uma pena.
Servidor: Localhost via soquete UNIX
Tipo de servidor: Servidor Percona
Versão do servidor: 5.5.35-33.0-log - Percona Server (GPL), Release rel33.0, Revisão 611
Versão do protocolo: 10
Usuário: ***
Codificação do servidor: UTF-8 Unicode (utf8)