¡Migrar a SQL ya!

[ignacio]

Nuevo artí­culo en nuestro blog:
http://xailer.info/wordpress/es/?p=1158
Un saludo

[vgest]

Excelente comentario!!
Pero aunque estemos convencidos de la necesidad de migrar, la pregunta es: Que tipo de cambios es preciso hacer?
Pensemos en la tí­pica aplicación dbf, con tablas de muchos campos y poquí­simo normalizada.
Si se cambian directamente DbfDataSet por SqlDataSet ¿El rendimiento no serí­a desastroso?
La tí­pica navegacion DBF, los bucles while !eof()... skip().. originarian cientos de consultas a la base de datos.
¿Existe algún tipo de buffer en los Sqldataset para evitar esto?
A nivel de concepto, seria muy interesante conocer, en base a vuestra experiencia, que tipo de cosas habrí­a que rehacer para migrar una aplicación tí­pica dbf a sql.
Ayudarí­a mucho para que cada uno se plantee los pasos que tendrí­a que seguir para dar este salto, por otra parte inevitable.

[Claudio[1]]

Hola Victor.
En mi modesta opinión la única forma que veo es programando OO por capas
MVC y utilizando Store procedures en la Base de datos.
Lo mismo comente en el blog:Le agregarí­a una sugerencia ( en mi caso lo
impuse como condición ) Migrar a SQL con Stored procedures,
procedimientos almacenados del lado servidor. Quizá cueste un poco más
pero enseguida se recupera el tiempo invertido.
Es realmente otro mundo.
Quizá, quienes estamos en una disyuntiva similar podamos compartir
experiencias y ( por que no ) código y ejemplos. Propongo armar una
lista / grupo o lo que sea para estos temas.
Te cuento lo que estoy haciendo
- Motor de BD maria DB 10.0 ( esta version al igual que Mysql 5.6 tiene
una gestion de errores excelene: disgnostics area )
- Gestor de BD Heidi SQL 8.3
- MySql workbench para diagramas Entidad Relacion ( también puede usarse
como gestor de BD )
Xailer vuela cuando 'ataca' a la BD.
Este esquema (el modelo con SP) te sirve también para subir la BD a la
nube e interactuar contra ella desde... cualquier otro entorno. No es un
dato menor.
Saludos,
Claudio
El 24/10/2014 a las 02:09 p.m., victor escribió:
>
> Excelente comentario!!
>
> Pero aunque estemos convencidos de la necesidad de migrar,
> la pregunta es: Que tipo de cambios es preciso hacer?
>
> Pensemos en la tí­pica aplicación dbf, con tablas de muchos
> campos y poquí­simo normalizada.
>
> Si se cambian directamente DbfDataSet por SqlDataSet ¿El
> rendimiento no serí­a desastroso?
>
> La tí­pica navegacion DBF, los bucles while !eof()...
> skip().. originarian cientos de consultas a la base de
> datos.
> ¿Existe algún tipo de buffer en los Sqldataset para evitar
> esto?
>
> A nivel de concepto, seria muy interesante conocer, en base
> a vuestra experiencia, que tipo de cosas habrí­a que rehacer
> para migrar una aplicación tí­pica dbf a sql.
> Ayudarí­a mucho para que cada uno se plantee los pasos que
> tendrí­a que seguir para dar este salto, por otra parte
> inevitable.
>
>
---
Este mensaje no contiene virus ni malware porque la protección de avast! Antivirus está activa.
http://www.avast.com

[PEDRO DE LEON RODAS[3]]

Victor, buen dia.
Realmente te vas a sorprender cuando empieces a usar sql.
Es rápido, y en cuestión de los bucles, los usas igual que un dbf.
Si quieres arma un ejemplo con dbfs y te ayudo a convertirlo para el uso con
sqlite.
Cuando yo empece a usar sql, tuve muchas dudas, pero esas dudas fueron
aclaradas por medio de los compañeros de este foro.
El detalle es que tienes que usar la version enterprise.
O si no quieres aun invertir en la compra, pues usa el demo.
Saludos.
"victor" escribió en el mensaje de noticias:544a87c1$[email=1@svctag-j7w3v3j....]1@svctag-j7w3v3j....[/email]
Excelente comentario!!
Pero aunque estemos convencidos de la necesidad de migrar,
la pregunta es: Que tipo de cambios es preciso hacer?
Pensemos en la tí­pica aplicación dbf, con tablas de muchos
campos y poquí­simo normalizada.
Si se cambian directamente DbfDataSet por SqlDataSet ¿El
rendimiento no serí­a desastroso?
La tí­pica navegacion DBF, los bucles while !eof()...
skip().. originarian cientos de consultas a la base de
datos.
¿Existe algún tipo de buffer en los Sqldataset para evitar
esto?
A nivel de concepto, seria muy interesante conocer, en base
a vuestra experiencia, que tipo de cosas habrí­a que rehacer
para migrar una aplicación tí­pica dbf a sql.
Ayudarí­a mucho para que cada uno se plantee los pasos que
tendrí­a que seguir para dar este salto, por otra parte
inevitable.

