Discusión sobre el artículo "Trabajo con el SGBD MySQL desde MQL5 (MQL4)" - página 29
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
gracias por la aclaración. No puedo saberlo todo, por eso pregunto.
He encontrado la solución para mí aquí.
P.D: Comprobado para SELECT - funciona
Bueno, la conversión del resultado de la consulta está permitida, pero no olvides que tienes la definición utf8mb4 a nivel de tabla, es decir, para todos los campos se usará varchar por defecto, y si tienes una condición en un campo de texto en tu consulta, MySQL intentará convertirlo implícitamente. Y si tiene en cuenta que puede tener un índice construido sobre una columna de texto, entonces el optimizador puede no recogerlo durante dicha conversión... de ahí los problemas con el rendimiento de la consulta.
existe un campo de descripción. Algo así como "comentarios", el campo no es necesario, sólo una explicación de texto. No habrá índice.
MySQL utf8mb4 lo hace por defecto. ¿Puedes decirme cómo especificar en DDL próxima vez? ¿Qué cambiar y a qué codificación ?
¿Alguna idea?
Sigo recibiendo este error:
¿Has conseguido resolverlo Boaz?
¿Hay alguna manera de saber el número de campos que se pueden recuperar después de MySqlCursorFetchRow?
Quizás alguna función oculta como RowFieldsSize ...
Según tengo entendido, si no hay ningún Campo, MySqlGetFieldAsString devuelve vacío. Pero también si String Field contiene específicamente un campo vacío, también devuelve vacío. Es decir, no siempre es posible averiguar el número de Fields por fuerza bruta.
Como muletilla se puede averiguar a través del comando sql primero, pero luego seleccionar de nuevo, pero esto ya es un Select innecesario.
Por favor, desarrollar la biblioteca, cosa muy útil. Por supuesto hace mucho tiempo un par de mysql para construir en mt
Insertar y actualizar consulta - sólo 16 kb límite de consulta?
Si la consulta tiene más de 16.000 caracteres, metatrader se bloquea (se cierra). si tiene menos, va bien.
Adjunto un ejemplo de UPDATE para 32.000 caracteres.
Campo para actualizar en la base de datos - LONGTEXT
Consulta de inserción y actualización - ¿límite de consulta de sólo 16kb?
Si la consulta es más de 16.000 caracteres, metatrader se bloquea (cierra). si menos, está bien.
Adjunto un ejemplo de UPDATE para 32.000 caracteres.
Campo para actualizar en la base de datos - LONGTEXT
Esto es más como un límite de tamaño de línea en MQL :-(
y se puede escribir de forma más compacta :
REPLACE d1 ("t", "o", "h", "l", "c") VALUES (time1,open1,high1,low1,close1), (time2,open2,high2,low2,close2) ....
y/o dividir en dos consultas combinándolas en una sola operación
Por ejemplo, tengo datos 50 000 elementos y los actualizo en la tabla cada 0,1 seg (números). ¿ MT5 podrá recogerlos de MySQL y actualizarlos cada 0,1 seg ? ¿Hay alguna limitación de la funcionalidad dada en este artículo en KB por 1 consulta?
Hola! Pregunta para expertos - ¿cuántos datos y con qué frecuencia puedo leer de MySQL a MT5?
Por ejemplo, tengo datos 50 000 elementos y los actualizo en la tabla cada 0,1 seg (números). ¿ MT5 podrá recogerlos de MySQL y actualizarlos cada 0,1 seg ? ¿Hay alguna limitación de la funcionalidad dada en este artículo sobre KB para 1 consulta?
Bueno, la pregunta es ciertamente interesante ...
Debo decir que no hay límites en el número de filas de consulta SELECT devueltos.
El límite de tamaño para la consulta en sí es de 64 Kb. Por lo tanto, si se trata de actualizar 50k filas de datos, es mejor dividirlos en lotes, digamos 1000 filas cada uno, y enviar así 50 consultas.
En cuanto a la velocidad de 100 ms, si usted tiene la base de datos en un servidor, y su terminal en el que se ejecuta MQL con una conexión a la base de datos es algo remoto, entonces lo más probable es que se encontrará con la latencia de la red, el tamaño de la ping....
Por ejemplo, si tienes un ping de 60 ms entre el servidor de la base de datos y la terminal, la respuesta real del servidor se retrasará = 60ms (consulta) + tiempo de procesamiento de la consulta en el lado de la base de datos + 60ms (respuesta).
Este proyecto es sólo una simple envoltura para acceder a la funcionalidad de las bibliotecas mysql dinámicas.
El conjunto de la funcionalidad se limita a las principales funciones prácticamente útiles, puede ampliar, añadir lo que necesita, digamos añadir soporte para consultas asíncronas, y entonces usted puede enviar todas las 50 consultas en 1000 líneas sin esperar a la ejecución de cada uno a su vez.
P.D.: en Github puedes ver las fuentes de la librería y los límites preestablecidos(https://github.com/elugovoy/MQLMySQL-Project/tree/master/MQLMySQL).
P.P.D.: también puedes descargarlo, modificarlo a tu gusto, compilarlo y probarlo.
¿Hay alguna manera de saber el número de campos que se pueden recuperar después de MySqlCursorFetchRow?
Tal vez hay alguna función oculta como RowFieldsSize ...
Según tengo entendido, si no hay ningún Campo, MySqlGetFieldAsString devuelve vacío. Pero también si String Field contiene específicamente un campo vacío, también devuelve vacío. Es decir, no siempre es posible rastrear el número de Fields por fuerza bruta.
Como muletilla se puede averiguar a través del comando sql primero, pero luego seleccionar de nuevo, pero esto ya es un Select innecesario.
Por favor, desarrollar la biblioteca, cosa muy útil. Por supuesto, un par de mysql debe ser construido en mt hace mucho tiempo
Hm... ¿y qué tipo de consultas te resultan tan complicadas que es necesario determinar el número de campos que devuelve?
Normalmente en el comando SELECT solo se lista lo que se necesita en una situación concreta. No uses SELECT *, selecciona sólo lo que necesites :) esto es una práctica normal.
No debes hacer muletillas, puedes tomar el código fuente de Github y añadir un wrapper para mysql_fetch_fields() función de la API MySQL