2. Agenda:
A.- Diseño y Arquitectura de Base de Datos en SQL Server
B.- Manejo de Consultas e índices en SQL Server

3. Temas:
1. Formateo y Alineamiento de Disco.
2. Diseño de la Base de datos Tempdb.
3. Diseño de Base de Datos.
A.- Diseño y Arquitectura de Base de
Datos en SQL Server
Mejores Prácticas con Transact SQL

4. Temas:
1. Formateo y Alineamiento de Disco.
2. Diseño de la Base de datos Tempdb.
3. Diseño de Base de Datos.
A.- Diseño y Arquitectura de Base de
Datos en SQL Server
Mejores Prácticas con Transact SQL

5. 1.1. Definición
Formato y Alineamiento de Disco
La página es la unidad básica del almacenamiento de datos en SQL
Server. El espacio en disco asignado a un archivo de datos (.mdf o
.ndf) de una base de datos, se divide lógicamente en páginas
numeradas de forma contigua de 0 a n. Las operaciones de E/S de
disco se realizan a nivel de página. Es decir, SQL Server lee o escribe
páginas de datos enteras. El tamaño de página es de 8 KB. Esto
significa que las bases de datos de SQL Server tienen 128 páginas
por megabyte. Existen 3 datos importantes para alinear nuestras
particiones.

6. 1.2. Formatear un Disco
Formato y Alineamiento de Disco

7. Temas:
1.Formateo y Alineamiento de Disco.
2.Diseño de la Base de datos Tempdb.
3.Diseño de Base de Datos.
A.- Diseño y Arquitectura de Base de
Datos en SQL Server
Mejores Prácticas con Transact SQL

8. 2.1. Definición
Diseño de la Base de Datos de la Tempdb
La TempDB es una base de datos del sistema que se instala por
defecto y se utiliza para almacenar objetos temporales creados
por el usuario como tablas temporales, vistas temporales,
variables temporales u otro objeto temporal.

9. Temas:
1.Formateo y Alineamiento de Disco.
2.Diseño de la Base de datos Tempdb.
3.Diseño de Base de Datos.
A.- Diseño y Arquitectura de Base de
Datos en SQL Server
Mejores Prácticas con Transact SQL

10. 3.1. Definición
Diseño de Base de Datos
Cuando vamos a crear una base de datos, por lo general, solo
pensamos en cómo se va a llamar y en qué servidor va a ser
alojada y sobre esto, determinamos si tenemos espacio en disco
para poder crearla. Pero las consideraciones que debemos de
tener en cuenta son:
- El tamaño proyectado que va a tener nuestra base de datos.
- La velocidad con la que podremos acceder a nuestra
información.
- La velocidad con la que podremos ingresar nuestra información.
- El tipo de información que almacenará la base de datos.

11. 3.2. Pasos en el Diseño de la Base de Datos
Diseño de Base de Datos
Además, podemos decir que uno de los pasos más importantes
en la creación de una aplicación que maneja una base de datos,
es el diseño de la misma, ya que si no tenemos en cuenta unas
buenas definiciones de nuestras tablas, tipos de datos y ubicación
de la base de datos podemos tener problemas de performance al
momento de utilizar nuestra aplicación.
- Capacity Planning
- Tamaño de nuestra base de datos

12. Temas:
1. Buenas Practicas en la Construcción de Consultas.
2. SQL HINTS
3. Optimizando Consultas.
4. Indices.
5. T-SQL Planes de Ejecución.
B.- Manejo de Consultas e índices en SQL
Server
Mejores Prácticas con Transact SQL

13. Temas:
1.Buenas Prácticas en la Construcción de Consultas.
2. SQL HINTS
3. Optimizando Consultas.
4. Índices.
5. T-SQL Planes de Ejecución.
B.-Manejo de Consultas e índices en SQL
Server
Mejores Prácticas con Transact SQL

14. 1.1. Definición
Buenas Practicas en la Construcción de Consultas
“El tema más importante en la elaboración de reportes o
extracción de información de nuestra base de datos es el tiempo
de procesamiento de las consultas que realizamos. Muchas veces,
esto se debe al hardware, el software utilizado, el mal diseño de
la base de datos, la mala formulación de índices y consultas. Por
tal motivo, para mejorar este último punto desarrollaremos
algunas consideraciones que nos permitirán minimizar el impacto
que tiene las consultas en el tiempo de procesamiento de
nuestra aplicación ”

15. 1.2. Consideraciones
Buenas Practicas en la Construcción de Consultas
T-SQL Crude vs Stored Procedure
• Lo recomendado es siempre utilizar las consultas dentro de
motor de base de datos y no dentro de la aplicación.
• Siempre realizar la consulta dentro de un procedimiento
almacenado ya que éste se ejecuta más rápido que
cualquier consulta externa fuera del motor de base de
datos.