[Claudio[1]]

Victor, me olvidaba de decirte
Uso la version Personal de Xailer y me conecto con TADODataSource
Por ser la version personal debí­ instalar el cliente ODBC de Mysql ( con
el de mariaDB hubo algunos problemas )
Entiendo que con la version enterprise la conexion es nativa....
Mientras tanto con la personal puedo ir investigando y creando mis
propios "Wrap".
Saludos a todos.
El 24/10/2014 a las 06:28 p.m., Contacto en Xailer escribió:
> Hola Victor.
>
> En mi modesta opinión la única forma que veo es programando OO por capas
> MVC y utilizando Store procedures en la Base de datos.
> Lo mismo comente en el blog:Le agregarí­a una sugerencia ( en mi caso lo
> impuse como condición ) Migrar a SQL con Stored procedures,
> procedimientos almacenados del lado servidor. Quizá cueste un poco más
> pero enseguida se recupera el tiempo invertido.
> Es realmente otro mundo.
>
> Quizá, quienes estamos en una disyuntiva similar podamos compartir
> experiencias y ( por que no ) código y ejemplos. Propongo armar una
> lista / grupo o lo que sea para estos temas.
>
> Te cuento lo que estoy haciendo
> - Motor de BD maria DB 10.0 ( esta version al igual que Mysql 5.6 tiene
> una gestion de errores excelene: disgnostics area )
> - Gestor de BD Heidi SQL 8.3
> - MySql workbench para diagramas Entidad Relacion ( también puede usarse
> como gestor de BD )
>
> Xailer vuela cuando 'ataca' a la BD.
>
> Este esquema (el modelo con SP) te sirve también para subir la BD a la
> nube e interactuar contra ella desde... cualquier otro entorno. No es un
> dato menor.
>
> Saludos,
> Claudio
>
>
> El 24/10/2014 a las 02:09 p.m., victor escribió:
>>
>> Excelente comentario!!
>>
>> Pero aunque estemos convencidos de la necesidad de migrar,
>> la pregunta es: Que tipo de cambios es preciso hacer?
>>
>> Pensemos en la tí­pica aplicación dbf, con tablas de muchos
>> campos y poquí­simo normalizada.
>>
>> Si se cambian directamente DbfDataSet por SqlDataSet ¿El
>> rendimiento no serí­a desastroso?
>>
>> La tí­pica navegacion DBF, los bucles while !eof()...
>> skip().. originarian cientos de consultas a la base de
>> datos.
>> ¿Existe algún tipo de buffer en los Sqldataset para evitar
>> esto?
>>
>> A nivel de concepto, seria muy interesante conocer, en base
>> a vuestra experiencia, que tipo de cosas habrí­a que rehacer
>> para migrar una aplicación tí­pica dbf a sql.
>> Ayudarí­a mucho para que cada uno se plantee los pasos que
>> tendrí­a que seguir para dar este salto, por otra parte
>> inevitable.
>>
>>
>
>
> ---
> Este mensaje no contiene virus ni malware porque la protección de avast!
> Antivirus está activa.
> http://www.avast.com
>
---
Este mensaje no contiene virus ni malware porque la protección de avast! Antivirus está activa.
http://www.avast.com

[xhermita]

