Migrar sistema en Paradox a MySQL

[golf2008]

Colegas:
Estoy migrando un sistema en paradox a mysql con Zeos.
Haciendo pruebas comprobé que el componente TZTable funciona exactamente igual que el TTable.
Pregunto a los expertos en mysql y Zeos: es necesario ejecutar sentencias SQL con el ZQuery, porque el rendimiento del TZTable es el mismo.
Gracias

[lucasarts_18]

Empezado por golf2008

Pregunto a los expertos en mysql y Zeos: es necesario ejecutar sentencias SQL con el ZQuery, porque el rendimiento del TZTable es el mismo.
Gracias

No soy experto en esto, pero creo saber algo, TTable está ligado a BDE, es decir si usas este componente necesitas distribuir con tus aplicaciones el BDE, además estos se conectan mediante ODBC y como todos saben el rendimiento no es tan óptimo como cuando se hace mediante conexión nativa mediante algún componente, en este caso ZEOS.

Hasta Luego .-

[golf2008]

gracias por tu respuesta, pero tengo muy claro lo que decis del Ttable.

Mi pregunta apuntaba a: como es el rendimiento de TZTable (Zeos) comparado con ejecutar sentencias SQL con el ZQuery (Zeos), porque hacen lo mismo. Y por lo tanto la migración no sería tan engorosa.
Gracias totales.

[[poliburro]]

Empezado por golf2008

Colegas:

Pregunto a los expertos en mysql y Zeos: es necesario ejecutar sentencias SQL con el ZQuery, porque el rendimiento del TZTable es el mismo.
Gracias

Pero claro que es necesario, de hecho es mucho mejor usar Sps. Una muestra

Imagina que tienes una tabla con un millón de registros. y necesitas actualizar el registro # 598715. Si usas un Table, deberás primero cargar todo el contenido de la tabla y despúes usar un FindKey para posicionarte en el registro y modificarlo. Esas dos operaciones son sumamente costosas.

Ahora, con un query, solo necesitas ejecutar la consulta de actualización ahorrando enormes recursos.

El rendimiento es el mismo entre un table y un query?,
por supuesto que !!NO¡¡

[golf2008]

Hace la siguiente prueba:
Ejecuta con un TZTable (Zeos), por ejemplo agregar un registro y grabar.
Colocá un TZSQLMonitor (Zeos) y en el archivo de texto que genera, fijate que sentencias se ejecutan.
Me gustaría saber tu respuesta

[[poliburro]]

te propongo una prueba mejor,

carga tu tabla con 1 millón de registros,

y despúes haz la prueba que mencionas,

[keyboy]

Empezado por golf2008

Hace la siguiente prueba:
Ejecuta con un TZTable (Zeos), por ejemplo agregar un registro y grabar.
Colocá un TZSQLMonitor (Zeos) y en el archivo de texto que genera, fijate que sentencias se ejecutan.
Me gustaría saber tu respuesta

Yo ya hice esta prueba y éste es el archivo que se genera:

1. CONNECT TO "base" AS USER "usuario"
2. SELECT * FROM tabla
3. SHOW TABLES FROM base LIKE 'tabla'
4. SHOW COLUMNS FROM base.personal LIKE '%'
5. INSERT INTO base.tabla (...campos...)

Descontando la conexión al servidor (1) y la obtención de la metadata (3, 4) nos quedan dos consultas. Como sabes, la última instrucción (5) es más que suficiente para insertar un registro. Así que la "única" diferencia es (2):

seleccionar todos los registros de la tabla

Ahora haz la prueba que te propone poliburro.

Bye

[[AzidRain]]

El TZTable únicamente se inlcluye en Zeos como compatibilidad hacia atrás y de hecho es un "SELECT *". En su lugar utilizar un TZQuery aunque de inicio ocupes de todos modos una sentencia "SELECT *" pues más adelante cuando requieras ya filtrados o algo similar podrás cambiarlo sin mucho problema y sin tener que cambiar tu código. Ahora, si tienes la seguridad de que tu tabla nunca pasará de unos cuantos registros es una buena opción pero te repito es lo mismo que un TZQuery con SELECT *

[golf2008]

Me gustaría saber en que tipo de aplicación tuviste tu "gran experiencia" de trabajar tablas con un millón de registros.
Espero tu respuesta.

Azidrain: gracias por tu respuesta, fué la mejor.

[[eduarcol]]

Empezado por golf2008

Me gustaría saber en que tipo de aplicación tuviste tu "gran experiencia" de trabajar tablas con un millón de registros.
Espero tu respuesta.

