Hora: 27-Jan-2020, 10:23 AM ¡Hola, Invitado! (Iniciar sesiónRegístrate)

Enviar respuesta 
Acceso a datos 13 : Elección del formato de datos/soporte físico
Autor Mensaje
admin Sin conexión
Administrator
*******

Mensajes: 16,280
Registro en: Dec 2005
Mensaje: #1
Acceso a datos 13 : Elección del formato de datos/soporte físico
Si bien es cierto que las aplicaciones modernas pueden correr sobre un montón de plataformas, en la práctica tenemos pocas opciones reales.

Frecuentemente me preguntan.. tengo problemas con el Access 2000, que hago ? Y el problema es que una aplicación con Access 2000 debe de tener instalado en las maquinas destino el motor ( preferentemente DAO 3.6 ) para ese formato. Si usan access usen el formato 97 y quitense de dolores de cabeza.

He comentado que hay pocas opciones, pero antes de explicarlas una por una, nuestro sistema debe de ser portable, esto es una característica de RAD. Porqué? Bueno, anteriormente comenté que debemos programar en base al Acceso, no a los datos.

En febrero de este año una empresa me pidió que hiciera un sistema basado en ORACLE. Yo no sabía con que versión iba a trabajar, asi que lo primero que hice fue con el Data Architect un modelo físico suponiendo que iba a usar Access 97. Un poco mas adelante en el proyecto, resultó que alguien se dió cuenta que era contraproducente usar el servidor ORACLE disponible, y me dijeron que pasara a SQL Server 7.0. Y cosa de un mes después se dieron cuenta que el sistema no podía usar el servidor SQL, y lo terminé pasando a Access. Pero no tuve que cambiar nada cada vez, excepto una linea de código. Por la manera en que se hace el diseño, cambir de plataforma puede ser una pesadilla o muy facil.

Pasando a los soportes físicos tradicionales, podemos usar varias alternativas:
  • Access 2000 - Tiene ventajas supongo, pero también el gran problema que si se instala en una PC que usa office 97 puede desconfigurarla casi completamente. Por otra parte necesita mas recursos que Access 97, y obviamente no es compatible hacia atrás, es decir, access 97 no puede abrir una base access 2000, lo que puede ser una ventaja. Su clave de provider JET es 4.0 ( luego vemos que es eso ), y su requisito es MSDAC 2.6. Ojo, si usan DAO es 3.6.
  • Access 97 - Su ventaja principal es que es el motor incluido en VB5 y VB6. En una empresa me tocó realizar una serie de procesos con una tabla Access, pero ni siquiera tenía Access. Conociendo las sintaxis DAO/ADO, no es necesario pagar por el soporte de Access, y esto impide que los clientes lo modifiquen desde la base y puede disminuir costos. Su principal problema es que es poco resistente/estable para una aplicación grande/mediana que usen varias tablas. Los de las gaseras, recordarán como avisé con UN AÑO Y MEDIO DE ANTICIPACION, los problemas que iban a tener si usaban Access y nadie me creyó. Lean los comentarios en las lecciones anteriores sobre access para mas señas. Su clave de Provider JET es 3.51 y su requisito es MDAC 2.0 o 2.1.
  • SQL Server 6.5 - Su ventaja principal es .... que no es la versión 7.0 !!! Como es eso ? Bueno, tiene soporte para muchas funciones, procedimientos almacenados ( que no recomiendo luego vemos porqué ), pero no tiene lo que se ha dado en llamar TRANSACT SQL , característica de la versión 7.0. Sus desventajas son que ya no está a la venta, pero si existe el precio lo justifica. No tiene problemas de Mayúsculas Minusculas en nombres, lo que puede ser una ventaja. Se usa el acceso standard de provider, que puede ser el incluido en Office 97, en VB, o usar las versiones OLEDB. Necesita un servidor dedicado, pero hay que tener acceso a el para modificar los datos a mano, y saber el proceso. Muy robusto, y al igual que la versión 7.0, permite dar accesos al usuario por tabla ( borrar, cambiar, etc )
  • SQL Server 7.0 - Su ventaja real es que hay una versión demo de 120 dias, y una gran característica es que en la instalación hay una versión "Desktop" en el mismo CD, que hace que tener un servidor sea opcional. Otra ventaja es que podemos programar y probar en una sola máquina sin servidor. Tiene un chequeo de nombres completamente funcional, pero configurarlo puede ser un problema. Soporta Triggers, store procedures y otras chunches que no son del standard ANSI SQL, pero si se usan el sistema es menos Portable. Si bien esas chunches son "necesarias" para un desarrollo en capas, a mi parecer se pierde en portabilidad. Si usan este servidor, tengan cuidado al configurar el tamaño de las bases de bitácora o LOG. Me tocó con una aplicación que usaba acceso intensivo, que las tablas necesitaban 10 mb.. y el log de transacciones 260 !!! Porque se cargaban archivos continuamente. En ciertos casos es preferible poner a ceros el Log. A mi parecer es el mas sólido de los productos SQL, si no se usa Transact. Otro problema:. NO RECUPERA SUS PROPIOS RESPALDOS cuando estos son complicados. Mas adelante veremos esto, pero Para Lucent Technologies tuve que hacer un programa especial de respaldo. Al igual que su antecesora, usa los drivers default de Windows y VB. Siempre que me refiera a usar SQL server, me refiero a esta versión SIN USAR TRIGGERS Y STORE PROCEDURES !!!.

    Cita:En el año 2004 la empresa en que laboro compró un sistema de nómina relativamente robusto que necesitaba SQL 7, pero hubieron dos problema bastante desagradables. El primero fue que una tercera empresa, que daba mantenimiento al servidor, instaló Panda antivirus en el servidor SQL, y el sitio de Panda dice claramente que es incompatible con SQL7. De repente nos quedamos sin SQL corporativo, sin manera de hacer respaldos, etc. Pude levantarlo tras dos meses de trabajo con imagenes GHOST y sin reinstalar. El segundo problema fue una falla del disco duro que me obligó a cambiarlo a otro disco del mismo servidor. La falla en este caso fue porque el sistema de nómina validaba muchas cosas por Stored procedures e inicios de sesión. Sin entrar en detalles tuve que hacer circo maroma y teatro para reinstalar la base de datos y restaurar inicios de sesión y derechos de usuario, pero debidas a fallas de diseño del sistema de nómina.
  • MSDE - Esta es una versión limitada del SQL Server 2000 mezclada con Access. Puede ser util si quieren usar el Access 2000 como servidor corporativo. No puedo dar muchos detalles, pero en teoría solo permite cinco usuarios.
  • DBF - Este formato tiene una mirada de desprecio por parte de muchas personas. Pero tiene varias ventajas a favor. Es condenadamente rápido y pequeño. Por ejemplo, supongamos que tenemos un proyecto que usa dos tablas de tamaño mediano, que en total miden 3 mb. En Access 97 estas tablas pueden llegar a formar un MDB de 6 a 10 mb. Tienen el inconveniente que muchos desarrolladores diseñan aplicaciones VB tratando de coexistir con índices de Clipper y esto no es posible; debe desarrollarse de un modo un poco diferente, y preferentemente NO usando motores externos. Otra de sus ventajas es que para aplicaciones en Internet y JAVA ( no confundir con Java script ) Puede usarse directamente. Mi recomendación basica es.. usa los indices de VB, No te compliques con NTX, CDX o indices diferentes. Otra ventaja es que soporta cualquier tipo de acceso, de ODBC a ADO. Un detalle curioso, en una empresa que usaba people soft, tenía que instalar una aplicación VB5-DAO con estas bases, pero el rendimiento era infame. Lo que hice fue, believe it or not ( aunque usted no lo crea ) , cambiarlo a ... VB3 !! Con data control. Menos recursos y mas rapido. Siempre que me refiera a este formato, me refiero al provider "dBase III;"
