heres the resumen

BasesDeDatos/resumen1.org

@@ -81,3 +81,51 @@ WHERE SupplierID IN (
     WHERE Country = 'USA'
 );
 #+end_src
+
+* clase4 Indices
+Los indices son utilizados para mejorar el tiempo de ejecucion de las querys en las bases de datos. Estos traen pros y contras. y vienen en distintos tipos.
+
+La mala administracion de los indices en una base de datos puede llevar a efectos no deseados
+
+** Indices Primario
+*** Duro
+Este tipo de indice es el que crea un registro de indice por cada valor de clase de la base.
+
+*** Disperso
+Es un indice que genera un registro por cada cierta cantidad de valores key.
+
+*** Multinivel
+Tiene uno o varisos niveles de indices dispersos y el ultimo nivel denso que apunta a la base de datos.
+
+** Indices Secundarios
+Estos se construyen sobre un atributo que no esta ordenado previamente en la DB, donde se crea en el archivo de indices un registro donde se pone el valor clave junto a una cubeta con punteros a los registros que tengan el valor key.
+No ordenan la tabla.
+
+** B-Tree
+Hay de dos tipos el arbol binario normal o un arbol binario pero el nodo rama tambien guarda un dato.
+
+* clase5 Procesamiento de consultas
+Al ejecutar una consulta se corren estos procesos:
+- Analisis Sintactico
+- Se comprueba que lso objetos que se van a utililizar en la query estan a disposicion.
+- Se convierte la consulta en expresiones de algebra relacional.
+- Se ejecuta con el plan de ejecucion creado en el paso anterior.
+
+* clase6 Optimizacion de Consultas
+existe 2 formas de determinar la forma optima de ejecucion de una consulta:
+1. Por Costos
+2. Euristica
+
+** Por Costos
+Esta implica dar un peso a los planes de ejecucion segun un archivo estadistico, una vez asignados los valores, se selecciona el que tenga menor tiempo de ejecucion.
+
+Tiene un contra y es que en caso de existir muchos planes de ejecucion obtener los datos y seleccionar uno puede tomar mucho tiempo.
+
+** Euristica
+Consiste en elejir decisiones que se conocen como buenas de forma previa. sin tomar en cuenta si son las más optimas para el caso actual. algunos ejemplos Son
+- No poner el * en el SELECT de la consulta.
+- poner el db.schema.tabla en vez de la tabla sola.
+- utilizar el not exists en vez de not in.
+- no usar sp_ para las store procedures que hagamos nosotros.
+- no uses Distinct, Group By o Order By si no es indispensable.
+- desabilitar el contado de registros afectados en consultas que no lo necesiten.