El otro día me encontré con un artículo que vino a confirmar una sensación que tengo desde hace tiempo sobre el cometido de un DBA. Normalmente cuando se nombra el término “DBA”, se piensa en una persona que se encarga de analizar el rendimiento del servidor de base de datos con herramientas como el monitor de rendimiento, o consultando objetos de sistema (vistas, DMV, procedimientos almacenados, etc.). Tareas como replicación entre base de datos, log shipping, backups, creación de logins… son operaciones que sabemos que tiene que hacer esta persona.

En un entorno pequeño, esta persona se puede encargar además de “guiar” a los desarrolladores (o al jefe de proyecto) para que hagan las cosas del modo en que un experto en la materia (en este caso SQL Server) puede llegar a hacer. Sin embargo, en la mayoría de las empresas, el número de servidores hace que el trabajo del día a día impida realizar este otro tipo de operaciones, tanto o más importantes que las otras (incluso he conocidos algunos DBA que consideran estas tareas como degradantes). Esto supone en muchos casos que el DBA se termina encontrando con el problema directamente en el servidor de producción, ya que nadie ha validado que el proceso cumpla con unos requisitos de eficiencia mínimos: en unos casos porque el desarrollador no tiene los conocimientos suficientes (sí, sabe crear procedimientos almacenados, pero poco más) o el jefe de proyecto considera que lo principal de su trabajo consiste en que el modelo de clases que ha pensado quede bien reflejado, dando menor importancia a todo lo relacionado con la base de datos. En definitiva, por diversas circunstancias, el problema al final está ahí, y normalmente aparece en el peor momento.

Por eso hace tiempo empecé a pensar en que realmente deberían existir varios DBA o, mejor dicho, varios perfiles de DBA: uno de ellos se debería dedicar más a tareas relacionadas con los servidores de producción, encargándose de que ese entorno ofrezca el servicio que se presupone; pero otro de ellos debería encargarse de que las operaciones que se realizan en los entornos menos “conflictivos” cumplan con unos criterios de calidad mínimos, aconsejando en todo lo relacionado con el diseño de la base de datos (tablas, índices, funciones, procedimientos, etc.). De este modo el rendimiento vendría avalado por un experto en la materia, que tendría el mismo punto de vista que la persona que se encarga del entorno de producción, consiguiendo de ese modo, además, que los posibles problemas que puedan surgir se resuelvan mucho antes.

El artículo al que hacía referencia define muy bien el objetivo en el que deben centrarse estas dos figuras: el DBA (tal y como lo entendemos hasta ahora) debe centrarse en SQL Server como instancia, mientras que esta nueva figura debe centrarse en las bases de datos que alberga cada instancia de SQL Server.

¿Tú qué opinas? ¿Consideras que esta figura debería estar en todas las empresas? ¿Crees tal vez que el nivel de conocimientos de un desarrollador debe ser mayor en todo lo referente a las bases de datos? ¿Piensas que es el jefe de proyecto el que debe garantizar el rendimiento óptimo en base de datos?

0 Shares:
Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

You May Also Like