Visual Basic y bases de datos grandes

eescaler · #1 (**permalink**) 17/08/2005, 16:03

Soy un recientemente graduado de la carrera de Ingeniería en Sistemas acá en México, y en mi actual trabajo se les ha presentado un problema bastante interesante:

Diseñaron hace un par de meses un sistema para una aduana, y lo programaron usando Visual Basic 6 y conectandose a una base de datos de SQL. Pero al momento de implementar el sistema éste no puede con el enorme volumen de datos que pasan por la aduana.

¿Qué posibilidades tengo para "arreglar" esta aplicación y permitir que maneje los datos de 4,000 transacciones diarias que se dan en esta aduana? Cualquier comentario es bienvenido y, gracias.

Developer9 · #2 (**permalink**) 17/08/2005, 17:09

Haber "Ingeniero"

... la herramienta front end que utilices no tiene tanta importancia, la que pinta es la base... primero dices que se conecta a SQL... sera SQL Server (que lo dudo compañero) o MySQL... o que base será. Tambien depende de como esté diseñado el modelo entidad relacion. Tambien podrias comentar que errores te salen al tratar de acceder a tu base grande

biffly · #3 (**permalink**) 18/08/2005, 12:53

no se MYSQL ya que no lo utilice nunca y hasta donde se no trabajo con SP, pero para que SQLSERVER comience a trabajar de verdad tendrias que hablar de porlomenos 5 millones de registros, es muy probable que si usas SQLSERVER te sea muy util trabajar con SP ya que estos agilizan mucho el trabajo, pero como te an comentado anteriormnte con tan poca info es dificil decir, saludos :D

Developer9 · #4 (**permalink**) 19/08/2005, 10:40

Eje!! claro que es mejor trabajar con procedures.

eescaler por favor primero comenta que errores te da la aplicacion y que base utilizas

MaxExtreme · #5 (**permalink**) 19/08/2005, 19:35

No son nada, 4000 trans/día significa una transacción cada 20 segundos... ¿Seguro que no puede? Es Visual Basic pero tampoco es que sea tan lento.

:)

biffly · #6 (**permalink**) 19/08/2005, 21:16

mira creo que te olvidaste de decirnos que base estas usando SQLSERVER??????

GeoAvila · #7 (**permalink**) 21/08/2005, 08:37

bueno..... al parecer alguien necesita leer un par de manuales....jajaj

nos vemos..

Developer9 · #8 (**permalink**) 23/08/2005, 19:44

Cita:

Iniciado por MaxExtreme

No son nada, 4000 trans/día significa una transacción cada 20 segundos... ¿Seguro que no puede? Es Visual Basic pero tampoco es que sea tan lento.

:)

Compañero MaxExtreme, el problema no es la aplicacion (el "ingeniero" que hizo el post cree que modificando la aplicación puede arreglar el problema) el problema es el motor de la base de datos

MaxExtreme · #9 (**permalink**) 23/08/2005, 20:40

Cita:

Iniciado por Developer9

Compañero MaxExtreme, el problema no es la aplicacion (el "ingeniero" que hizo el post cree que modificando la aplicación puede arreglar el problema) el problema es el motor de la base de datos

¿De qué hablas?

No me hagas creer que una base de datos normalita no puede mover algo cada 20 segundos...

El problema está en el programa de Visual Basic, en la configuración de la base de datos o en que el equipo no es potente.

GeoAvila · #10 (**permalink**) 24/08/2005, 08:10

bueno para solucionarle el problema, mira nos podes enviar como va al controlador de la base de datos asi lo podemos identificar..

nos vemos..

Developer9 · #11 (**permalink**) 24/08/2005, 17:01

Cita:

Iniciado por MaxExtreme

¿De qué hablas?

No me hagas creer que una base de datos normalita no puede mover algo cada 20 segundos...

El problema está en el programa de Visual Basic, en la configuración de la base de datos o en que el equipo no es potente.

Eje! ah claro, puede ser que al servidor de base de datos no le de la raza o un modelo entidad/relacion pobremente normalizado o sin constrains... lo unico que hace el programa es hacer un begintrans y ejecutar sentencias sql tipo DML y/o queries... y según el modelo de datos puede que se demore la ejecución de cada sentencia pero eso ya no es problema de la aplicación sino del motor de bd, para finalmente hacer un commit.

