Buenas prácticas de programación

Creado por David Miralpeix, Modificado el Vie, 16 Feb a 12:24 P. M. por David Miralpeix

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                                                                                                                                  

¿Le ha sido útil este artículo?

¡Qué bien!

Gracias por sus comentarios

¡Sentimos mucho no haber sido de ayuda!

Gracias por sus comentarios

¡Háganos saber cómo podemos mejorar este artículo!

Seleccione al menos una de las razones
Se requiere la verificación del CAPTCHA.

Sus comentarios se han enviado

Agradecemos su esfuerzo e intentaremos corregir el artículo