Azidrain: gracias por tu respuesta, fué la mejor.

Cualquier tipo de aplicacion seria de facturacion a vuelta de un año puede llegar a esa cifra, asi que no es tan descabellada.

[golf2008]

Se nota que nunca implementaste ni siquiera un sistema de facturación.

[[AzidRain]]

El comentario del poli me parece atinado pero creo que al igual que a todos el te lo hizo con la poca información que tenemos de lo que vas a hacer. De hecho no mencionas precisamente para que lo vas a ocupar.

Es cierto que una facturación puede llegar a tener gran cantidad de registros pero esto no es necesariamente una ley. He realizado facturaciones que al cabo de un año solo llegan a unos cuantos cientos y otras donde rondan las 100 mil. No hay nada escrito en esto y creo que el análisis ya te toca hacerlo a tí, finalmente tu pregunta era muy concreta. Lo que pasa es que todos nos emocionamos cuando queremos responder y a veces exageramos. Vamos, igual y tu pregunta tenía que ver con alguna tarea de la uni..y nosotros aquí casi peleándonos...

[[poliburro]]

Empezado por golf2008

Se nota que nunca implementaste ni siquiera un sistema de facturación.

, vaya, mejor me ahorro mis comentarios.

[keyboy]

Ni siquiera hay que llegar a un millón de registros. Con 20000 o incluso 5000 o 2000 registros o menos, hacer un SELECT * puede ser excesivo a no ser que estemos trabajando en nuestra pc en local. Via TCP, aun con una conexión de banda ancha, este tipo de selecciones tienen un rendimiento muy malo.

Bye

[[eduarcol]]

Pues eso es lo que saca uno por ayudar, y es verdad nunca he trabajado con un sistema de facturacion, y todos estos años he vivido de la beneficiencia social...

[[poliburro]]

Empezado por eduarcol

Pues eso es lo que saca uno por ayudar, y es verdad nunca he trabajado con un sistema de facturacion, y todos estos años he vivido de la beneficiencia social...

:P jajjajajajaja. Pero si cada troll que de repente cae al site verdad amigo eduarcol?

[[eduarcol]]

Empezado por poliburro

:P jajjajajajaja. Pero si cada troll que de repente cae al site verdad amigo eduarcol?

pues eso es lo que se saca por ayudar a desconocidos, menos mal que todos no son asi, y pensar que si sacara cuentas, una tabla para llegar al millon solo necesita 2,800 inserciones diarias, cosa que puede hacer cualquier supermecado mediano, ya que no son 2,800 facturas necesariamente, solo 2,800 registros.

y como dicen Azid y KeyBoy solo con 100mil un sistema mal diseñado comenzara a colapsar.

[lucasarts_18]

Empezado por eduarcol

y como dicen Azid y KeyBoy solo con 100mil un sistema mal diseñado comenzara a colapsar.

Hola, esto es cierto, tambien lo que dice keyboy, con 5000 registro empieza a flaquear cualquier sistema, por lo tanto, ¿qué sistema necesita desplegar tal cantidad?, por eso siempre hay criterios para listar una serie de registros.

No quiero cambiarme de tema..., pero paginar resultados en php me ha dado muy buenos resultados de rendimiento, cosa que empezaré a pensar en implementar en los sistemas de escritorio con delphi

Hasta Luego .-

[Martin Subira]

Hola compañeros:

En mi empresa informatizamos cadenas de tiendas y supermercados.

Es algo común tener, como valores promedio de una cadena de 40 supers:
5 TPVs/supermercado x 300 tickets/Tpv x 10 líneas/ticket

Eso son 600.000 registros diarios de líneas de ticket
Multiplicad x 300 días hábiles/año y da 180.000.000 registros/año

Y veréis que, teniendo en línea dos años (nuestros clientes tienen hasta 5 vaños), pues da unos cuantos milloncejos de líneas.
Y no es ninguna fantasmada, es algo real como la vida misma.

[AlexCan]

Mira golf2008 yo estoy desarrollando un sistema de puntos de ventas y facturación. Y si todos los demas tienen razón en que en este tipo de proyectos tienes que estar acostumbrado al estas cantidades exorbitantes de registros. Ademas de que no te debes ofender por los puntos de vistas ya que es por ofrecerte AYUDA que no se te olvide.

Sin embargo muchachos estan de acuerdo que no todos los sistemas en este caso de facturación estan enfocados a grandes supermercados y negoscios gigantescos Hellooo? también existen las pequeñas y medianas empresas.