Algo que para mi es un principio de sentido común y al mismo tiempo RAD, es hacer un diseño que no suponga que el cliente tiene la ultima tecnología. Hace unos meses con algunos negocios usaba un sistema de vb5-Access que mandaba por Internet actualizaciones. Obviamente necesitaba W95, etc etc. Y de repente, se abrieron diez sucursales mas. Lo que hice fue conseguir 10 computadoras 286/386, realizar una versión con VB4 a 16 bits ( windows 3.1 ), conectarlas a Internet.... y el cliente se ahorró 20 mil pesos, y yo me gané 10 mil sin tener que cambiar gran cosa en el programa.

En dic de 2004 todos esos sistemas siguen funcionando... con modems externos y portatiles 286 y 386 en varias sucursales.

En el próximo correo, un ejemplo rápido de esto y como hacer un diseño de datos ( modelo físico ) compatible con lo que sea , y relacional.

------------------------------------------
Alfonso Orozco - Mayo 2001 Actualizado Octubre 2004
02-Apr-2009 08:00 PM
Encuentra todos sus mensajes Cita este mensaje en tu respuesta
Enviar respuesta 


Posibles temas similares...
Tema: Autor Respuestas: Vistas: Último mensaje
  RANTS de Oracle, un manejador de bases de datos admin 5 5,746 13-Apr-2009 01:04 PM
Último mensaje: admin
  Acceso a Datos 07: Principios RAD admin 1 3,305 09-Apr-2009 10:36 AM
Último mensaje: Lux
  Acceso a Datos 16: La esencia de RAD admin 0 3,408 02-Apr-2009 08:01 PM
Último mensaje: admin
  Acceso a Datos 14: RAD Aplicado a diseño de Tablas admin 0 3,767 02-Apr-2009 08:01 PM
Último mensaje: admin

Salto de foro:


Usuario(s) navegando en este tema: 1 invitado(s)

Powered By MyBB, © 2002-2020 MyBB Group. | | Theme Created By effone of Equinox Design