MCTS 70-433: SQL Server 2008 – Manejo de tablas y vistas

http://sergiot2.com/blogimages/2008/09Sep/05_Ladrillos.jpg

Aunque ahora con las herramientas de consultas, como SQL Server Management, se puede hacer cualquier operación con la base de datos, en distintos escenarios vamos a necesitar hacer estas operaciones por queries. Por ejemplo cuando estamos actualizando una versión de base de datos, a de desarrollo a pruebas, o a producción, el modo de hacer un backup y restaurarlo en el otro servidor puede servir al inicio, pero ¿y si la base de datos del otro servidor ya tiene data ingresada? existen varias estrategias para hacer esto, pero la más útil y recomendable por el trabajo que le dado ahora, ha sido generar un archivo actualización con los queries de Update, puede surgir problemas si te olvidas de poner algún query pero ese es otro tema.

Empecemos con el tema…

Tenemos muchas opciones para crear y modificar tablas, usando CREATE TABLE y ALTER TABLE. Al crear una tabla nosotros podemos crear columnas calculadas, que son columnas virtuales ya que no son almacenadas físicamente en las tablas, y si queremos almacenarlas físicamente debemos usar el keyword PERSISTED: Computed Columns. Con SQL Server 2005 se introdujo el concepto de Schemas, que entre una de las funciones principales permite categorizar y agrupar los permisos dentro de una base de datos, en este artículo se explica la necesidad de la creación de Schema en versiones anteriores: Understanding the Difference between Owners and Schemas in SQL Server, ver también CREATE SCHEMA. Recordar que la seguridad es importante siempre, y no después que hemos sido atacados, y siempre tener claro el concepto: “mínimos privilegios”, es decir, si una base de datos tiene distintas aplicaciones que trabajan con ella, y por ejemplo hay una aplicación Web que trabaja con 6 tablas (dentro de un Schema propio), se debería tener un usuario sólo con el permiso a este grupo de tablas, es más si para todas tus modificaciones (CRUD) usas procedimientos almacenados, no deberías permitirle al usuario poder hacer INSERT, UPDATE, o DELETE directamente contra este grupo de tablas, sólo darle permiso de ejecución de los store procedures (CRUD), para modificar los permisos podemos usar GRANT, DENY, REVOKE.

Sobre las Vistas (Views) recuerdo que una mini-charla de rendimiento hace años, recomendaron no usarlas, y bueno hasta ahora no he necesitado hacer uso de las mismas. En este artículo podemos entender las vistas, y en este otro podemos ver que podemos hacer y que no, con las vistas: Diseñando e implementando Vistas. Hay algunas opciones al momento de crear vistas (CREATE VIEW), ENCRYPTION para cifrar el registro en sys.syscomments que contiene la consulta de la creación de la vista, CHECK OPTION y SCHEMABINDING, para mantener la consistencia cuando se van a modificar los datos en una vista.

El tema de índices, debería tener una o varias entradas sólo para hablar de ello. Y el tema de índices no muchas veces se entiende en el primer review, charla, u otra fuente de información, sobre todo si no esta bien explicados, pero si debemos saber que el buen uso de Indexes va a mejorar el rendimiento de los queries y aplicaciones que usen nuestra base de datos, debido a que los índices pueden reducir la cantidad de data que se debe leer para devolver un conjunto de registros. Una tabla o vista puede contener índices clustered, y nonclustered, además existen otras opciones en los tipos de índices disponibles en SQL Server: Filtered Index, Index with Included Columns, Unique Index, entre otros. Dentro de las opciones para optimizar índices, se encuentra el uso de la opción Fill Factor. Cada vez que se ejecuta un query el componente Query Optimizer, es el encargado de determinar la manera más eficiente de ejecutar un query, basado en los famosos planes de ejecución, es bueno conocer como el Query Optimizer, genera las estadísticas para escoger el plan de ejecución más eficiente, nosotros podemos crear estadísticas (CREATE STATISTICS) de las columnas y su comportamiento con los índices, para más información revisar el siguiente artículo: Statistics Used by the Query Optimizer in Microsoft SQL Server 2005. Con respecto al tema indexed views, revisar el siguiente artículo: Improving Performance with SQL Server 2005 Indexed Views.

Si ya pasaron el tema de índices, los constraints son más sencillos, son usados para forzar la integridad de la data, y si revisaron el tema de CREATE TABLE y ALTER TABLE los deben haber visto: PRIMARY KEY (revisar IDENTITY_INSERT para insertar valores predeterminados a un columna Identity), FOREIGN KEY (revisar las opciones de actualización de información), UNIQUE, CHECK.

Los tipos de datos estructurados, son los que veníamos usando desde las primeras versiones de SQL, con SQL Server 2005 se contaba con datos semi-estructurados (Xml). Ahora con SQL Server 2008 tenemos el tipo de datos espacial, y el tipo FileStream, y respecto a estos últimos hay mucha información en los blogs, e internet en general.