No lo pienses Victor, lanzate.
Veras como muchas de las cosas que actualmente haces por código con
montón de lineas, con SQL se convierten en una instrucción que te
devuelve la información justa que necesitas.
Un ejemplo, si tienes un fichero con movimientos de artí­culos (entradas
y salidas) y quisieras saber el stock actual de ese articulo, con DBF
tendrí­as que recorrerte todo el fichero e ir sumando y restando las
unidades de cada movimiento para saber el resultado final.
En SQl tendrí­as algo así­;
Suponiendo que la tabla movimientos, tenga un campo 'tipo' donde se
almacena si el movimiento es de 'entrada' o 'salida', otro 'unidades'
que indica las unidades correspondientes a ese movimiento y un campo
'articulo' donde esta la referencia del articulo.
Lógicamente habrán mas campos, pero para esta consulta nos basta con estos.
SELECT stock AS SUM( IF( tipo='salida', unidades * -1, unidades ) )
FROM movimientos
WHERE articulo=740617212662
(nota: Es posible que es codigo SQL no este del todo bien, lo he echo de
cabeza y sin probarlo)
Esto te devolverí­a en segundos el stock del artí­culos que hemos buscado,
con la ventaja que todo el calculo se ha realizado en el servidor, a tu
pc solo le llega el resultado lo que reduce mucho el trafico de la red.
¿Cuantas lineas de código necesitaras para hacerlo en DBF? y lo mas
importante, ¿Cuanto tardarí­a en calcularse para por ejemplo 1000
movimientos?
Tienes que cambiar de mentalidad cuando tratas con SQL, el tiempo que
vas ha tardar en adaptarte es inversamente proporcional al tiempo que
vas a ahorrar una vez estés en funcionamiento.
Yo compre hace años un libro que me ha ayudado mucho y que nos recomendo
Jose Alfonso a varios, "Curso de SQL" de Anthony Molinaro
http://www.anayamultimedia.es/libro.php?id=1164323
Explica desde un nivel muy basico hasta operaciones bastante complejas,
con muchos ejemplos y ejercicios para hacer, y ademas te lo explica para
DB2, MySQL, SQL Server, ProstgreSQL y Oracle.
lo dicho, no te lo pienses.
Un saludo
Pedro Amaro

[bingen]

Cuando empiezas a trabajar en Sql lo único difí­cil es dejar de pensar en
los DBF y en como se hací­an las cosas antes, lo más fácil es aprender SQL.
Al poco tiempo estarás maldiciendo tener que mantener tus viejos
programas con DBFs y deseando pasarlos a Sql.
Salu2.

[vgest]

Muchí­simas gracias a todos, tanto por el apoyo como por los consejos. Es indudable que hay que hacer este cambio, todo es ponerse.
El problema es si tienes una aplicación inmensa (de un trabajo de muchos años), con miles de lineas de código y clientes usándola.
Entre estos miles de lineas, todos los algoritmos con datos son similares a:
oTab:Seek( minKey )
do while !oTab:Eof() .and. oTab:Cliente <= maxKey
if oTab:Fecha >= Fecha1
// Filtro y proceso de cada documento
..................
..................
endif
oTab:Skip()
enddo
Observese que la navegación por la tabla y el proceso mismo están mezclados (Estilo dfb clásico)
En cambio, para SQl la cosa es hacer una Select y traerse todos los registros al DataSet, recorrer y cambiar sus lineas y luego salvar, si procede.
Esto implica que todo el código anterior del programa es invalido, y por tanto tiene que ser repetido. Esta es la duda, si habrí­a algún camino para replantear una gran aplicación o si es preciso empezar desde cero.

[pacoelche]

A mi me gustarí­a utilizar SQL pues veo que todo va dirigido ahí­, pero sinceramente no tengo ni idea por donde empezar. Para mi SQL es chino mandarino. Llevo desde 1987 con DBF y no he utilizado otra cosa.
Agradecerí­a que me indicáseis algún buen manual al respecto para empezar desde 0 (por favor, en castellano).
Si aparte alguien quisiera hacer un manual, curso, etc. para su aplicación en Xailer, por lo que a mi respecta estarí­a dispuesto a pagar, no pido que vuestro trabajo sea gratuito.
Gracias y un saludo
Paco Martí­nez
"victor" <comercial[at]powercom[dot]es> escribió en el mensaje news:544a87c1$[email=1@svctag-j7w3v3j....]1@svctag-j7w3v3j....[/email]
Excelente comentario!!
Pero aunque estemos convencidos de la necesidad de migrar,
la pregunta es: Que tipo de cambios es preciso hacer?
Pensemos en la tí­pica aplicación dbf, con tablas de muchos
campos y poquí­simo normalizada.
Si se cambian directamente DbfDataSet por SqlDataSet ¿El
rendimiento no serí­a desastroso?
La tí­pica navegacion DBF, los bucles while !eof()...
skip().. originarian cientos de consultas a la base de
datos.
¿Existe algún tipo de buffer en los Sqldataset para evitar
esto?
A nivel de concepto, seria muy interesante conocer, en base
a vuestra experiencia, que tipo de cosas habrí­a que rehacer
para migrar una aplicación tí­pica dbf a sql.
Ayudarí­a mucho para que cada uno se plantee los pasos que
tendrí­a que seguir para dar este salto, por otra parte
inevitable.
--

