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