Partición de tablas e índices, siempre lo distribuido (cuando se hace bien) tiende a llevar a una alta disponibilidad y escalabilidad. La partición de tablas e índices, permite que la data sea dividida horizontalmente y puede ser colocada en más de un filegroup. Recordar que la partición de tablas e índices sólo esta disponible en las versiones SQL Server Enterprise y SQL Server Developer Edition. Antes de particionar las tablas o índices, debemos crear los siguientes objetos: Partition Function, para especificar como la tabla o los índices serán particionados y Partition Scheme mapea las particiones producidas por una Partition Function para asignarlas a los filefroups definidos. Existen tres diferentes tipos de operaciones con particiones: MERGE, SPLIT, y SWITCH. Por cierto también podemos hacer partición de las vistas.

P.D.: Algunas de las mejoras del SQL Server Management Studio (2008), es el IntellSense para algunos keywords y algunos objetos (todavía no tengo claro el patrón), y algo que se pedía a gritos el agrupamiento de un bloque de código en los queries, ósea como si usaras las llaves de C# y puedes comprimir las líneas visibles de código, para la otra versión espero el #region…#endregion :D.

Saludos,

9 comentarios en “MCTS 70-433: SQL Server 2008 – Manejo de tablas y vistas”

  1. JC’s, que bueno que te haya gustado, quiere decir que no esta tan malo :D.

    Se pudo citar muchas otras fuentes, pero en MSDN esta completo, y se pudo hablar mucho más de cada tema, pero la idea era tener una rápida referencia de los temas necesarios para el examen.

    Saludos,

  2. Sergio:

    Quisiera aclarar muchos puntos:

    1.- con la herramienta SSMS no se puede realizar cualquier operaciòn contra la base de datos, sòlo una parte.
    2.- Las operaciones no se hacen CON LA base de datos, sino CONTRA la base de datos.
    3.- Las vistas si se recomienda para seccionar la data que se necesite, mejora la performance, tambièn se puede particionar. Sim embargo no se debe abusar de su uso, pues complicaria la administraciòn.
    4.- El concepto de schemas no se introduce en SQL Server 2005, sino ya viene desde SQL Server 2000, la diferencia es la forma como se trabajaba, etc.
    5.- El optimizador de consultas NO GENERA las estadìsticas, SINO solamente las usa.
    6.- etc.

    Saludos, espero sirva.

  3. Gracias por las acotaciones Percy. Para ser una entrada de referencia a los temas de estudio, va quedando más completa.

    Y en cuanto a la Vistas, tengo algunas preguntas para que quede claro para todos. Mejora el rendimiento en todos los modelos de datos?, es decir si tengo problemas de performance debo usar Vistas?, o hay cierto escenarios donde se pueden aplicar mejor, ¿cuál es la característica de estos escenarios? Y para terminar, ¿el único costo de usar vistas es “complejidad en la administración”?

    Saludos,

  4. Sergio:

    En realidad cualquier implementación de vistas que realices mejorará la performance. En general, siempre recomiendo indexar las vistas, SIEMPRE. Por qué?, por la sencilla razón que una vista indexada ya no es resuelta en el momento que la consultes, ya no estará como tabla virtual, sino que estará lista y almacenada en disco. Ahora me dirás, pero hay un costo de disco?, claro, pero el disco es barato, y ganarás un adicional en performance. Ese es el escenario donde las vistas mejora la performance, cuando se indexa y tenga sentido su uso, donde uses filtros tanto para filas y columnas.

    Las vistas nacieron principalmente por cuestiones seguridad, sólo dar acceso limitado a la data, como un tabla virtual. Luego la cuestión empezó apestar cuando se abusaba de su uso indiscriminado. Por ejemplo, yo he tenido que liar con problemas de performance causados por demasiados niveles de anidamiento de vistas, una vista dentro de otra, sin indexar, más de 10 niveles de anidamiento, y donde mucho de ellas eran simples SELECT * FROM Tabla1, y una que otra tenía filtraba con WHERE. El uso de vista en escenario no tiene sentido, aunque parezca increible, he visto peores tipos de implementaciones, empresas desperadas por problemas de performance donde una de las principales las implementaciones de vista lleno de malas prácticas, pobres trabajos de indexamiento de la data, malas configuraciones de servidor, queryies mal escritos, etc-.

    Usa vistas en modelos de datos OLAP, ganarás tremenda performance. También puedes usar en modelos OLTP donde se realice más lecturas que escrituras, donde no exista alta frecuencia de inserciones, actualizaciones y eliminación de data, pues al estar un vista indexada, tendrán que actualizarse estas, y será allí donde no le sacarás mucho provecho a las vistas. Evalua la frecuencia de actualización de la data que quieres acceder a traves de vistas indexadas. Existe otro costo a partir de la complejidad de la administración al usar muchos niveles de anidamiento, como por ejemplo: Cuando se realiza tuning en procesos donde participan vistas, tomará más tiempo en analizar, más tiempo lleva a más presupuesto, más dinero. El proceso de tuning performance se vuelve más complejo.

    En conclusión: el uso de vista mejora la performance :).

    Espero sirva.

    Saludos,

Deja un comentario

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