Hola bienvenidos a este sexto capítulo del curso completo de base de datos.
En esta oportunidad vamos a hablar de dos índices.
Cuando pensamos en la palabra índice se nos viene a la mente los índices de los libros que no son más
que un listado de temas apuntados a un número de páginas determinado.
Esto fue pensado y creado para que los lectores que deseen solo abordar rápidamente el tema no tengan
que leerse todo el libro completo para encontrarlo.
Entonces si tengo en mis manos un libro completo sobre programación Java pero quiero ver solamente el
tema que habla de tipos de datos en Java voy a ir al índice y en pocos segundos encontrar el tema que
necesito o okey está en la página 197 y ahí me dirigiré en una base de datos.
Los índices funcionan de manera muy similar y nos permiten determinar en qué campo serán índices.
También solemos llamarlos clave.
Por ejemplo la clave principal de la tabla clientes debe ser si o si el aided de cliente.
Como vemos en este ejemplo al definirlo como índice cuando le pidamos a la base de datos que nos ubique
el cliente número 2 qué creen que hará el motor de base de datos recorrer toda la tabla adquirientes
hasta encontrarlo o ir a la ubicación del disco rígido donde se encuentra el registro correspondiente
al cliente número dos.
Lo bueno es que podemos tener tantos índices por cada tabla como decíamos aunque luego veamos en la
sección de normalización de bases de datos aspectos importantes a tener en cuenta a la hora de determinar
un índice.
Hay principalmente tres tipos de índices importantes el prisma primarily o clave principal el lluny
o clave única sin repetición y el quiz solamente que es la clave una clave cualquiera que pueda estar
duplicada.
Vamos a ver cómo funcionan estos tres amigos de la optimización.
El primer aquí en la clave principal de cada tabla es una muy buena práctica que cada tabla tenga su
prima Ariki.
Por cuestiones de performance y tiene la restricción de que no puede duplicarse es decir por ejemplo
en el ejemplo que vimos no podemos tener dos registros con el vídeo bajo EIIL igual a 2 se supone que
la clave irrepetible con la que identificaremos inequívocamente a nuestro cliente.
Esto mismo aplica a proveedores artículos cualquier entidad que tengamos usuarios cualquier entidad
que tengamos grabada en la base de datos la prima de equipos tienen la posibilidad de auto generarse
con una propiedad llamada auto incremento Cuando indicamos a nuestra tabla que nuestra prima ariki usará
un auto incremento significa que su valor se irá Hatay incrementando conforme creemos nuevos registros.
En estos casos no tendremos que pagar ningún valor a ese campo cuando queremos nuevos registros.
Por ejemplo supongamos que tengamos una aplicación que da de alta a clientes.
Acaso nosotros tendremos que llevar la cuenta de cuál es el próximo número de cliente libre.
No nada de eso el motor asignará a la prima ariki el próximo valor automáticamente.
Entonces podemos crear el cliente Juán y el motor le pondrá el número 1.
Luego creamos el Kylián Depedro y el Motorola le asignará el número dos.
Esta funcionalidad no viene por defecto.
Uno tiene que tirar la casilla que dice auto incremento en la prima ariki para que tenga este comportamiento.
Vamos a ver ahora las lluny y comparte al igual que las primarily el hecho de que no pueden haber valores
duplicados en el campo o el conjunto de datos señalados.
Cabe destacar que una clave no necesariamente debe estar formada por un solo campo.
Quizás queremos crear una clave única uniendo para ello los campos de por ejemplo número de factura
más código de producto y evitar que un mismo producto se duplique en una factura.
A diferencia de las primarily la y no tienen la propiedad auto incrementa habilitã luego tenemos Laski
Lasky son claves simples que admiten valores duplicados por ejemplo en una tabla para el campo AUR y
bajo pero hoy día si quisiéramos listar todos los productos el proveedor 52 el motor solo debe consultar
el índice y ver en qué registro poner el foco.
Si en este ejemplo AUR de un bajo pero eurito no fuera una clave el motor no tendría otro remedio que
leer los miles y miles de registros de todos los productos que comercializamos para separar los que
correspondan al proveedor número 52 ocasionando un problema de performance considerable.
Entonces vemos que los índices fueron creados para lograr buenas performance accediendo a datos más
representativos.
Mi consejo es que si en total la elcampo que son referencias a otros maestros no convierta el índice
sí o sí vamos a ver un ejemplo durante una venta tenemos que alimentar dos tablas la tabla de cabecera
de facturas y la tabla de pase de facturas.
Este modelo no vamos a ver bien cuando veamos sobre las tres formas normales de optimización de base
de datos en la tabla de cabecera seguramente tengamos alguno de estos datos que vemos ahora en pantalla.
El factor m y un bajo Aydin el FACC medio a un bajo fechan el FACC medio un prefijo y el medio Europac
terminando con M CLI Heydi.
Qué son estos campos.
El primero obviamente se habrán dado cuenta en nuestra Primary y auto incremental el segundo es la fecha
de la factura.
El otro es el prefijo de la facultad son cuatro o cinco dígitos dependiendo del país que representan
al punto de venta de la factura.
El siguiente es el número Fateh y son los ocho dígitos del número de factura y el último es el Heydi
de cliente.
Aquí no voy a grabar el nombre del cliente.
Sería una práctica horrible muy poco profesional grabar en una cabecera de factura el nombre del cliente
y ocupar todo el espacio que ocupa un nombre.
Cuando puedo obtener el aided que es un número que me va a llevar a la tabla maestra de clientes y hoy
en día tener todos los datos que necesite el nombre el mail la dirección.
Eso tiene que ver con las buenas prácticas y con las optimizaciones de tablas a lo largo de mi carrera
he visto todo tipo de animalada en este sentido propio de gente sin experiencia.
Y es bueno aprender las optimizaciones que necesitan las tablas en la tabla detalle de facturas que
vemos a continuación tenemos aquí puse solamente tres campos porque este es un ejemplo el paquete de
detalle de detalle la M anterior era de maestro natilla.
Cuando veo partid si no tiene una M una de ello no sé si me está hablando del detalle o de la tabla
maestra M es un barco Faydit desde Leydi de la tabla de facturas maestra y de bajo Aydin.
Este Leydis de la tabla de dietas que prima ariki como imaginamos.
Luego tenemos una idea que me lleva CIMI tabla maestra.
Esto es fundamental por aquella modelarse de una factura a cada uno de los ítems a cada uno de los productos
que vendí.
Entonces imitable al detalle tengo que tener una idea que me apunte a mirar la maestra.
Este producto que se vendió en la tabla de ventas facturas a qué factura corresponde.
Aquí no voy a repetir en la tabla de detalles no voy a repetir la fecha el número de clientes el número
de factura no puedo repetir los datos no puedo duplicar información es una práctica totalmente condenable
y propia de amateurs de bases de datos.
Repetir información.
Todo esto lo vamos a ver más en detalle en el curso de optimización de bases de datos que viene después.
Y por último en el ejemplo tenemos el Farber y un bajo artículo es el Heydi de mi tabla de productos.
Nuevamente en la tabla de detalle de facturas no voy a poner la descripción del producto con el código
con la descripción en color.
La medida no voy a duplicar información.
Si yo quiero saber qué producto es en base al Euribor que fue grabado aquí me voy a la tabla de productos
y traigo toda la información.
Esto que están viendo ustedes en pantalla es básicamente un ejemplo de cómo usar Eirís y cómo optimizar
bases de datos por un breve ejemplo después lo vamos a ver en el próximo capítulo ya empezamos a verlo
muy en profundidad y como estamos viendo el tema índices es importante entender que aparte de la la
fecha del campo Cabecera también conviene asignarle propiedades de índice de clave porque es muy común
buscar las facturas que van de tal fecha tal fecha en un rango de fecha.
El prefijo no sería importante el número de factura habría que estudiarlo y si el Heydi de cliente va
a tener que ser claro yo quiero todas las facturas del cliente número 2 y me va a ir explosivamente
a esos requisitos.
Imaginemos el campo cliente no es clave.
Quiero todas las facturas del cliente 2 del año pasado al motor.
No le va a quedar otra que recorrer cada una de las facturas del año pasado sean del cliente 2 o no
del cliente 2.
Eso va a ocasionar muchos segundos de demora a veces hasta minutos.
Para eso se crearon los índices para bajar consultas que nos tomaría minutos sin obtener una respuesta
en solo milisegundos.
Estas consultas van a demorar milisegundos aún si la tabla tuviera millones de registros así que es
muy importante el tema.
Ahora nos vamos a enfocar a partir de esta clase en lo que es optimización de tablas.
Vamos como habrán visto estamos yendo de menor a mayor.
Cada vez se va a poner más interesante y vamos a abandonar de a poco el sector de novatos y vamos a
empezar en el sector intermedio vamos a aprender buenas prácticas y después tenemos todo el lenguaje
SQL el lenguaje de base de datos que lo vamos a aprender completo.
Quizás alguien dirá no pero no enseñó tal función o tal función agregada o tal combinación.
Bueno voy a enseñar completo el lenguaje de lo que se usa en el 99 por ciento de los casos así que bueno
los invito ahora a realizar un breve examen en pantalla muy breve muy fácil para que ustedes vean si
han afianzado algunos conocimientos y podamos continuar con el resto del curso.
Los invito al examen y nos vemos en el curso de optimización de base de datos.