Buenas prácticas de programación

Si trabajamos con tablas hay que tener en cuenta los siguientes criterios:

• Intentar crear la tabla con los campos necesarios y no crear campos en la tabla principal que vayan a tener muchos nulos, es mejor crear otra tabla con los campos adicionales que se van a rellenar de vez en cuando. Usar siempre alias para las tablas y en la selección de columnas.
• Los campos grandes deberían ir también en otra tabla.
• Las tablas deben de tener un índice ordenado siempre, y una clave primaria, normalmente el índice ordenado puede ser la clave, pero no siempre tiene por qué ser así.
• No definir tipos de datos varchar(max) en campos de búsqueda ya que sobre este tipo de datos no se pueden definir índices.
• Hay que definir siempre las claves ajenas.
• Definir índices únicos siempre que sea necesario
• Cuando una tabla tiene muchas búsquedas por el IdDoc deberemos crear un índice sobre este campo.
• Añadir defaults de campos cuando el tipo de campo sea booleano, siempre deberá llevar un default por defecto, los numéricos que vayan a intervenir en cálculos deberán llevar un default, y las fechas también deberían llevarlo, y además en todos estos campos poner que no se aceptan Nulos.
• No debemos usar los tipos de campos text, ntext, image, float, real en las tablas.
• Por incompatibilidad con Visual Basic 6 no se deben usar los campos Date o varchar(max) como salidas de stored procedures.
• En la definición de los índices y en los where siempre lo más restrictivo primero.

Con el resto de objetos intentaremos, vistas, triggers, procedimientos y funciones:

• En las vistas no hacer Select * y poner solo los campos que se necesitan.
• Si hay que usar funciones definidas por el usuario, intentad gastar funciones in-line.
• Evitad los anidamientos en las vistas.
• Filtrad siempre todo lo que se pueda en el FROM antes que en el WHERE, para filtrar los conjuntos de datos lo antes posible.
• Evitar el CROSS APPLY y OUTER APPLY en funciones de tabla no in-line
• Favorecer los EXISTS frente a los IN, <> , Not in, or,… 
• En los triggers, al principio, comprobar siempre: IF EXISTS (SELECT * FROM Inserted) 
• No usar los triggers para procesos de negocio, sino para comprobaciones de integridad de datos que no se puedan realizar por clave ajenas.
• Y tener en cuenta siempre que el inserted y el deleted pueden contener n registros y no solo uno.
• En los procedimientos hay que usar siempre plantillas TRY/CATCH. Y abrir transacción solo si es necesario y lo mas pequeña posible.
• Usar siempre la instrucción sp_executesql y no EXEC.
• Intentar trabajar siempre con conjuntos de datos y no con cursores, esto se aplica a triggers, procedimientos y funciones.
• Si necesitamos verificar si un registro existe en una tabla no usar SELECT COUNT (*) para identificarla ya que es muy ineficiente y utiliza recursos de servidor de forma masiva. En su lugar la sentencia Transact-SQL IF EXISTS 
  
  

<< Artículo anterior