Gestor de BD

He desarrollado una aplicación VB (ADO), Access 2000 (ODBC), que hasta ahora no ha funcionado perfectamente, pero, tengo un cliente que maneja una cantidad de información superior a los anteriores.
- 40000 referencias
- 3000 clientes y proveedores
- Tarifas de proveedores de hasta 450000 registros
- 500000 de lineas de venta año aprox.
Me temo que Access se queda corto, puesto que las búsquedas, estadísticas (Crystal Reports 8.5) son lentas.
¿Qué Gestor de bases de datos me recomiendas?

1 respuesta

Respuesta
1
Por lo que veo, los volúmenes de datos que me comentas no son grandes, el código del programa es tuyo, con lo que puedes cambiar los accesos a datos cuando quieras, osea que en principio lo tenemos fácil... bueno pues yo creo que debería ir a Sql-Server... aunque nunca descartes Oracle, ya que Oracle ofrece todo lo que pueda tener Sql-server, corregido y aumentado... Como tienes los programas hechos en VB, creo que se simplificará la cosa con trabajando con la "base de datos" de la casa... osea microsoft que con una externa, además si tienes cierto volumen y movimiento, a corto, medio plazo Oracle necesitará la mano de un Administrador para que todo funcione bien, y vaya optimizado, cosa que con Sql-server no... a lo mejor es una ventaja y todo.. pero bueno yo creo que debes valorar unos puntos antes de decidirte:
1.- Volumen Datos: Cuando se estime que se puede llegar a un volumen de datos considerable... y por ponerle un numero, yo diría que unos 20, o 25Gb empieza a ser muy recomendable pensar en Oracle. Por la manejabilidad, la operatividad que ofrece.
2.- Numero de transacciones: Al igual que el volumen de datos, cuando se espere generar muchas transacciones, los mecanismos con los que cuenta oracle, son muchos más resistentes a transacciones concurrentes que lo que ofrece sql-server.
3.- Usuarios concurrentes: Aunque no lo confiesen, Sql-server tiene problemas cuando se reciben multitud de usuarios concurrentes conectados, de todos modos creo que esto no nos debe preocupar porque no creo que esperemos más de 100 usuarios, ¿no?
4.- ¿Alguien se puede hacer cargo de la Administración de la Base de datos?. Necesitaremos a alguien con conocimientos suficientes como para poder dar soporte técnico de sistemas para la aplicación.
5 .- ¿Tengo suficiente "Hardware" para instalar un servidor de Oracle?. Esta pregunta es clave, ya que aunque no lo parezca si tenemos una máquina "justita" para que corra oracle, a la larga lo pagaremos muy caro, ya que si ahora funciona más o menos bien, con el tiempo al crecer la B.DE y posiblemente los usuarios, irá decayendo el rendimiento de la misma, sin posibilidad de mejorarlo.
En fin creo que son en resumidas cuentas, los puntos por los que te puedes guiar a la hora de decidirte por uno o por otro entorno.
Que tengas suerte en tu decisión!.
Pedro
Ante todo muchas gracias.
Mi duda es realtiva al punto 5.
El servidor deberá soportar 25 equipos en la red local de la central, y otros 5 puntos de otras tantas sucursales en un área de unos 10-50 Kms.
¿Qué tipo de máquina debería ser?
¿Qué tipo de conexiones para central-sucurcales, tanto tipo de linea, (ahora lineas punto a punto de telefónica) como tipo de acceso, ADO, RDO,?
¿Qué sistema operativo, Servidor y Clientes?
Saludos,
Xabi.
Yo siempre que puedo recomiendo que se usen sistemas operativos robustos, fiables y con suficiente documentacion; el problema es que casi nunca se cumplen los requerimientos, osea que lo mejor es que si lo vas a administrar tu, instales el sistema que mejor controles, el que mejor conocimiento tengas. Si se te da mejor Unix, o linux, pues mejor para ti, porque a mi parecer son los mejores ... en este caso linux te resolvería muchos quebraderos de cabeza con respecto al tema de TCP porque tiene una facilidad de configuración y una robustez a prueba de bombas, pero claro debes tener un buen conocimiento de linux y también de ShellScripts para poder administrarlo bien; en su defecto te recomiendo encarecidamente que te decidas por un "servidor" de windows NT o 2000 preferiblemente.. más que nada por el tratamiento de la seguridad si van a acceder usuarios por WAN.
En resumen : LINUX, UNIX, WINDOWS 2000. Cualquiera te vale, aunque mis preferidos para Oracle son Unix y Linux... por ese orden.
El "Hardware" que te recomiendo es mínimo 500Mb Ram (mínimo) lo recomendable sería por encima de 1Gb porque las últimas versiones de oracle requieren mucha ram.
Placa dual PIII 700. Y esto tiene una justificación: La atención casi a tiempo real de varios procesos concurrentemente y sin afectar al momento de producción.
En caso de que no puedas acceder a un servidor con 2 procesadores, pues intenta dar la máxima velocidad... lo notarás.
HDD: Debe ser SCSI e ir en Raid 5 como mínimo. Es sumamente importante que los discos cuenten con alguna redundancia; En una ocasión en nuestra empresa compramos 32 discos SCSI para aumentar la capacidad del servidor central y tuve un debate con el administrador de unix, ya que el se empeñaba en hacer Raid 0 + 1 (espejo stripeado), para que en caso de desastre tener el sistema cubierto y yo le decía(por mi escasa experiencia) que no haría falta... que con las copias ya bastaba... pues bien en una ocasión hubo un fallo de hardware y fallaron 2 discos de distinto RAID. ¿Qué habría pasado si no hubiese estado en Raid 0 + 1?... que hubiésemos tenido que cerrar el sistema, hasta que la empresa de outsourcing nos trajesen los discos y monstasemos de nuevo la b.DE en los nuevos disco: en total 5 días seguro:
Resultado: 2 administradores en el paro.
Osea que te recomiendo que intentes acceder a Raid 1, no hace falta que lo stripees... con Raid 5 también dormirás tranquilo... solo que si falla un disco tendrás que esperar a tener otro para pincharlo y regenerar la información perdida... pero bueno también es buena solución.
Resumen:
Sistema Operativo: Win 2000, Linux, Unix... depende de tus conocimientos.
Hardware: 1gb Ram, HDD (capacidad la que tu estimes necesaria)
Raid 1 o Raid5.
BUS SCSI.
Streamer de Copias con capacidad para asumir los backup del sistema todos los días completo.
UPS: Muy recomendable, ya que trabajando con un B.DE en caso de apagón, podemos dejarla con inconsistencia de datos... yo diría que imprescindible.
Bueno, espero haberte servido de ayuda.
Suerte y al toro!
Pedro

Añade tu respuesta

Haz clic para o

Más respuestas relacionadas