database

Siempre es buen momento para planificar mejoras. Siempre es bueno revisar cómo podemos abaratar nuestros costes de desarrollo en la nube. Los tiempos de respuesta de procesos contra bases de datos (BBDD) de Microsoft SQL Server en Azure, a medida que va creciendo el volumen de nuestros datos se deteriora irremediablemente.

Por tanto, debemos anticiparnos mejorando nuestra infraestructura y nuestra manera de actuar con ellas. Todo siempre es susceptible de mejorar sin necesidad de ir contratando mayores y más caros niveles de servicio cuando, a lo mejor, todavía no es necesario.

Buenas prácticas en programación contra bases de datos relacionales y ahorro en costes

Refactorizando cierto código muy concreto, ya en producción, y comenzando a aplicar Buenas Prácticas a la hora de desarrollar contra SQL Server, buscamos mejorar nuestra capacidad de gestión para aumentar el rendimiento actual. También es necesario prevenir cuellos de botella y anticiparnos a problemas que puedan llevarnos posteriormente a grandes costes de desarrollo y recursos.

Aplicando Buenas Prácticas también podremos disminuir los tiempos de desarrollo de los programadores. El código, llegará a ser más eficiente y entre los distintos programadores se podrá reutilizar, comprender y mejorar, ya que ciertas decisiones se podrán implementar de forma normalizada y facilitarán la labor de equipo. La tarea de un desarrollador que necesite mantener el código creado por otra persona será más sencilla.

El rendimiento de un sistema de base de datos depende de múltiples factores, y es difícil garantizar que las mejoras reales en el rendimiento coincidirán con las predicciones. La optimización es, principalmente, un trabajo artesanal que debe abarcar todo el sistema, pero las mejoras más radicales se suelen encontrar solucionando y refactorizando código poco eficiente contra la BD.

No es fácil para nadie construir inicialmente un esquema de BD y un código a prueba de futuro. Cuando comenzamos nuestro negocio, los requisitos son muy diferentes a cuando llevamos muchos años explotándolo. El éxito de la empresa también trae expansión en diferentes geografías y un crecimiento del volumen de datos. Esto implica que se puedan volver permanentes algunas de las soluciones que se necesitan crear de forma transitoria y urgente, así como mucho “código personalizado” para la ocasión.

Hay numerosas razones para una codificación deficiente y la mayoría de las veces se debe a que el desarrollador que está escribiendo el código no está 100 % familiarizado con el esquema de BD o con las nuevas características de Transact-SQL. En cualquier caso, conocer bien el modelo de datos solamente puede traernos enormes bondades y ventajas. Así pues, dominar nuestro modelo de BD debe ser nuestra primera y obligatoria buena práctica.

Hay muchas más malas prácticas de diseño de esquemas de BD, sin embargo, casi siempre las encontramos exclusivamente después de que nuestro negocio haya tenido éxito. Y entonces, después de cierto tiempo, ya es difícil cambiar dicho esquema. Por tanto, no se deben tomar nunca decisiones sobre el modelo de datos a la ligera.

Al recopilar información sobre una aplicación y cómo se utiliza, podemos tomar decisiones de arquitectura inteligente que harán que nuestra base de datos sea más escalable y funcione mejor con el tiempo. El resultado será un mayor rendimiento y una menor pérdida de tiempo resolviendo problemas a posteriori.

En artículos posteriores, continuaremos hablando de las grandes ventajas de aplicar las Buenas Prácticas que estamos implantando ya en TELDAT para nuestros desarrollos contra BBDD SQL Server en la nube.


Sobre el autor

Fernando Tomas Rodriguez
Fernando Tomas Rodriguez
Ingeniero Técnico en Informática de Sistemas en el departamento de I+D de Teldat. Dentro de dicho departamento trabaja en el grupo de Infraestructura como especialista en Bases de Datos.

Comparte este post


Nuestras Soluciones Relevantes