Con la intención de hacer más frecuentes mis posteos voy a empezar a copia aquí respuestas a las preguntas que algunos amigos y clientes me hacen por correo. Algunos nombres han sido cambiados para proteger la identidad de los inocentesJ.

Estimado Javier:
¿Es conveniente marcar la columna PERSISTED y definir un índice sobre esta?, Si no es recomendado que la columna sea PERSISTED=yes, ¿La columna puede estar definida de esa forma sin el índice?

DERNORMALIZADOR COMPULSIVO

Estimado DERNORMALIZADOR:

Como dice la canción de Jarabe de Palo: Depende. … ¿De qué depende? … Del cristal con que se mire todo depende…
Una columna calculada, convierte a una tabla en una mezcla de vista y tabla. En mi opinión, que no comparten todos los DBAs, es una excelente forma de des-normalizar. Esto es de poner una columna que depende de las otras columnas de la tabla, y al mismo tiempo garantizar que los datos son consistentes. Antes para hacer esto había que usar una vista independiente, ahora la misma tabla puede hacerlo. Esto es diseño lógico de la Base de Datos y se hace para facilitar el trabajo de desarrollador.
En la parte de diseño físico, tenemos 3 opciones:
1) Dejarla como calculada únicamente: esta suele ser la mejor opción casi siempre. En este caso el servidor cada vez que se consulta la tabla vuelve a calcular el valor. En contra de lo que la mayoría de los desarrolladores piensan esto suele ser más rápido que almacenar la columna, y la razón es simple: los discos duros son lentos, y el CPU y memoria rápidos. Para el servidor multiplicar 2 columnas suele ser más rápido que leer el cálculo previamente almacenado en el disco, esto sin contar con que adicionalmente se evita el costo de INSERT y UPDATE.
2) Ponerla como PERSISTED: Cuando los cálculos son pesados (complejos, ejemplo los que se basan en XML, u otros) y la columna no se actualiza con frecuencia, PERSISTED puede ayudar al desempeño. PERSISTED lo único que nos indica es que la columna se materializa en la tabla, esto es que en el momento de hacer INSERT u UPDATE se calcula y se almacena el valor, luego cuando se consulta se usa. Esto es nuevo en SQL 2005, antes de esto para persistir o materializar una columna había que crear un índice.
3) Se puede indizar: Esta es independiente de la opción de PERSISTED. Una columna indizada puede ayudar los SELECT cuando se usan con frecuencia en WHERE o en JOINs y lo más importante cuando sea SELECTIVA.

En SQL 2005 y SQL 2008 puede ser parte de la llave o solo incluirse a nivel de detalle usando el INCLUDE.

Saludos….

 

0 Shares:
Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

You May Also Like
SQL Server en Kubernetes (Parte 2)
Leer más

Matar al mensajero – SQL Server en Kubernetes (Parte 2)

En la primera parte de este artículo explicamos en qué consiste un SQL Server en contenedores y mostramos una forma sencilla de crear un entorno Kubernetes manejado. En esta segunda parte vamos a enfocarnos en los escenarios más críticos donde el uso de contenedores puede añadirnos latencias y esperas extras que acaben impactando en el rendimiento percibido por nuestros usuarios tras una migración de SQL Server a contenedores.

UNPIVOT “SINCRONO”

Más de una vez nos hemos encontrado en la situación de tener que unpivotar una tabla, teniendo así que recurrir o bien al componente “Unpivot” de SSIS o incluso a tener que guardar los datos en tabla y realizar posteriormente una lectura de esta misma utilizando T-SQL para unpivotarla, con los problemas que ambas soluciones nos puedan conllevar con un gran volumen de datos.