Discusión sobre el artículo "Trabajo con el SGBD MySQL desde MQL5 (MQL4)" - página 12
Está perdiendo oportunidades comerciales:
- Aplicaciones de trading gratuitas
- 8 000+ señales para copiar
- Noticias económicas para analizar los mercados financieros
Registro
Entrada
Usted acepta la política del sitio web y las condiciones de uso
Si no tiene cuenta de usuario, regístrese
Hay un montón de GUIs/IDEs de terceros para ello - y sqlite en sí es sólo un motor de base de datos puro y API para incrustarlo en aplicaciones...
API es realmente para todo, incluyendo NET. Buscaré GUI - puede que te guste).
https://www.mql5.com/es/articles/862
Gracias, lo leí. Hay un punto muy bueno allí por el autor del artículo actual, que llegó,..... y lo estropeó todo).
La posibilidad de usarlo está ahí y eso es bueno. Otra cosa es que SQLite no debería usarse para proyectos serios. En cualquier caso, yo no lo recomendaría. Yo mismo me he enfrentado más de una vez al problema de las colisiones en él. Por ejemplo, si un robot de trading está conectado a diferentes gráficos, pero utiliza la misma base, y el acceso es a una tabla de propósito general (digamos registro/cambio de sesiones, cuentas), entonces en cualquier caso obtendrás un error como "tabla bloqueada". Y no importa que todas las transacciones se hayan completado, los cursores estén cerrados y la base de datos se haya abierto en modo compartido. Este problema también lo conocen los desarrolladores de SQLite.
En mi opinión, MS Access es la mejor de las bases de datos de archivos con soporte SQL. No importa cuánto regañes a la gente de small-soft, pero yo dejé SQLite por MS Access y no me arrepiento en absoluto. OleDB driver Jet 4.0 se instala incluso con Win98, para que los proyectos funcionen en todos los OC Windows.
Ya he escrito anteriormente que Access es probablemente realmente el mejor, que es lo que yo uso. En caso extremo MS SQL Server, especialmente ahora que hay una versión de libre distribución. Y MySQL es demasiado voluminoso, sólo la distribución del servidor ~450 MB
Gracias, lo he leído. Hay un punto muy bueno allí por el autor del artículo actual, que entró,..... y arruinó todo).
La posibilidad de usarlo está ahí y eso es bueno. Otra cosa es que SQLite no debería usarse para proyectos serios. En cualquier caso, yo no lo recomendaría. Yo mismo me he enfrentado más de una vez al problema de las colisiones en él. Por ejemplo, si un robot de trading está conectado a diferentes gráficos, pero utiliza la misma base, y el acceso es a una tabla de propósito general (digamos registro/cambio de sesiones, cuentas), entonces en cualquier caso obtendrás un error como "tabla bloqueada". Y no importa que todas las transacciones se hayan completado, los cursores estén cerrados y la base de datos se haya abierto en modo compartido. Este problema también lo conocen los desarrolladores de SQLite.
En mi opinión, MS Access es la mejor de las bases de datos de archivos con soporte SQL. No importa cuánto regañes a la gente de small-soft, pero yo dejé SQLite por MS Access y no me arrepiento en absoluto. OleDB driver Jet 4.0 se instala incluso con Win98, para que los proyectos funcionen en todos los OC Windows.
Ya he escrito anteriormente que Access es probablemente realmente el mejor. En caso extremo MS SQL Server, especialmente ahora que hay una versión de libre distribución.
MS Access es una de las peores opciones. En VDS apenas se mueve. Lo que no se puede decir de la misma SQLite - es muy rápido. Hay un problema (pero es lo mismo con MySQL y en general con cualquier otro) - ahora el modelo es "un Asesor Experto=una operación y además en algún lugar hay indicadores, gráfico y terminal", pero puede cambiar fácilmente, además todo en código-base no está diseñado para el trabajo competitivo, implica el uso monopólico del recurso, no hay bloqueo necesario, sincronización y así sucesivamente. Y por cierto es de la sección de perversiones - ejecutar más de un Asesor Experto (aunque sean instancias del mismo) en una cuenta real.
Y si quieres fiabilidad con felpas - poner Oracle (usted se sorprenderá, pero para las necesidades de los robots es gratis) y APEX, escribir un conector a la misma..Y otra opción - para conducir los datos a través de Web-Request al modelo REST.
PS/ por qué discutir - hasta que MQ no lanzará un conector generalizado a SQL todos los intentos de trabajar correctamente con DBMS están condenados al fracaso. Este es el mismo caso cuando un componente no es realizable por las fuerzas de la comunidad
Y si quieres fiabilidad con pluses - poner Oracle (usted se sorprenderá, pero para las necesidades de los robots es gratis) y APEX, escribir un conector a la misma..Y otra opción es conducir los datos a través de Web-Request al modelo REST.
Sí, sé de Oracle. Incluso tengo un par de sus certificados por ahí. Por desgracia, no son útiles.
En cuanto a Access, no es tan lento. Lo usé para traducir las cotizaciones a TS (conexión: terminal - base - TS). Historial, cotizaciones actuales, estados, logs, etc. en la base de datos. Y esto para intrade. No hubo quejas sobre la velocidad de la base de datos.
Me temo que SQLite no funcionará para un planteamiento de problemas similar, por las razones expuestas por Eugeniy Lugovoy.
Sí, conozco Oracle. Incluso tengo un par de sus certificados por ahí. Por desgracia, no me han sido útiles.
En cuanto a Access, no es tan lento. Yo lo usaba para traducir cotizaciones a TS (conexión: terminal - base - TS). Historial, cotizaciones actuales, estados, registros, etc. en la base de datos. Y esto para intrade. No hubo quejas sobre la velocidad de la base de datos.
Me temo que SQLite no funcionará para una declaración similar problema, por las razones expuestas por Eugeniy Lugovoy.
si no es un secreto, ¿qué mecanismo se utilizó en TC para leer datos de Activos?
TC - C# ADO.NET estándar. C buffers, sus actualizaciones y escritura a la base de datos. Terminal escribe datos a la base de datos a través de (no puedo recordar) - ya sea ODBC, pero más probablemente a través de Jet. Voy a mirar más tarde si usted está interesado. Terminal ha incorporado la exportación a la base de datos (cualquiera, si el conductor está en el equipo).
PS Parece OLEDB
.
¡Saludos a todos! Chicos hacía tiempo que no miraba por aquí. Hace mucho calor aquí en las discusiones :) Permítanme explicarme :)
Hace un par de años estuve involucrado en proyectos donde los requisitos eran bastante diferentes (análisis adicional del mercado por software de terceros, publicación en la web con la preservación de la historia, la aplicación de algoritmos genéticos, la emulación de la negociación, etc), pero era conveniente tener los datos en la base de datos. Como los requisitos eran diferentes, la elección del SGBD correspondía. Y al final decidí escribir controladores MT4 RDBMS para cada DBMS con el fin de utilizar controladores nativos, pero no ODBC/OLEDB. Es decir, para mysql - libmysql, para oracle - OCI/Instant client, para SQLite - su DLL con api, pero para las bases de datos de Microsoft (Access/MS SQL) sólo hay opción OLEDB. Todo esto ha sido escrito y existe hasta ahora, aquí acabo de formar el artículo para bases MySQL, porque para el espacio postsoviético es todavía más cerca en mi opinión subjetiva.
En general, con las bases de datos trabajé bastante tiempo y densamente, y, la aparición, el desarrollo y la popularidad de SQLite no podía dejar de afectarme :) Escribí un rapero bajo v3 y en un hilo separado todo está bien (es decir, cuando un gráfico pesa EA), sin embargo, al probar en varios gráficos inesperadamente obtuve un bloqueo de tabla. Especialmente escribí EAs de prueba para actualizar los datos (filas) sólo por su propio símbolo, es decir, la tabla es la misma, pero las filas son diferentes para no causar loc. el resultado - tabla loc. Y esto a pesar del hecho de que el propio vrapper utiliza mutexes para realizar operaciones, es decir, hasta que una actualización no se ha completado (+autocommit), el otro no se iniciará. en pocas palabras - loc a ocurrir en ninguna parte, excepto dentro de la SQLite. He buscado en los foros y he encontrado que efectivamente existe este problema. He reescrito el ripper bajo OLEDB (la estructura de todos los rippers es casi idéntica, excepto por los comandos para llamar a la API del DBMS requerido) y comprobado en MS Access.... los mismos scripts - sin problemas. MS SQL - sin problemas, PostgreSQL - sin problemas, conectado a Oracle - también todo ok.
Y aunque fue hace mucho tiempo, pero la sensación de SQLite se mantuvo ... No experimenté más. La única base de datos similar (archivo y compacto con SQL) que recuerdo fue MSSQL Compact Edition, pero mis manos no llegaron a la implementación en esta dirección.
Al final me quedan dos proyectos - uno para MySQL (incluyendo MariaDB) y otro para OLEDB, que aunque limitan las posibilidades en comparación con los drivers nativos (por ejemplo, el mismo DBMS Oracle), pero son suficientes para implementar proyectos de producción. En este sentido valoro estabilidad + rendimiento de la solución, bueno, y además minimización de costes de mantenimiento. Bueno, si en el futuro será necesario cambiar a otro SGBD, los costes serán mínimos - si simplificas, sólo tendrás que reescribir las consultas teniendo en cuenta la sintaxis de la nueva sub-base de datos, y en general, la lógica del proyecto no se verá afectada.
Gracias a todos y ¡buena suerte!
Me tomé la molestia de "comprobar fuera de la caja" - no funciona.
Saludos Pavel,
Por favor, facilítanos la siguiente información sobre tu entorno
- Versión y bit del sistema operativo
- Versión, build y bit del terminal
- Versión de MySQL
Es bastante extraño que kernel no contenga una función para crear un mutex, y libmysql no contenga una función para determinar el número de filas afectadas por la operación...
Intentaré crear un entorno similar y comprobarlo.
win 7 x64 - mt5 x64 última versión (v5 b1455)
No puedo llegar a MySQL, pero no es una lástima.
Servidor: Localhost via UNIX socket
Tipo de servidor: Percona Server
Versión del servidor: 5.5.35-33.0-log - Percona Server (GPL), Release rel33.0, Revision 611
Versión del protocolo: 10
Usuario: ***
Codificación del servidor: UTF-8 Unicode (utf8)