Subiendo la bbdd a MySql o como lo haría Carlos Mora

[hmpaquito]

Carlos,

Por no romper el hilo de los Reyes...

Te comenté que lo hacía con Update, con Dolphin para Fwh. Pero qué lento era eso.

Tu me recomendaste que usara la consola de MySql.

Una pregunta... ¿ Será igual de rápido si uso MySql.exe ? Porque si bien con la consola, al estar en local debería ser más rapido, también hay que tener en cuenta el tiempo que se tarda en subir el archivo .sql al server.

¿ Qué te parece ?

PD. Te hice un comentario reeditando mi ultimo post en el hilo de los Reyes.

Saludos

[Carlos Mora]

Te comenté que lo hacía con Update, con Dolphin para Fwh. Pero qué lento era eso.
Tu me recomendaste que usara la consola de MySql.
Una pregunta... ¿ Será igual de rápido si uso MySql.exe ? Porque si bien con la consola, al estar en local debería ser más rapido, también hay que tener en cuenta el tiempo que se tarda en subir el archivo .sql al server.
Saludos

Con la consola me refería precisamente a mysql.exe, le digo consola porque bueno... en linux el ejecutable no tiene extensión, y uso mysql exclusivamente en Linux.

Mi sugerencia es la misma: mysql.exe -u xx-p bbdd < tuarchivo.sql y metido como una tarea programada en un bat (usando lenguaje de windows)

La transferencia del .sql puede ser pesada, pero seguramente puedes comprimirla antes de transferirla con un ratio bastante alto, y descomprimirla en destino.
¿Con que frecuencia planeas actualizar?
¿Hay forma de hacer actualizaciones selectivas, cambiando solo lo nuevo?

[hmpaquito]

Te comenté que lo hacía con Update, con Dolphin para Fwh. Pero qué lento era eso.
Tu me recomendaste que usara la consola de MySql.
Una pregunta... ¿ Será igual de rápido si uso MySql.exe ? Porque si bien con la consola, al estar en local debería ser más rapido, también hay que tener en cuenta el tiempo que se tarda en subir el archivo .sql al server.
Saludos

Con la consola me refería precisamente a mysql.exe, le digo consola porque bueno... en linux el ejecutable no tiene extensión, y uso mysql exclusivamente en Linux.

Mi sugerencia es la misma: mysql.exe -u xx-p bbdd < tuarchivo.sql y metido como una tarea programada en un bat (usando lenguaje de windows)

La transferencia del .sql puede ser pesada, pero seguramente puedes comprimirla antes de transferirla con un ratio bastante alto, y descomprimirla en destino.
¿Con que frecuencia planeas actualizar?
¿Hay forma de hacer actualizaciones selectivas, cambiando solo lo nuevo?

Carlos,

Perdona mi extremada ignorancia. Te pido, por favor, un poco de paciencia.

A ver. Yo distingo entre la consola a) MySql.exe que tengo en mi ordenata Windows y el b) MySql consola que está en el server del VPS que mi tecnico me montó bajo ¿ Ubuntu ?, donde reside la bbdd y que es como trabajar en local para la bbdd, por lo que no hay flujo de datos ¿ Es asi ?

Asi, por lo que me comentas, b) seria la opcion mas rapida, si comprimimos previamente el .sql ¿ Es eso ?

Gracias.

[Carlos Mora]

Mi sugerencia es la misma: mysql.exe -u xx-p bbdd < tuarchivo.sql y metido como una tarea programada en un bat (usando lenguaje de windows)

La transferencia del .sql puede ser pesada, pero seguramente puedes comprimirla antes de transferirla con un ratio bastante alto, y descomprimirla en destino.
¿Con que frecuencia planeas actualizar?
¿Hay forma de hacer actualizaciones selectivas, cambiando solo lo nuevo?

Carlos,

Perdona mi extremada ignorancia. Te pido, por favor, un poco de paciencia.

A ver. Yo distingo entre la consola a) MySql.exe que tengo en mi ordenata Windows y el b) MySql consola que está en el server del VPS que mi tecnico me montó bajo ¿ Ubuntu ?, donde reside la bbdd y que es como trabajar en local para la bbdd, por lo que no hay flujo de datos ¿ Es asi ?

Asi, por lo que me comentas, b) seria la opcion mas rapida, si comprimimos previamente el .sql ¿ Es eso ?

Gracias.