16. 1.2. Consideraciones
Buenas Practicas en la Construcción de Consultas
T-SQL Crude vs Stored Procedure
• La primera vez que se ejecuta el procedimiento
almacenado es compilado lo que produce un plan de
ejecución que es un paso a paso de como el motor
ejecutará las sentencias SQL
• El plan es colocado en memoria (Cached) para su reuso

17. 1.2. Consideraciones
Buenas Practicas en la Construcción de Consultas
T-SQL Crude vs Stored Procedure
Otra ventajas:
• Seguridad: no se le da acceso a objetos internos de BD
• Administración cualquier cambio se hace en el
procedimiento no en la aplicación
• Tráfico de Red se reduce el tráfico porque se trabaja sobre
el motor de BD

18. 1.2. Consideraciones
Buenas Practicas en la Construcción de Consultas
Nunca se debe de utilizar el SELECT *
• No se debe usar Select * puesto que con esto el motor lee
primero toda la estructura de la tabla antes de ejecutar la
sentencia.
• Otra desventaja es que el resultado variará si se agrega o
quitan campos.

19. 1.2. Consideraciones
Buenas Practicas en la Construcción de Consultas
Para hacer consultas entre tablas es preferible usar los JOIN, RIGTH
JOIN y LEFT JOIN.
• Usar JOIN, RIGTH JOIN y LEFT JOIN ya que mientras el motor de
base de datos va leyendo las tablas va verificando que relación se
necesita entre ellas y de este modo, éste lee menos registro y
hace mas eficiente la consulta a diferencia del WHERE que hace
que las tablas se lean en su totalidad y después hace las
relaciones

20. 1.2. Consideraciones
Buenas Practicas en la Construcción de Consultas
Especificar a que tabla corresponde cada campo
• Si utilizas varias tablas en la consulta especifica siempre a que
tabla pertenece cada campo, le ahorras al gestor el tiempo de
localizar a que tabla pertenece el campo.
• En lugar de SELECT Nombre, Factura
FROM Clientes, Facturacion WHERE IdCliente=IdClienteFacturado,
usamos: SELECT Clientes.Nombre, Facturacion.Factura
WHERE Clientes.IdCliente = Facturacion.IdClienteFacturado.

21. 1.2. Consideraciones
Buenas Practicas en la Construcción de Consultas
Orden de las Tablas en las Consultas.
Cuando se realiza una consulta entre varias tablas el orden de estas
debe ir de menor a mayor número de registros; dependiendo del
numero de columnas y registros de la tabla se genera un resultado
que puede llevar mucho tiempo para ser completado por parte del
motor de base de datos.
• Ej: Si deseamos saber cuantos alumnos se matricularon en el año 1996 y escribimos: FROM
Alumnos, Matriculas WHERE Alumno.IdAlumno = Matriculas.IdAlumno AND Matriculas.Año =
1996 el gestor recorrerá todos los alumnos para buscar sus matriculas y devolver las
correspondientes. Si escribimos FROM Matriculas, Alumnos WHERE Matriculas.Año = 1996
AND Matriculas.IdAlumno = Alumnos.IdAlumnos, el gestor filtra las matrículas y después
selecciona los alumnos, de esta forma tiene que recorrer menos registros.

22. 1.2. Consideraciones
Buenas Practicas en la Construcción de Consultas
Operadores en el filtro:
Si utilizamos WHERE, los operadores a utilizar deben ser los de
mejor rendimiento. El orden de rendimiento de los operadores de
mayor a menor es:
=
>,>=, <=, <
LIKE
IN
<>, NOT IN, NOT LIKE

23. 1.2. Consideraciones
Buenas Practicas en la Construcción de Consultas
Orden de las Tablas en las Consultas.
Cuando se realiza una consulta entre varias tablas el orden de estas
debe ir de menor a mayor número de registros; dependiendo del
numero de columnas y registros de la tabla se genera un resultado
que puede llevar mucho tiempo para ser completado por parte del
motor de base de datos.

24. 1.2. Consideraciones
Buenas Practicas en la Construcción de Consultas
• Evitar el uso del comando LIKE con el siguiente wildcard „%R‟ ya
que no permite el uso del indice si el campo lo tuviera, LIKE con
el siguiente wildcard „R%‟ permite el escanéo parcial y el uso del
índice
• El comando BETWEEN es más eficiente que el IN porque el
primero busca un rango de valores y el segundo varios valores
puntuales provocando que la sentencia sea menos efectiva.

25. 1.2. Consideraciones
Buenas Practicas en la Construcción de Consultas
• Cuando utilicemos los operadores AND es preferible empezar
por los campos que sean parte de algún índice para que la
información seleccionada sea mas selectiva y la cantidad
de registros leídos sea mínimo.
• Cuando se tenga la necesidad de ordenar los datos en una
consulta se recomienda que los campos a ordenar sea el menor
número posible, y también se sugiere crear un índice de tipo
clustered index sobre el campo que se esta utilizando.