[bingen]

No necesariamente, si trabajas con DBF pero con DataSets no tienes que
cambiar mucho para seguir trabajando con SQL también con datasets.
Haras un Open() un Addnew() o un Edit() un Update() y un Close() igual....
Pero no te lleves a equí­vocos, yo he intentado convertir varias
aplicaciones con DBF a SQL y me ha costado más que si empiezas de cero.
Mi recomendación, empiezas a trabajar con MySql haciendo pruebas, la
siguiente aplicación que hagas sobre todo si es pequeña la inicias con
MySql y ya llegará el momento de cambiar las otras aplicaciones
anteriores si es qu dispones del tiempo necesario.
Manuales de mysql y ayudas las hay por Intenet a toneladas, pero dime
una dirección email y te enví­o manuales de MySql si quieres.
Salu2.
El 27/10/2014 14:33, victor escribió:
>
> Muchí­simas gracias a todos, tanto por el apoyo como por los
> consejos. Es indudable que hay que hacer este cambio, todo
> es ponerse.
>
> El problema es si tienes una aplicación inmensa (de un
> trabajo de muchos años), con miles de lineas de código y
> clientes usándola.
>
> Entre estos miles de lineas, todos los algoritmos con datos
> son similares a:
>
> oTab:Seek( minKey )
>
> do while !oTab:Eof() .and. oTab:Cliente <= maxKey
>
> if oTab:Fecha >= Fecha1
>
> // Filtro y proceso de cada documento
> ..................
> ..................
> endif
>
> oTab:Skip()
> enddo
>
> Observese que la navegación por la tabla y el proceso mismo
> están mezclados (Estilo dfb clásico)
>
> En cambio, para SQl la cosa es hacer una Select y traerse
> todos los registros al DataSet, recorrer y cambiar sus
> lineas y luego salvar, si procede.
>
> Esto implica que todo el código anterior del programa es
> invalido, y por tanto tiene que ser repetido. Esta es la
> duda, si habrí­a algún camino para replantear una gran
> aplicación o si es preciso empezar desde cero.
>
>
>

[Carlos Ortiz]

Hola Victor, el problema no es sql (son un manojo de comandos, menos de
los que tení­amos en xBase) lo importante es interpretar estos datos,
diseñar bien y separar un poco las cosas para que todo sea mas fácil de
mantener.
De hecho siempre podrí­amos haber programado de esta manera, código
limpio y claro pero venimos arrastrando un lastre que nadie se puso
firme en evitar (montones de lugares desde dónde se acceden a los datos,
se acceden desde las pantallas, no se usan clases, etc. etc.) con
cualquier lenguaje se podrí­a haber hecho esto y mas con clipper teniendo
objetos.
Hace un tiempo le dicte un curso a un colega por skype (y lo ofrecí­ en
el foro) para progamar en Xailer usando sql / clases y objetos todaví­a
esta vigente, si querés lo charlamos por privado, saludos.
Carlos Ortiz.
ca-ortiz@hotmail.com es mi cuenta para skype, al que le interese ya sabe
solo tiene que dedicarle 4 sábados o menos.

[juanc]

Gracias por el empujon y la motivacion, seguramente algunos terminaremos
siguiendo el consejo. Saludos Cordiales.
PD Ahora lo que sigue es: investigar y aprender y si el coco lo tenemos duro
pues preguntar...
---
Este mensaje no contiene virus ni malware porque la protección de avast! Antivirus está activa.
http://www.avast.com

[Rich]

Amigos, tengo 45 años programando, en 2007 adquirí­ la licencia de uso de Xailer Enterprise y desde entonces la he venido utilizado con MySQL y a partir de 2010 con MariaDB. Les ofrezco mi ayuda a través de cursos en lí­nea (webinars), para llevarlos de la mano en el cambio de tecnologí­a DBF's a SQL (bases de datos y tablas de MySQL o de MariaDB). Mi correo es meridiano74@prodigy.net.mx tengo mucha experiencia en impartir cursos eficaces.
Raúl Olivares G.