SIMPLE STEPS

Cuando una compañía nos contrata para subir de Access a SQL Server, siempre avisamos al cliente acerca de las fases de programación necesarias para llevar a cabo hasta que están contentos con la velocidad de la solución. Cuánto tiempo invertimos en cada proyecto depende de varios factores, el mayor de los cuales es el presupuesto y las preferencias del cliente.

¿Por qué Access necesita optimización con SQL Server?

Hay varios factores que afectan una actuación rápida:

La base de datos Access está mal diseñada. Si el cliente no quiere invertir en actualizar el diseño en general, estamos forzados a utilizar un diseño pobre complementario en SQL Server. Compensamos mediante la adición de índices y mejoras detrás de las escenas, donde sea posible.

La infraestructura de red es terrible. El otro día le ayudé a un cliente que utiliza un servidor SQL que era demasiado lento. La performance era tan mala que recomendamos descargar datos de la tabla antes de ejecutar informes, de forma de evitar tener que volver al servidor para cada consulta sucesiva.

La velocidad es subjetiva

Lo que puede ser rápido para nuestro personal puede ser inaceptable para nuestro cliente, o viceversa, y puesto como nos pagan por hora, es importante que gastemos el dinero de nuestros clientes con prudencia. Por lo tanto haremos un par de iteraciones de mejoras hasta que estén contentos con el rendimiento de la aplicación. En general nos esforzamos por tiempos de espera de 3 segundos o menos.

Fase 1 – SMA actualizar y optimizar

Durante nuestra primera fase, utilizamos SQL Server Migration Assistant para Access, seguido por utilizar todas las características del programa y arreglar problemas de velocidad que encuentre nuestro personal. Si vamos a crear una aplicación web para la base de datos, hay que pedir al cliente abrir una cuenta en línea y usamos esa cuenta para hacer nuestro desarrollo. Si es una actualización de la red local, nuestros desarrolladores usan un servidor SQL local en su escritorio.

Una vez que hemos completado nuestra primera fase, entregamos los resultados a nuestros clientes y les pedimos evaluar su experiencia con la aplicación mejorada.

Fase 2 – Optimizar el uso de procedimientos almacenados

Podemos migrar procesos en procedimientos almacenados y consolidar las consultas de Access a vistas sobre SQL Server. Crear procedimientos almacenados toma tiempo, por lo que es importante trabajar en estrecha colaboración con el cliente y asegurarse alcanzamos sus expectativas de costo. En ocasiones el cliente puede decidir vivir con el proceso más lento en lugar de invertir en la optimización.

Ronda 3 – ley de rendimientos decrecientes

Si nuestro cliente encuentra todavía parte del sistema demasiado lento, discutimos los próximos pasos generales. Terminamos con migrar más procesos al servidor y continuar desarrollando en SQL Server, sin embargo el retorno de la inversión es logarítmico, tomando más tiempo pero con mínimas mejoras en el rendimiento.

Optimizar toma tiempo y experiencia, y para realmente hacerlo bien, hay que convertirse en un desarrollador de SQL Server además de un gurú de VBA. Una vez que domina ambos mundos, disfrutará tomando en estos proyectos y creando soluciones maravillosas con Access y SQL Server.