Velocidad en Cajeros de Supermercado

[Esteban Quito]

Hola a todos. Tengo el siguiente problema en el siguiente contexto.
Aplicacion de gestion comercial desarrollada en delphi 7 y tablas Paradox 7 instalada en un autoservicio de dos cajas y tres PCs (caja 1 con Celeron 6.1 (s.o.WinXp), caja 2 con Pentiun III (s.o.Win98) y la oficina administrativa una integrada VIA y (s.o.WinXp)) y dos controladores fiscales Epson TM 2000. Yo instalé los datos (entre ellos 13000 artic) en la caja 1 que es el punto donde mas se trabaja, y la aplicación en las tres PCs. La red es Windows.
La Caja 1, que es la que tiene los datos accede con buena velocidad pero el problema es la velocidad de coneccion con el TM 2000 y en la caja dos se potencian todas las demoras de manera tal que si no logro la velocidad requerida por mi cliente buscará otro software.
Mi pregunta es qué estoy haciendo mal ya que es mi primera experiencia en cajeros de autoservicio donde la facturación es intensa y con los cajeros(empleados) acostumbrados a la velocidad del cobol (antes funcionaba con una aplicación en cobol rm85)

Sé que en una base de datos Cliente Servidor, el problema estaria solucionado (eso creo), pero la solución debo encontrarla de inmediato y pasar entera una aplicación de tablas planas a cliente servidor tendría un costo en tiempo que mis clientes no estarían dispuestos a esperar.

Describo brevemente como es (desde el punto de vista Código) el acceso a los datos y a un articulo específico.
Un Query que carga los 13000 artículos, un Locate de ese Query se encarga de la busqueda del codigo de barras contenido en un control Edit con el SetFocus permanente que toma la lectura del scanner. A partir de ahí, comienza el envio del item al TM2000, el descuento de stock, totalizador (un conjunto de acumuladores), etc. Me sugirieron que en vez de Query de 13000 y el Locate, ejecute un Query para un solo articulo parametrizado por el código de barras. Esto significa leer del disco cada vez que se scannea un artículo. Ambos mecanismos funcionaron igual en la PC mas grande pero en la mas lenta, la lectura en disco por cada articulo ingresado es una muerte.

Bueno. Si necesitan mas detalles del código Delphi o sql para entender el lio que estoy haciendo, solo me dicen. Muchas gracias desde ya.

[[Lepe]]

Habrá que empezar por la pregunta más obvia: ¿has creado un índice secundario por el campo del codigo de barras? ¿es clave primaria por casualidad?

Si tienes un índice o es clave primaria, el locate si usará dicho índice. El proceso de búsqueda puede tardar.... 50 milisegundos.

Si la caja 1 y 3 van perfectamente y la 2 es la lenta, es la prueba feaciente de que no se trata de Software sino de Hardware.

Entre tú y yo: podríamos echarle la culpa a Win98, intentar instalar WinXP y ver si mejora, pero si realmente el hardware es menor (poca RAM, microprocesador, etc) es más aconsejable cambiar el Hardware directamente.

Precisamente tengo funcionando Paradox 7 + WinXP en 3 ordenadores PII a 500 Mhz con 128Mb de RAM y las consultas son instantáneas, incluso los TTables.

Saludos

[Esteban Quito]

Si. Efectivamente,he creado un "Secundary Index" por el campo tipo Alpha Codigobarra. No estoy seguro si es correcto lo siguiente. Configuracion de Index Option: Unique=False, Maintained=True, Case Sensitive=False y Desending=False

[Esteban Quito]

Perdon. Me faltó decirte que cajas son la 1 y la 2. La tercera pc (VIA 3000 integrada con s.o. WinXp) está en la administración y tambien es lenta cuando abre los 13000 articulos y modifica alguno. Pero de última, la preocupación de mi cliente es que las dos cajas facturen a mayor velocidad.

[jachguate]

Empezado por Esteban Quito

Si. Efectivamente,he creado un "Secundary Index" por el campo tipo Alpha Codigobarra. No estoy seguro si es correcto lo siguiente. Configuracion de Index Option: Unique=False, Maintained=True, Case Sensitive=False y Desending=False

Dos observaciones sobre el índice:

• A menos que los items tengan la posibilidad de un código de barras alfanumérico, un índice entero funcionaría mucho mas rápido. Si los códigos son UPC o EAN-13, solo tendrán números.
• ¿Realmente dos productos pueden tener el mismo código de barras?. No lo creo, por tanto el índice también podría ser único, lo que en la mayoría de motores acelera las búsquedas.

Menciono ambas cosas como "cultura general" de bases de datos. Nunca trabajé con paradox, por lo que ignoro si es aplicable en dicho caso.

