Mejores prcticas SQL Server Nombrado de objetos
Estndar en los nombres
Se debe tener un estndar para nombrar los objetos, no solo a nivel de base de datos sino tambin a nivel de instancia, esto es, que los nombres de las propias bases de datos deben seguir normas especficas que sugieran a simple vista su aplicacin.
Base de datos
Como objeto en la instancia debe tener su propio estndar de codificacin, por ejemplo, en algunas organizaciones utilizar como nombre de base de datos el nombre del aplicativo que la usa, por ejemplo: RegistroClientes, Facturacion, etc. As es fcilmente identificable.
Tablas
Las tablas representan una instancia de una entidad, y DEBE contener solo informacin que corresponde a la entidad que representa (No vamos a guardar la direccin del cliente en la tabla proveedor) as pues el nombre de sta debe ser alusivo a la informacin que contiene, por ejemplo: Proveedores, Clientes. Es a consideracin del DBA o del DBD decidir si se usaran plurales o singulares para nombrar las tablas as tambin como las tablas que contienen informacin de ms de una entidad, por ejemplo: PedidosCliente, tambin puede llamarse: PedidosPorCliente, lo importante es que sea claro y solo con verla podemos saber qu entidad representa y por ende la informacin que contiene.
Consideraciones
Prefijos como: tblClientes no aportan nada al nombre. Si tenemos alguna especie de lgica especial o compleja y necesitamos ver agrupados un grupo de tablas (En el SQL Server Managment, al expandir las tablas) podemos usar prefijos indicando el grupo al cual pertenece, ejemplo: Tenemos dos tablas que pueden tener el mismo nombre, pero pertenecen a distintos procesos podemos hacer lo siguiente: RH_Cliente y V_Cliente, pertenecientes a Recursos humanos y ventas, o mejor an la solucin para esto es usar esquemas.
Vistas
Las vistas no son ms que tablas filtradas, por lo tanto la informacin que presentan est definida en su mbito y lmites, lo cual nos ayuda a nombrarlas. Por lo que nombrar las vistas en mi opinin debe ser en funcin de la consulta ms que en las entidades, por ejemplo: ResumenVentas2011, ClientesFrecuentes, son perfectamente entendibles.
Consideraciones
Nombrar vistas en base a las tablas que consulta tambin puede ser til pero no siempre funcional, por ejemplo: si en una vista combinamos Clientes y Direcciones la vista se llamara DireccionesClientes, pero si existe ya una tabla con ese nombre?.
Procedimientos almacenados
Los procedimientos almacenados siempre tiene una tarea especfica y en base a ste los debemos nombrar, por ejemplo: ObtenerDetalleClientes, sin embargo personalmente no me gusta esta aproximacin ya que a nivel visual (En SQL Server Managment Studio al expandir Procedimientos almacenados) estarn juntos todos los que comienzan por obtiene lo cual no tiene mucho sentido, prefiero que el SP comience por el nombre de la entidad a la que est afectando, por ejemplo: ClientesObtenerDetalle, asi en el Managment estarn todos juntos los procedimientos de Clientes. Si el procedimiento afecta ms de una tabla no debe afectar su nombre, es decir debe ir en funcin de el proceso, por ejemplo: FacturaInsertar seguramente ingresa su encabezado y detalle y si los tenemos separados pues deberan ser: FaturaEncabezadoInsertar y FaturaDetalleInsertar.
Consideraciones
NUNCA colocar como prefijo a los procedimientos sp_, sta es una prctica bastante difundida que no est para nada bien, (a menos que sea un procedimiento que se guarde en la BD master), la razn es que SQL Server coloca este prefijo a los procedimientos del sistema (No te habas dado cuenta?), por tanto si le dices que ejecute un procedimiento con prefijo SP, primero lo buscara en master. Funciones de usuario En cierto sentido una funcin de usuario es un procedimiento almacenado, claro que con ciertas caractersticas, debemos nombrar el UDF de acuerdo a su funcionalidad, como stos no van dirigidos a una tabla en especfica pueden nombrarse de acuerdo a lo que hacen, por ejemplo: CalcularDigitoVerificacion.
Triggers
Los triggers tambin son un tipo especial de procedimiento almacenado, para nombrarlo sugiero tener en cuenta que: un trigger no puede existir por s solo, es decir, debe estar asociado a una tabla, por tanto tiene mucho sentido colocar en el nombre la tabla a la cual pertenece. Ademas de esto los triggers tambin estn asociados a una operacin sobre la tabla (SELECT, DELETE, UPDATE, INSERT), asi que tambin tiene sentido colocar esta informacin en el nombre, por ejemplo: ClientesInsertTrigger.
ndices
En este apartado en lo que a m respecta, prefiero dejar que sea el SSMS quien me sugiera el nombre, sin embargo, como regla general podemos tener en cuenta lo siguiente: el nombre del ndice debe comenzar con un prefijo que indique el tipo de ndice, nombre de la tabla en donde se creara, columna y si lo desean informacin adicional, por ejemplo: PK_Clientes_ClienteID_ASC. En el caso especial de las forneas que referencian dos tablas podemos usar la siguiente norma: FK_+TablaQueReferencia+ColumnaQueReferencia_+TablaReferenciada+ColumnaReferenciada.
Columnas
Realmente en este apartado lo que hay que decir es que debemos nombrar las columnas con sentido comn y de acuerdo con la informacin que se est guardando, ya es decisin de uds. Si por ejemplo a la columna ID de la tabla clientes le colocan: ClienteID o ID, Si se usa la primera forma, todos los nombres de columnas de la tabla deben ser precedidos por el mismo, es decir, en la tabla clientes: ClienteID, ClienteNombre, ClienteDireccion. Por qu? As cuando se est en una consulta compleja, como por ejemplo con un JOIN no habr conflicto de ambigedad con nombres. Tipos de datos definidos por el usuario Realmente son columnas con tipo de datos especiales por as decirlo, por tanto creo que usando el estndar de columnas estar bien.
Mejores prcticas SQL Server Nombrado de objetos
Introduccin
En el mundo del desarrollo de habla mucho acerca de buenas prcticas, patrones de diseo y una cantidad de vocabulario como patrones, diseos, etc. Y aunque el desarrollo a nivel de base de datos en muchos casos no exige una arquitectura es importante tener en cuenta ciertos parmetros a la hora de crear procedimientos almacenados. Las bases de datos si lo pensamos con detenimiento son el corazn de la aplicacin en muchos sentidos, y por tanto es extremadamente importante para DBAa y DBDs crear objetos que tengan siempre un ptimo desempeo para evitar cuellos de botella en la aplicacin. He aqu algunas prcticas que he recopilado, algunas por la red otras por experiencia:
Estndar en los nombres
Se debe tener un estndar para nombrar los objetos, no solo a nivel de base de datos sino tambin a nivel de instancia, esto es, que los nombres de las propias bases de datos deben
seguir normas especficas que sugieran a simple vista su aplicacin. Veamos algunos estndares para los objetos de la base de datos:
Base de datos
Como objeto en la instancia debe tener su propio estndar de codificacin, por ejemplo, en algunas organizaciones utilizar como nombre de base de datos el nombre del aplicativo que la usa, por ejemplo: RegistroClientes, Facturacion, etc. As es fcilmente identificable.
Tablas
Las tablas representan una instancia de una entidad, y DEBE contener solo informacin que corresponde a la entidad que representa (No vamos a guardar la direccin del cliente en la tabla proveedor) as pues el nombre de sta debe ser alusivo a la informacin que contiene, por ejemplo: Proveedores, Clientes. Es a consideracin del DBA o del DBD decidir si se usaran plurales o singulares para nombrar las tablas as tambin como las tablas que contienen informacin de ms de una entidad, por ejemplo: PedidosCliente, tambin puede llamarse: PedidosPorCliente, lo importante es que sea claro y solo con verla podemos saber qu entidad representa y por ende la informacin que contiene.
Consideraciones
Prefijos como: tblClientes no aportan nada al nombre. Si tenemos alguna especie de lgica especial o compleja y necesitamos ver agrupados un grupo de tablas (En el SQL Server Managment, al expandir las tablas) podemos usar prefijos indicando el grupo al cual pertenece, ejemplo: Tenemos dos tablas que pueden tener el mismo nombre, pero pertenecen a distintos procesos podemos hacer lo siguiente: RH_Cliente y V_Cliente, pertenecientes a Recursos humanos y ventas, o mejor an la solucin para esto es usar esquemas.
Vistas
Las vistas no son ms que tablas filtradas, por lo tanto la informacin que presentan est definida en su mbito y lmites, lo cual nos ayuda a nombrarlas. Por lo que nombrar las vistas en mi opinin debe ser en funcin de la consulta ms que en las entidades, por ejemplo: ResumenVentas2011, ClientesFrecuentes, son perfectamente entendibles.
Consideraciones
Nombrar vistas en base a las tablas que consulta tambin puede ser til pero no siempre funcional, por ejemplo: si en una vista combinamos Clientes y Direcciones la vista se llamara DireccionesClientes, pero si existe ya una tabla con ese nombre?.
Procedimientos almacenados
Los procedimientos almacenados siempre tiene una tarea especfica y en base a ste los debemos nombrar, por ejemplo: ObtenerDetalleClientes, sin embargo personalmente no me gusta esta aproximacin ya que a nivel visual (En SQL Server Managment Studio al expandir Procedimientos almacenados) estarn juntos todos los que comienzan por obtiene lo cual no tiene mucho sentido, prefiero que el SP comience por el nombre de la entidad a la que est afectando, por ejemplo: ClientesObtenerDetalle, asi en el Managment estarn todos juntos los procedimientos de Clientes. Si el procedimiento afecta ms de una tabla no debe afectar su nombre, es decir debe ir en funcin de el proceso, por ejemplo: FacturaInsertar seguramente ingresa su encabezado y detalle y si los tenemos separados pues deberan ser: FaturaEncabezadoInsertar y FaturaDetalleInsertar.
Consideraciones
NUNCA colocar como prefijo a los procedimientos sp_, sta es una prctica bastante difundida que no est para nada bien, (a menos que sea un procedimiento que se guarde en la BD master), la razn es que SQL Server coloca este prefijo a los procedimientos del sistema (No te habas dado cuenta?), por tanto si le dices que ejecute un procedimiento con prefijo SP, primero lo buscara en master. Funciones de usuario En cierto sentido una funcin de usuario es un procedimiento almacenado, claro que con ciertas caractersticas, debemos nombrar el UDF de acuerdo a su funcionalidad, como stos no van dirigidos a una tabla en especfica pueden nombrarse de acuerdo a lo que hacen, por ejemplo: CalcularDigitoVerificacion.
Triggers
Los triggers tambin son un tipo especial de procedimiento almacenado, para nombrarlo sugiero tener en cuenta que: un trigger no puede existir por s solo, es decir, debe estar asociado a una tabla, por tanto tiene mucho sentido colocar en el nombre la tabla a la cual pertenece. Ademas de esto los triggers tambin estn asociados a una operacin sobre la tabla (SELECT, DELETE, UPDATE, INSERT), asi que tambin tiene sentido colocar esta informacin en el nombre, por ejemplo: ClientesInsertTrigger.
ndices
En este apartado en lo que a m respecta, prefiero dejar que sea el SSMS quien me sugiera el nombre, sin embargo, como regla general podemos tener en cuenta lo siguiente: el nombre del ndice debe comenzar con un prefijo que indique el tipo de ndice, nombre de la tabla en donde se creara, columna y si lo desean informacin adicional, por ejemplo: PK_Clientes_ClienteID_ASC. En el caso especial de las forneas que referencian dos tablas podemos usar la siguiente norma: FK_+TablaQueReferencia+ColumnaQueReferencia_+TablaReferenciada+ColumnaReferenciada.
Columnas
Realmente en este apartado lo que hay que decir es que debemos nombrar las columnas con sentido comn y de acuerdo con la informacin que se est guardando, ya es decisin de uds. Si por ejemplo a la columna ID de la tabla clientes le colocan: ClienteID o ID, Si se usa la primera forma, todos los nombres de columnas de la tabla deben ser precedidos por el mismo, es decir, en la tabla clientes: ClienteID, ClienteNombre, ClienteDireccion. Por qu? As cuando se est en una consulta compleja, como por ejemplo con un JOIN no habr conflicto de ambigedad con nombres. Tipos de datos definidos por el usuario Realmente son columnas con tipo de datos especiales por as decirlo, por tanto creo que usando el estndar de columnas estar bien.
Consideraciones adicionales
y y
Entre ms simple, mejor. No usar palabras reservadas para nombrar objetos de la base de datos (Por ejemplo nombrar a una columna password), y en caso de hacerlo se pueden usar los corchetes ([]) para denotar la palabra. No usar espacios para separa palabras en el nombre de los objetos de la base de datos, es preferible usar notacin CamelCase. Usar underscore solo en el caso en que el objeto tenga un prefijo o sufijo, para separar las palabras usar la regla anterior.
y y