Estándares y buenas prácticas en SQL Server

Estándares y buenas prácticas en SQL Server

En este módulo aprenderás los principios fundamentales para nombrar, organizar y documentar objetos en SQL Server. Aplicar estas normas mejora la legibilidad del código, reduce errores y facilita el mantenimiento a largo plazo. Cada sección está basada en preguntas típicas de un quiz, acompañada de explicaciones detalladas y ejemplos prácticos.

1. Convenciones de nombres para tablas

Una convención clara y consistente es esencial para que cualquier desarrollador pueda entender la estructura de la base de datos sin ambigüedades.

• Nombre descriptivo en singular y PascalCase: Cada tabla debe llevar un nombre que describa su contenido, usando la primera letra de cada palabra en mayúscula y sin prefijos. Por ejemplo, Cliente, OrdenVenta o ProductoInventario.
• Evita prefijos como tbl_ o lut_. Estos añaden ruido y pueden generar conflictos cuando se integran con herramientas que ya utilizan sus propios prefijos.
• El uso del singular facilita la lectura de sentencias JOIN y mantiene la coherencia con los nombres de columnas que suelen ser también singulares (ClienteId, ProductoId).

Analogía: Piensa en el título de un libro: debe ser claro y estar escrito en CamelCase para que destaque sin necesidad de adornos.

2. Prefijos recomendados para vistas

Las vistas son objetos lógicos que representan consultas guardadas. Un prefijo estándar ayuda a distinguirlas de tablas y procedimientos.

• Utiliza el prefijo vw (por "view"). Ejemplo: vw_ClientesActivos o vw_ResumenVentas.
• Este prefijo es breve, evita colisiones con otros objetos y es ampliamente adoptado en frameworks y guías de estilo.

Analogía: Imagina "vw" como la abreviatura de "vista‑window", una ventana que muestra datos filtrados.

3. Evitar el prefijo sp_ en procedimientos almacenados

SQL Server reserva ciertos prefijos para sus propios procedimientos del sistema. Usar sp_ para objetos propios puede provocar:

• Conflictos de nombres, ya que el motor busca primero los procedimientos del sistema antes que los definidos por el usuario.
• Posibles degradaciones de rendimiento al requerir búsquedas adicionales en el catálogo.
• Dificultades en la gestión de permisos, pues los procedimientos reservados pueden tener privilegios diferentes.

En su lugar, emplea nombres descriptivos sin prefijo o con un prefijo propio, como usp_ (User Stored Procedure) o simplemente ObtenerClientes.

Analogía: "sp_" es una señal de emergencia que el motor interpreta antes que cualquier otra cosa.

4. Uso de nombres de cuatro partes

Referenciar objetos con la forma Servidor.BaseDeDatos.Esquema.Objeto aporta varios beneficios:

• Elimina ambigüedad: El motor no necesita resolver nombres duplicados en diferentes esquemas o bases.
• Mejora el rendimiento: Al especificar el esquema, se evita la búsqueda de resolución de esquema, lo que reduce el tiempo de compilación de la consulta.
• Facilita la migración y el mantenimiento en entornos con múltiples servidores o bases de datos.

Ejemplo práctico:

SELECT *
FROM ServidorProd.BDVentas.dbo.OrdenVenta OV
JOIN ServidorProd.BDVentas.dbo.Cliente C ON OV.ClienteId = C.Id;

Analogía: Es como escribir una dirección completa: calle, número, ciudad y país, evitando confusiones.

5. Propiedades extendidas (Extended Properties)

Documentar directamente en el catálogo del sistema permite almacenar descripciones, notas de auditoría o cualquier metadato útil.

• Se crean con el procedimiento sp_addextendedproperty y se consultan con fn_listextendedproperty.
• Ejemplo de agregar una descripción a una tabla:

  EXEC sp_addextendedproperty 
        @name = N'MS_Description', 
        @value = N'Tabla que almacena la información de los clientes', 
        @level0type = N'SCHEMA', @level0name = N'dbo', 
        @level1type = N'TABLE',  @level1name = N'Cliente';
  

• Estas propiedades son visibles en el Explorador de objetos de SSMS y pueden ser extraídas para generar documentación automática.

Analogía: Es como colocar una etiqueta pegada al archivo, que siempre está disponible para quien lo consulte.

6. Principio de privilegios mínimos

Este principio de seguridad establece que cada usuario o aplicación debe poseer únicamente los permisos estrictamente necesarios para cumplir su función.

• Reduce la superficie de ataque: si una cuenta se ve comprometida, el daño potencial está limitado.
• Facilita auditorías y cumplimiento normativo, pues los permisos son claros y rastreables.
• Implementación típica:
  • Crear roles específicos (p. ej., rol_lectura_ventas).
  • Asignar a cada rol solo los objetos que necesita (SELECT en vistas, EXEC en procedimientos).
  • Agregar usuarios a los roles adecuados.

En resumen, el objetivo es garantizar que usuarios y aplicaciones solo tengan acceso a los datos y operaciones necesarios.

7. Riesgos de omitir el esquema al referenciar tablas

Cuando se escribe SELECT * FROM Cliente sin especificar el esquema, SQL Server asume el esquema por defecto del usuario (usualmente dbo). Esto puede generar:

• Ambigüedad si existen tablas con el mismo nombre en diferentes esquemas.
• Errores de permisos, ya que el usuario podría no tener acceso al esquema implícito.
• Problemas de rendimiento por la necesidad de resolver el esquema en tiempo de ejecución.

La práctica recomendada es siempre incluir el esquema: dbo.Cliente o ventas.Cliente.

Analogía: Es como intentar abrir una puerta sin saber a cuál habitación pertenece; el sistema siempre busca la puerta predeterminada, lo que puede llevar a equivocaciones.

8. Documentación recomendada para bases de datos

Una buena documentación no solo facilita el trabajo del equipo de desarrollo, sino que también cumple con requisitos de auditoría y gobernanza.

• Procedimientos y funciones críticas: describir su propósito, parámetros, y ejemplos de uso.
• Diagramas entidad‑relación (ERD): visualizan la estructura lógica y las relaciones entre tablas.
• Políticas de retención y clasificación de datos: indican cuánto tiempo se conserva la información y su nivel de sensibilidad.
• NO se incluye el código fuente de la aplicación cliente, ya que la documentación se centra en la capa de datos y su gestión.

Utiliza herramientas como Data Dictionary, SQL Doc o scripts de generación automática para mantener la documentación actualizada.

Analogía: Los documentos son procesos + diagramas; el código fuente pertenece a otra capa.

Resumen y mejores prácticas

Aplicar los estándares descritos garantiza una base de datos más organizada, segura y fácil de mantener. A continuación, se presentan las recomendaciones clave en formato de lista para su rápida referencia:

• Nombrar tablas en singular, PascalCase y sin prefijos.
• Usar el prefijo vw para vistas.
• Evitar sp_ en procedimientos; preferir usp_ o nombres descriptivos.
• Referenciar objetos con la notación de cuatro partes cuando sea necesario.
• Agregar Extended Properties para describir objetos directamente en el catálogo.
• Aplicar el principio de privilegios mínimos mediante roles y permisos granulares.
• Siempre especificar el esquema al referenciar tablas para evitar ambigüedades.
• Documentar procesos críticos, ERD y políticas de datos; excluir código cliente.

Implementar estas prácticas no solo mejora la calidad del código, sino que también favorece el SEO interno de los repositorios de documentación, facilitando la búsqueda de información por parte de los equipos de desarrollo y auditoría.