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
Leer más

Expresiones, parámetros y funciones en Azure Data Factory

Hay ocasiones, cuando estamos construyendo pipelines con Azure Data Factory, que queremos repetir patrones para extraer y procesar la información cambiando de manera dinámica, en tiempo de ejecución, valores, orígenes/destinos de los datasets, incluso los mismos linked services. Esto es posible mediante el uso de parámetros, expresiones y funciones. Vamos a ver cómo implementarlo con un ejemplo práctico en el que se nos plantea el siguiente supuesto. Se nos ha pedido que extraigamos todos los días los datos del día anterior de distintas tablas del DW a ficheros en un blob storage que además se nombre como la tabla de origen. Si no pudiéramos utilizar contenido dinámico tendríamos que crear dos datasets (uno de origen y otro de destino) y añadir una actividad de copia por cada tabla a exportar.