Una transacción puede demorar mas de 20 segundos, depende del conjunto de sentencias sql que contenga y lo pesadas que se puedan volver

MaxExtreme · #12 (**permalink**) 24/08/2005, 20:11

Cita:

Iniciado por Developer9

Eje! ah claro, puede ser que al servidor de base de datos no le de la raza o un modelo entidad/relacion pobremente normalizado o sin constrains... lo unico que hace el programa es hacer un begintrans y ejecutar sentencias sql tipo DML y/o queries... y según el modelo de datos puede que se demore la ejecución de cada sentencia pero eso ya no es problema de la aplicación sino del motor de bd, para finalmente hacer un commit.

Una transacción puede demorar mas de 20 segundos, depende del conjunto de sentencias sql que contenga y lo pesadas que se puedan volver

Muy bien, haciéndote sonar importante. Lo único que has dicho en resumen es que si se manda hacer algo muy largo, se va a tardar más.

Ahora piensa un poco. ¿Me quieres hacer creer que una transacción va a tardar más de 20 segundos por muy pesada que sea? No sé a que llama "transacciones", pero tanto si no se pueden hacer más rápido, tanto esté mal diseñado todo, entonces tienen un serio problema, a mi parecer.

Developer9 · #13 (**permalink**) 25/08/2005, 19:33

Una transacción puede durar mucha mas de 20 segundos compañero Max... puede ser por muchos factores, el tamaño de la base, el volumen de datos que esten involucrados, la manera en que la modelaron, la conexion, el motor de la base... dependiendo de todo eso puede hasta que sea normal que el tiempo en cuestion

MaxExtreme · #14 (**permalink**) 26/08/2005, 05:30

Cita:

Iniciado por Developer9

Una transacción puede durar mucha mas de 20 segundos compañero Max... puede ser por muchos factores, el tamaño de la base, el volumen de datos que esten involucrados, la manera en que la modelaron, la conexion, el motor de la base... dependiendo de todo eso puede hasta que sea normal que el tiempo en cuestion

Como tú mismo dices, "puede que hasta sea normal". Entonces estaremos de acuerdo en que un tiempo así para una transacción es exagerado, hablando de la media de todo el día, no de una en concreto que haya habido una caída... un pico en la red... un servidor saturado... un botón mal presionado...

Developer9 · #15 (**permalink**) 26/08/2005, 18:48

cLARO... dependiendo del tipo de transaccion... si el trans involucra pocas sentencias sql que no pesen mucho hay algun problema, pero es de la base no de la aplicacion compañero Max

MaxExtreme · #16 (**permalink**) 27/08/2005, 05:32

Cita:

Iniciado por Developer9

cLARO... dependiendo del tipo de transaccion... si el trans involucra pocas sentencias sql que no pesen mucho hay algun problema, pero es de la base no de la aplicacion compañero Max

No, de la base no es... La aplicación manda hacer cosas a la base de datos, pero ésta es otra aplicación sin diferencia, guiada por otras. En resumen, si tienes que acortar las transacciones, lo hará la aplicación, no la base ;) Y si no se puede hacer mejor, pues tardará lo que tarde la base de datos, pero eso es un factor que ya se conoce desde el principio. Aunque, verdaderamente, no se como va a hacr a una base de datos ir lenta, son rapiiidííísimas. Están para eso.

Developer9 · #17 (**permalink**) 31/08/2005, 18:27

Cita:

Iniciado por MaxExtreme

No, de la base no es... La aplicación manda hacer cosas a la base de datos, pero ésta es otra aplicación sin diferencia, guiada por otras. En resumen, si tienes que acortar las transacciones, lo hará la aplicación, no la base ;) Y si no se puede hacer mejor, pues tardará lo que tarde la base de datos, pero eso es un factor que ya se conoce desde el principio. Aunque, verdaderamente, no se como va a hacr a una base de datos ir lenta, son rapiiidííísimas. Están para eso.

La marihuana solo se fuma... no se come!