Convenciones para Stored Procedures
Como toda la lógica de negocio vive en SQL Server (ver Database-Centric), la calidad y consistencia de los Stored Procedures importa tanto como la del código de aplicación en cualquier otro proyecto.
Nomenclatura
Prefijo sp_ + verbo en español + sustantivo, en PascalCase:
sp_AprovisionarBaseDatos
sp_AprovisionarBaseDatosSocio
sp_RotarPasswordBaseDatosSocio
sp_ListarBasesDatosSocio
sp_RotarClaveCifrado
sp_AltaCelulaSocia
sp_ValidarApiKeyCelula
sp_VerificarOInicializarClaveCifrado
El verbo describe la acción de negocio, no la operación SQL subyacente — sp_AprovisionarBaseDatos
en vez de sp_InsertBaseDatos, porque "aprovisionar" es lo que el sistema hace conceptualmente
(reservar el registro, generar credenciales, y coordinar el aprovisionamiento real), no una simple
inserción de fila.
Scripts numerados, orden estricto
Cada script en sql/ se ejecuta una sola vez, en orden numérico, y cada uno puede depender de
esquema o Stored Procedures creados por los anteriores. El primero define el esquema base; los
siguientes van agregando cada módulo funcional a medida que se incorporó al proyecto (triggers de
seguridad, perfil de usuario, API keys, DNS autoservicio, sesiones, células socias). Correr un
script fuera de orden falla por dependencias faltantes, no silenciosamente.
Qué vive en un SP y qué no
| Vive en el SP | Vive en el backend |
|---|---|
| Validar reglas de negocio (cuotas, duplicados, estados válidos) | Validar la forma del request (tipos, campos requeridos) |
| Generar valores (nombres únicos, contraseñas) | Autenticar al usuario / validar API key |
| Decidir permisos y transiciones de estado | Aplicar rate limiting |
| Escribir auditoría | Invocar el SP y mapear el resultado a HTTP |
Nunca SQL concatenado
Todo Stored Procedure se invoca con parámetros tipados — nunca se arma una sentencia SQL concatenando strings desde el backend. Esto no es una convención de estilo: es lo que hace que la inyección SQL sea estructuralmente imposible en este proyecto, no algo que dependa de que cada desarrollador recuerde sanitizar cada input.
Transacciones que no dejan estados a medias
Un patrón recurrente en los SPs más sensibles (por ejemplo, la rotación de la clave de cifrado) es envolver toda la operación en una única transacción: si falla a mitad de camino, se revierte por completo — nunca queda una fila parcialmente actualizada o un estado inconsistente entre tablas relacionadas. Ver Cifrado y Claves para un ejemplo concreto de este patrón.