Sobre la lentitud en general, es probable que el asunto vaya lento porque el sistema se ve en la necesidad de hacer swap de memoria al disco. Es una buena ídea que desactives todo servicio/aplicación que no se use y que se haga un buen tunning de la máquina. Si aún encontrás memoria para ella, duplicar la cantidad de RAM tampoco vendría mal.

Hasta luego.

[[AzidRain]]

Me parece que estamos fente a un error de diseño de la BD. Por definición la BD para artículos que pasan por un POS SIEMPRE estará dado por 12 o 13 dígitos( upc o EAN) que son lon los que el punto de venta registrará siempre. A fin cuentas un POS lo único que hace es mándarle al servidor una serie de UPCs escaneados para que los convierta en descripciones y precios. El problema es que elegiste tablas planas para una aplicación que no se ajusta a eso. El problema de velocidad estriba en el locate que haces para buscar los datos de cada item escaneado.

Un Query que carga los 13000 artículos,

Precisamente ese es el problema. Un buen query solo carga los items necesarios para la operación.

La verdad ni como ayudarte, el diseño está mal desde un inicio y de no ser migrar todo a MySQL, FB o Posgress no veo por donde...

[[Al González]]

Hola Esteban, además de los consejos que ya te han dado los compañeros. Te sugeriría evaluar la posibilidad de tener una base de datos independiente en cada computadora, en lo que consigues convertirla a cliente-servidor, lo cual será la solución definitiva (mi recomendación es Firebird).

Mientras tanto, es probable que al final de cada día (y ojalá sólo en ese momento) se requiera reunir información de las tres bases de datos para obtener reportes de ventas y similares. También es muy posible que necesites actualizar precios y existencias en las tres bases de datos. Pero si te das cuenta, estos no son procesos involucrados directamente en el registro y cobranza de las ventas.

Supongo que a tu cliente lo que más le interesa es que los cajeros no dejen de cobrar a una velocidad aceptable la mercancía que sale. Si esto es así, separa las bases de datos para que las tres cajas trabajen de forma autónoma temporalmente, y ármate de un plan de administración / sincronización de datos para los cortes de caja y actualización de inventarios de cada día. Tal vez tu cliente sí aceptaría el coste económico del cambio a cliente-servidor, mientras no le dejes detenido el negocio. Es una cosa de sentido común, a la larga tendrás tu sistema operando con una sola base de datos, pero eficientemente.

Erraste el camino al usar una base de datos de escritorio en procesos tan críticos como los de una caja de súper mercado, pero no te resultará complicado asimilar algo como Firebird. Te iremos ayudando conforme podamos (además del inmenso material que ya hay en los foros).

Eso sí, por nada del mundo se te ocurra usar MS Access.

Un abrazo partido en tres.

Al González.

[Neftali [Germán.Estévez]]

¿Has pensado en temas de red?
No es exclusivo con las soluciones anteriores, sino que es un añadido. Unas terjetas de red más rápidas, tal vez te ayudarían un poco.
Imprescindible también el tema de los índices únicos.

Otra cosa; De los pasos que haces. ¿Sabes exactamente cual es el que está tardando? ¿Has puesto marcas de tiempo?

Creo que cargar 13.000 artículos y luego hacer un Locate que los recorre en memoria es un error. Como ya te han dicho una SQL que busque el único que necesitas debe ser mucho más eficiente (si utilizas los indices correctos).

[Esteban Quito]

Gracias por el interes que le han dado a mi caso.
Les comento otra cosa que agraba mi situación. Se pierde la comunicación con el controlador TM2000 y supongo que es debido a que la aplicación le envia una nueva impresión de item sin que haya terminado de imprimir el anterior. Este error genera la cancelación del ticket y normalmente es cuando ya tiene muchos renglones. Les agradecería que me den una ayudita tambien en esto.

[Yosuun]

Bueno, creo recordar de mis tiempos de paradox que no utilice nunca querys para trabajar contra paradox, sino que utilizaba los indices que serian necesarios crear para las busquedas y utilizaba las intrucciones

Tabla.Findkey, Tabla.FindnearEst.
Hechales un vistazo a toda su gama de sabores, la velocidad era excelente y te estoy hablando de maquinas 386 con 256MB de Ram de aquel entonces y tuve funcionanado la aplacacion durante unos 5 años a pleno rendimiento con tablas que llegaban en aquel entonces a la nada despreciable cifra de un millon y medio de registros aproximadamente.

Espero que te sea de utilidad un saludo.

PD. si utilizas una maquina como servidor en NT en Windows 2000 creo ke no hacia falta no olvides eliminar la escritura en cache y te evitaras la corrupcion de indices.