26. 1.2. Consideraciones
Buenas Practicas en la Construcción de Consultas
• No se recomienda el uso del INSERT INTO ya que esto origina
que la tabla se bloquee mientras se esta llevando acabo el insert
y de este modo se impide el uso del resto de datos a los
usuarios.
• Si dentro de una consulta se debe utilizar el comando HAVING se
recomienda hacer todos los filtros posibles con el comando
WHERE, de esta forma el trabajo que tiene que realizar el
comando HAVING será el menor posible.

27. 1.2. Consideraciones
Buenas Practicas en la Construcción de Consultas
• Se procurará elegir en la cláusula WHERE aquellos campos que
formen parte del índice de la tabla
• Además se especificarán en el mismo orden en el que estén
definidos en la clave.
•Filtrar siempre por campos que tengan índices.

28. 1.2. Consideraciones
Buenas Practicas en la Construcción de Consultas
• Si deseamos interrogar por campos pertenecientes a índices
compuestos es mejor utilizar todos los campos de todos los índices.
Si tenemos un índice formado por el campo NOMBRE y el campo
APELLIDO y otro índice formado por el campo EDAD. La sentencia
WHERE NOMBRE='Juan' AND APELLIDO Like '%' AND EDAD = 20
sería más optima que WHERE NOMBRE = 'Juan' AND EDAD = 20
por que el gestor, en este segundo caso, no puede usar el primer
índice y ambas sentencias son equivalentes por que la condición
APELLIDO Like '%' devolvería todos los registros.

29. Temas:
1.Buenas Prácticas en la Construcción de Consultas.
2. SQL HINTS
3. Optimizando Consultas.
4. Índices.
5. T-SQL Planes de Ejecución.
B.- Manejo de Consultas e índices en SQL
Server
Mejores Prácticas con Transact SQL

30. 2.1. Definición
SQL Hints
«Los HINTS son opciones que se interponen a los comandos Select,
Insert, Update y Delete para especificar qué es lo que se tiene que
hacer, en lugar que el motor de base de datos decida qué hacer. El
lugar donde el motor decide cómo hacer la consulta, se llama
optimizador de consultas y la forma cómo se ejecuta la consulta se
llama Plan de ejecución
Existen 4 formas de aplicar los HINTS:
JOIN HINTS: Que especifica el tipo de JOIN que se utilizará.
INDEX HINTS: Que especifica el tipo de INDEX que se utilizará
LOCK HINTS: Que especifica el tipo de bloqueo que se utilizará.
PROCESSING HINTS: Que especifica la forma cómo se ejecutara el
query..»

31. Temas:
1.Buenas Practicas en la Construcción de Consultas.
2. SQL HINTS
3. Optimizando Consultas.
4. Índices.
5. T-SQL Planes de Ejecución.
B.- Manejo de Consultas e índices en SQL
Server
Mejores Prácticas con Transact SQL

32. 3.1. Definición
Optimizando Consultas
Cuando trabajamos realizando consultas sobre nuestra base de
datos tenemos que saber que siempre existirán consultas que son
más pesadas que otras, ya sea por que tenemos queries que
consultan tablas que tiene más registros que otras o por que los
filtros que utilizamos invocan a una gran cantidad de registros
entre tablas.
El objetivo de este punto es determinar cuáles son las consultas
de mayor impacto en nuestro servidor y analizar qué podemos
cambiar en ellas para mejorar la performance de nuestra base de
datos.

33. Temas:
1.Buenas Practicas en la Construcción de Consultas.
2. SQL HINTS
3. Optimizando Consultas.
4. Índices.
5. T-SQL Planes de Ejecución.
B.- Manejo de Consultas e índices en SQL
Server
Mejores Prácticas con Transact SQL

34. 4.1. Definición
Índices
«La performance de la aplicación, por lo general, siempre está
basada directamente, en el buen o mal diseño de nuestros índices,
ya que la función principal de éstos es optimizar el acceso a los
datos »

35. 4.2. Tipos de Indices
Índices
Índices Tipo Clustered
Índices de tipo No Clustered

36. Temas:
1.Buenas Practicas en la Construcción de Consultas.
2. SQL HINTS
3. Optimizando Consultas.
4. Índices.
5. T-SQL Planes de Ejecución.
B.- Manejo de Consultas e índices en SQL
Server
Mejores Prácticas con Transact SQL

37. 5.1. Definición
T-SQL Planes de Ejecución
«Cuando ejecutamos una sentencia dentro de nuestra base de datos,
el motor internamente ejecuta una serie de operación que varían
según la cantidad de datos, objetos y schemas. A estas operaciones
en conjunto. se le conoce como Plan de Ejecución .»

38. 5.2. Objetos de Planes de Ejecución
T-SQL Planes de Ejecución
Dentro de los Planes de ejecución se conocen los
siguientes operadores:
•Table Scan
•Clustered Index Scan
•Clustered Index Seek
•Index Seek
•Bookmark Lookup
•Index Scan
•Neested Loop Join
•Merge Join
•Hash Join
•Sort