con mysql.exe o mysql me refiero al programa que tienes cuando instalas mysql en algun sitio. mysqlD.exe o mysqld es el servicio de la base de datos (con D al ultimo) y mysql.exe o mysql (a secas en unix/linux) es la consola para ejecutar comandos. mysql.exe lo usaria para atacar a un servidor mysql que esté instalado en el propio windows, si el servidor (tal como me cuentas) es un ubuntu pues entonces hablamos de mysql en una consola. Te conectas al Ubuntu con ssh, si es desde windows usas el Putty.exe , y accedes a la linea de comandos (shell). Ahí ya puedes usar el comando mysql que te sugiero, y que yo creo que va a ir mas rápido.
Entonces si hablo de consola me refiero a Linux. Cualquier cosa hecha desde Windows será lenta por cuestiones de conexión. Tu solución está en el servidor, no le des mas vueltas.

Pero no me has contestado las preguntas para hacerme mejor idea de cual el el plan y la necesidad.
¿Con que frecuencia planeas actualizar?
¿Hay forma de hacer actualizaciones selectivas, cambiando solo lo nuevo?

Segun entiendo, lo mejor y mas rápido sería:

- Hacer un programa que lea todos los datos, determine la informacion a trasladar al MySql, y escriba todos los comandos SQL en un solo archivo.
- Al finalizar zippeo el archivo y lo copio al Ubuntu via SFTP, WebDav, o el método que dispongas.
- En el Ubuntu habrá un script metido en el cron del sistema que se ejecutará cada cierto tiempo (determina tu la frecuencia requerida) que se fijará si has pasado un fichero nuevo, si lo encuentra lo descomprimirá y ejecutará un 'mysql -u usuario -p bbdd < <ficherodescomprimido.sql' . Al finalizar borra los fichero que ya no se requieren.
- Te tomas una Volt Dam

De todas maneras, cuenta un poco más de lo que quieres hacer, que tienes hecho y un ejemplo de lo que te falla.

[hmpaquito]

Hola Carlos,

Pero no me has contestado las preguntas para hacerme mejor idea de cual el el plan y la necesidad.

¿ Ha sido un fallo, no me he dado cuenta ?

La frecuencia: la tengo que determinar. Pero creo que lo lógico, teniendo en cuenta que la bbdd almacenará precios y otros, al menos, tendría que ser una actualización diaria.

Ya tengo la generación del .sql. Ahora mismo los subia con oServerDolphin:Execute(cSqlQuery), una por query, pero iba exageradamente lento.

La actualizacion selectiva la acabo de hacer: sólo subirán los datos de determinados clientes. Con un poco de suerte el .sql se disminuye bastante. Ya veremos.


Segun entiendo, lo mejor y mas rápido sería:

- Hacer un programa que lea todos los datos, determine la informacion a trasladar al MySql, y escriba todos los comandos SQL en un solo archivo.
- Al finalizar zippeo el archivo y lo copio al Ubuntu via SFTP, WebDav, o el método que dispongas.
- En el Ubuntu habrá un script metido en el cron del sistema que se ejecutará cada cierto tiempo (determina tu la frecuencia requerida) que se fijará si has pasado un fichero nuevo, si lo encuentra lo descomprimirá y ejecutará un 'mysql -u usuario -p bbdd < <ficherodescomprimido.sql' . Al finalizar borra los fichero que ya no se requieren.
- Te tomas una Volt Dam

Sip. Es la solución que me planteaste ya al principio.

Nuevamente, muchas gracias por tu ayuda.

[Carlos Mora]

Estaba pensando y el proceso se puede mejorar en el caso del Ubuntu.
¿Que tal se maneja el técnico con Linux? Porque, para que quede wapo wapo, se puede hacer que el server espere que algo en un directorio cambie, y cuando eso suceda se lance un proceso. Esto cambiaría la opcion del cron, así no hay que esperar a que el cron actualice sino que tu decides cuando subiendo el fichero.

En cualquier caso cuenta luego como te va, porque es algo que toca hacer a menudo y a mi me resulta interesante ver que soluciones saca la gente.

Respecto de hacer mas selectiva la actualización... Supongamos que vas a actualizar la tabla de clientes...
Usando TDolphin ¿Cuanto te demora hacer un SELECT * FROM Clientes? Porque, si no es mucho, el mismo proceso puede ir verificando si cada cliente está actualizado, y generar solo los cambios, con lo que disminuirías a la mínima expresión los cambios a realizar, solo los registros que hayan cambiado, y eventualmente solo los campos.
Es otra idea, pero como ves siempre faltan detalles para saber si puede o no funcionar.

[Carles]

Hi,

Y viendo tu escenario, porque no te creas un trigger q salte cuando actualizas tu pedido o tus clientes. Asi ya puedes tener una tablita solo las modificaciones q has hecho preparadas para exportar...

Solo una idea mas tomando una Voll...

Nice weekend.

[hmpaquito]

Estaba pensando y el proceso se puede mejorar en el caso del Ubuntu.
¿Que tal se maneja el técnico con Linux? Porque, para que quede wapo wapo, se puede hacer que el server espere que algo en un directorio cambie, y cuando eso suceda se lance un proceso. Esto cambiaría la opcion del cron, así no hay que esperar a que el cron actualice sino que tu decides cuando subiendo el fichero.

Hablaré con él de este tema.

En cualquier caso cuenta luego como te va, porque es algo que toca hacer a menudo y a mi me resulta interesante ver que soluciones saca la gente.

A todos nos resulta interesante lo que todos hacemos Sólo hay que ver tu amabilidad al compartir conmigo y con todos tus conocimientos, lo cual es un acicate para que todos compartamos un poco mas

Respecto de hacer mas selectiva la actualización... Supongamos que vas a actualizar la tabla de clientes...
Usando TDolphin ¿Cuanto te demora hacer un SELECT * FROM Clientes? Porque, si no es mucho, el mismo proceso puede ir verificando si cada cliente está actualizado, y generar solo los cambios, con lo que disminuirías a la mínima expresión los cambios a realizar, solo los registros que hayan cambiado, y eventualmente solo los campos.
Es otra idea, pero como ves siempre faltan detalles para saber si puede o no funcionar.

Hago UPDATEs de todos los registros. Pretendo que la actualizacion sea en caliente y por tanto ha de ser con UPDATE: no puedo vaciar la tabla inicialmente.

Con lo del SELECT, me has dado una idea: una actualizacion incremental: dejamos el .sql anterior. Y para cada nuevo query (UPDATE) lo buscamos si ya existe en el .sql anterior. Si ya existe no se añade al .sql nuevo: si existe, entonces no se añade. Esto supongo que con At() será lentorro, y no sólo eso: colapsará la memoria. Así que podría meterlo todo en una .dbf y hacer un SEEK de por ejemplo: tipo query + codigo de cliente o de articulo o de lo que sea, y luego comprobar si los datos existentes son los mismos que hay.... pero... ¿ valdría lo mismo la salsa que el pollo ? Es decir, tardaría lo mismo una cosa que la otra.

Gracias de nuevo

[hmpaquito]

Hi,

Y viendo tu escenario, porque no te creas un trigger q salte cuando actualizas tu pedido o tus clientes. Asi ya puedes tener una tablita solo las modificaciones q has hecho preparadas para exportar...

Solo una idea mas tomando una Voll...

Nice weekend.

De Carlos a Carles; Hola Carles,

Mira, no lo tenía en mente, porque en el desktop tengo dbfs y no hay tigres.

Quizá una opción sería marcar los registros con FechaUActualizacion y HoraUActualizacion y asi solo subir al .sql los modificados. El problema es que alguna tabla se crea al vuelo, en el momento de "enviar" a web.
En algunas tablas ya tengo la marca de ultima fecha y ultima hora... pero la verdad... no confio mucho en ellas... Nunca las he usado oficiosamente...

Este sistema me gusta menos. Esperaba que el MySql me hiciera algo automaticamente. La verdad es que estoy un poco hartito de estar siempre currando las sincronizaciones, que a la larga, son las mas efectivas. De hecho, y como ya comenté en el otro hilo, la de la subida de imágenes, la tengo hecha a mano; sin hubic, sin dropbox o gdrive.

Gracias por el aporte

[Carlos Mora]

Carles,

Y viendo tu escenario, porque no te creas un trigger q salte cuando actualizas tu pedido o tus clientes. Asi ya puedes tener una tablita solo las modificaciones q has hecho preparadas para exportar...

Solo una idea mas tomando una Voll...

¿Es cierto que tienes un trigger que te avisa cuando se menciona una Voll en el foro?
La idea de los triggers es buena, sobre todo si la tienes en cuenta desde el principio del diseño. También la de la fecha de ultima actualización, como lo hace el propio MySQL con los campos timestamp. Logré hace una implementación parecida, porque para gestionar registros uso una clase propia que se llama RecBuffer, que hace pues eso, un buffer de edición, y hace los replaces. Nacio para ahorrarse el trabajo de declarar variables intermedias para editar y/o crear registros, y después le añadí unas cuantas florituras entre las que está el timestamping, con lo que eso se hace de manera automática.
Hace poco el Rafa escribió algo sobre triggers nativos, no? puede ser algo interesante.

Un abrazo