Bloque Oracle: SQL, MySQL, ACCESS

Este curso es sobre SQL, un lenguaje universal que sirve para acceder a bases de datos en
remoto. Este curso va dirigido a gente que sabe que es una base de datos, que es un registro,
propiedades, etc. El temario es el siguiente:

Vamos a trabajar con ACCESS y con MySQL. En esta primera parte, veremos:

Que es SQL: Siglas de Structures Query Language o lenguaje estructurado de consultas. Es un

lenguaje para interactuar con bases de datos relacionales. Con consultas nos referimos a
realizar además de creación de bases de datos, creación de campos, modificar propiedades,
establecer relaciones entre dos tablas de bases de datos.

El esquema básico de SQL es:

Para hacerlo, necesitamos un gestor de base de datos que interactúe con esto. Son los SGDB, y
entre ellos está SQL, ORACLE, MySQL. Todos adoptan el estándar SQL para interactuar con las
bases de datos.

Algunos son en local (ACCESS) y otros con bases de datos en remoto (MySQL).

Hay un estándar de SQL adoptado por todos los gestores de bases de datos, pero cada uno
tiene su propia versión. Si tenemos la base estándar, sabremos usarlo en distintos gestores,
pero cada gestor tiene como su “dialecto”. El estándar es ANSI + ISO.

Una sentencia SQL es una frase en inglés con comandos:

Grupos de comandos

DDL: Data Definition Languaje (crear, modificar, eliminar)

DML: Data Manipulation Languaje (seleccionar, consultar, insertar, actualizar)

DCL: Data Control Languaje (proporcionan seguridad)

TCL: Transation Control Languaje (control de los cambios en los datos)

 Grupos de clausulas

Instrucción SQL

NOTA: No es necesario que tenga todo cada instrucción SQL, con COMANDO+CLAUSULA vale.
Lo otro son opcionales, y dependerá de lo que queramos hacer.

**** Vamos a empezar a trabajar con una base de datos de Access:

**** Para en SQL hacer una consulta, por ejemplo, que me saque solo los clientes de Madrid,
nos dirigimos al botón Crear->Diseño de consulta->Seleccionamos Clientes
**** Y seleccionamos SQL Ver:

**** Nos llevará aquí:

**** Para hacer la consulta de sacar solo los campos empresa, dirección y población de
clientes. Damos a ejecutar (arriba izquierda con una exclamación) y nos saca por pantalla solo
la info que pedimos aquí:

Procedemos a hacer lo mismo en PHPmyAdmin a través de MAMP:

Vamos a crear una base de datos que llamaremos Curso_SQL, y luego importaremos los
archivos de Excel con extensión ods. Nos aseguraremos de que, a la hora de importar
pongamos el formato OpenDocument Spreadsheet y MUY IMPORTANTE habilitar que la
primera fila de la tabla contiene los nombres de cada columna. Haremos el mismo
procedimiento con CLIENTES Y CON PRODUCTOS:
Vamos a ejecutar la misma instrucción que lo de arriba:
Clausulas. Son las siguientes:

Operadores. Son para establecer criterios:

Operadores lógicos:

Esto de aquí abajo, aunque puede pasar, es muy raro que se den tantas clausulas juntas en una
solo sentencia SQL, pero el orden es así:

NOTA: Para seleccionar todo en la consulta ponemos comando SELEC *, el * es que coja todos
los campos.

Pondremos una práctica en PHPMyAdmin. Vamos a hacer una consulta para ver los artículos
que pertenecen a la sección de cerámica:
Lo mismo en ACCESS (seguir los pasos de arriba**** para llegar aquí ):

Por ejemplo, si queremos que salgan los artículos de cerámica y también los de deporte,
pondremos OR no AND, y esto es, porque no hay una sección que sea cerámica junto con
deporte, será solo uno u otro. La consulta correcta será así:

Vamos a poner que queremos sacar todos los productos de deporte cuyo país de origen sea
USA. Para ello usamos esta sentencia:

Podemos concatenar AND, OR nombre-sección=”criterio”.

En principio, en SQL(nosotros estamos a través de PHPmyAdmin) si ahora mismo, quisiéramos
sacar algún tipo de dato numérico, no podríamos. Vamos a ver como se hace:

Queremos sacar los artículos que valgan más de 300€. Si lo ponemos con la sentencia correcta,
nos saldrá erróneo todo, y el motivo es que, a la hora de importar el archivo .ods, se puso todo
como varchar en PHPmyAdmin, por tanto, todo es varchar para nuestra base de datos.
Tendríamos que cambiarlo, y para ello hay que eliminar PRODUCTOS, volver al Excel y en ese
mismo archivo le damos a la columna PRECIOS formato moneda y a la columna FECHA formato
fecha(año-mes-día):

Esto es MUY IMPORTANTE, TENER SIEMPRE EN CUENTA LOS TIPOS DE DATOS QUE
IMPORTAMOS. No podemos cambiar los datos desde PHPmyAdmin porque elimina la info.

Lo único que se puede hacer, en el caso del formato fecha, es desde el mismo PHPmyAdmin
cambiarlo a DATE. Pero porque ya tenemos los datos en ese formato dentro y no nos queda de
otra.

Vamos a hacer una consulta usando BETWEEN. Quiero que sean artículos entre marzo y abril
del 2000:

Consultas de agrupación o totales

Nos permite hacer cálculos por grupos. Vamos a ver cómo funciona la ORDER BY. Esta
siempre va en último lugar en la sentencia. Vamos a buscar los artículos de deporte y de
cerámica, y los ordenamos por sección (es texto, asique lo ordena por orden alfabético) si
fueran números, sería de menor o mayor. Esto se puede cambiar añadiendo, después de
ORDER BY, DESC O ASC. Solo se puede ordenar por una cosa.
Pero podemos establecer varios criterios de ordenación, en este caso, se ordenan por sección
y también por precio. En este caso, si se pueden poner así, solo un ORDER BY:

También podemos hacer esto mismo poniendo el precio descendente.

Para poder hacer cálculos pertinentes, usamos las funciones de agregado SQL, que son:

En este ejemplo vamos a ver cuánto suman los artículos de las secciones, cuanto son los de
ferretería, deportes, etc. Usaremos dos, campo de agrupación (sección)-campo del cálculo
(precio). Tenemos que incluir los campos SECCION Y PRECIO. Que SELECT nos dé solo sección,
ponemos una coma, que nos sume el precio (lo que vayamos a poner delante de SUM entre ())
de la tabla productos, y que luego ordene por sección:

El resultado es este:
Como generamos la columna temporal SUM (PRECIO), pero realmente no estamos
consultando la columna precio, no podríamos poner ORDER BY PRECIO para ordenar las
secciones según el precio. Podemos hacerlo agregando un ALIAS, cambiando el nombre de
SUM (PRECIO) para que reconozca con el ORDER BY precio que quiero ordenarlo por precio.
Usamos la cláusula AS:

En este caso, estamos incluyendo dos campos en SELECT (sección y suma del precio), pero que
pasa si añadimos tres o más, en MySQL por ejemplo agrega el primer registro de este campo.
Por ejemplo, si agregamos otro después de sección y de sum (precio), ese campo aparecería
entre medias y sale el nombre del primer artículo de cada sección. No muy útil. ACCESS no lo
hace, no lo agrupa:

Vamos ahora a consultar la media de los artículos de deporte y de confección. En este caso, lo
haremos con HAVING no con WHERE, ordenaremos con un alias como antes:
Vamos a contar cuantos clientes hay por población. En SELECT ponemos población ya que es lo
que queremos consultar, necesitamos contar los cliente de cada población, con un campo que
sepamos que va a estar. Aquí, lo más fiable es el código cliente, al cual de la damos un alias. Le
indicamos con FROM que es de la tabla clientes y que nos los ordene por población.

Funciones Max y Min: Vamos a averiguar el precio del artículo más caro de la sección de
confección en la tabla productos. La consulta sería así:

Consultas de cálculo

Es distinto a lo anterior, es sobre individual y no grupos. Aquí usamos frecuentemente

funciones SQL. Las funciones se salen del estándar de SQL porque cada gestor de bases de
datos tiene las suyas. Nosotros vamos a ver las de MySQL. (ACCESS tiene las suyas propias).
Hay algunas comunes y frecuentes que vamos a usar ahora:
Datediff(): Devuelve la diferencia entre dos fechas.

Dateformat(): Redondea fechas, pero ROUND es mejor. TRUNCATE también se usa

Concate(): Concatena frases.

Vamos a hacer una consulta de cálculo sobre la tabla de productos. Son sobre registros
individuales, y no sobre grupos. Pondremos una consulta en la que obtenemos el precio con el
IVA al 21%. Tendremos que meter un campo nuevo tal y como señalamos en el cuadro verde
para que saque precio+IVA, damos el alias IVA. Va a sacar algo grande, por producto:

Si queremos evitar tantos decimales, ponemos ROUND donde antes estaba PRECIO, no está
aquí pero detrás de 0.21 va el , y num de decimales (,2 por ejemplo) :

En los libros se les dice campo calculado o consultas de campo nuevo calculado

Vamos a poner un descuento de 3 euros. La consulta es similar a la anterior:

Vamos ahora a realizar una consulta pero para las fechas. Seleccionamos lo mismo, pero
añadimos FECHA al SELECT. Para que no salga toda la tabla de productos, usamos WHERE para
elegir en la sección solo deportes:

Vamos a saber los días de diferencia que hay entre la fecha de un artículo y el día de hoy. Esto
tiene bastante chicha, asique iré color por color explicando:

 Con NOW() y AS DIA_DE_HOY sacamos la fecha actual y le damos el alias

 Con DATEDIFF(NOW(),FECHA) Y AS DIAS_DE_DIFERENCIA establecemos la diferencia
de días entre la fecha actual y la fecha del producto.
 WHERE: Aquí seleccionamos solo la sección de deportes.
 DATE_FORMAT(NOW()’%D%-M%’): Esto le da a la fecha formato de día y mes.

Consultas multitabla

Es para varias tablas almacenadas en nuestra base de datos. Por ejemplo, tenemos 30 tablas
en nuestra base de datos, y queremos ver alguna info de cinco de esas.

Estos no están ni en MySQL

ni en ACCESS
Consulta UNION: Une varias consultas de diferentes tablas de una base de datos. Será
necesario porque siempre van a entrar varias tablas nuevas por cualquier tipo. Las tablas
tienen que cumplir una serie de requisitos:

 Tienen que tener el mismo número de campos

 Tienen que tener tipos de datos compatibles: Si pueden ser distintos nombres, pero
celda mismo tipo.

Cuando hacemos este tipo de consultas, lo que se hace es que ambas tablas se fusionan y esa
consulta toma como nombre de campos el de la tabla 1.

En nuestro ejemplo, hemos importado a MySQL una nueva tabla, nuevos productos que han
llegado (ProductosNuevos.ods). Usaremos las siguientes consultas para unir las dos carpetas:
queremos ver en una consulta los artículos que pertenecen a deportes y a deportes de riesgo.

Hay más abajo, pero lo

recorté

En el caso de nuestro ejemplo, el criterio de consulta es el mismo (en ambos buscamos un tipo
de artículo en SECCIÓN) pero pueden ser criterios distintos. En ACCESS no se pueden usar
consultas de unión en tablas de tipo objeto (imágenes, fotos, otros archivos, objeto OLE).

Vamos a consultar que nos muestro los artículos con precio superior a 500€ y los artículos de la
tabla productos y de productosnuevos los de alta costura.

NOTA: En estas consultas de unión, si en SELECT pongo tres campos, para unirlo con la otra
tabla, tengo que poner también tres campos.
 Diferencias entre UNION Y UNION ALL.

 UNION: Si hay campos repetidos en ambas tablas, los muestra solo una vez.
 UNION ALL: Muestra también registros repetidos las veces que esté.

Vamos a usar UNION ALL. Cogemos un producto (las mancuernas) de la tabla productos y la
repetimos en productosnuevos, lo insertamos y hacemos la siguiente consulta para que nos
saque todos los de la sección deporte en la tabla productos, y TODOS los productos de la tabla
productosnuevos:

En la página 1, nos sale primero el de la tabla productos. Siempre nos saldrá el primero:

Si usamos UNION ALL, nos va a mostrar todo, da igual las veces que se repita (es como el
anterior, pero en lugar en UNION PONEMOS UNION ALL).

Unión interna

NOTA: Repasar algún curso de relaciones entre tablas (en pildorasinformáticas, tienen de
ACCESS, esos sirven).

Vamos a ACCESS y abrimos el archivo del vídeo 8. Si miramos la relación de tablas vemos,
gracias al símbolo que marco en verde, que los clientes han hecho varios pedidos, no hay solo
una relación hay varias. Por ejemplo por cada registro de la tabla A puedo tener varios
registros relacionados en la tabla B:
Gracias a esta relación, yo puedo ver que clientes han pedido en un mes de un año concreto,
cuantos pedidos ha hecho, que pedidos se han pagado con X forma de pago, etc. Con los JOINS
podemos realizar todas las consultas. Comenzamos con el primero, en INNER JOIN.

INNER JOIN refleja la información común en ambas tablas, nos devuelve los registros que
aparecen en ambas tablas. Por ejemplo, los clientes que aparecen en las dos tablas. Si el
cliente TC01 me ha comprado cosas, aparecerá en la tabla de clientes y en la de productos,
pero el cliente TC03 no me ha comprado nada asique no está en la tabla de productos. Con
INNER JOIN SOLO veremos al cliente TC01 (está en ambas tablas)

LEFT JOIN refleja tanto la información común como la que solo aparezca en la tabla primera.
Por ejemplo, los clientes de arriba, los sacará a los dos, ya que ambos están registrados como
clientes, y a LEFT JOIN le da igual si me ha comprado o no.

RIGHT JOIN refleja tanto la información común como la que solo aparezca en la tabla segunda.
Por ejemplo, los clientes de arriba, solo sacará al cliente TC01, ya que ha comprado asique
aparece en la tabla productos. El TC03 no ha comprado asique no lo va a sacar.

Vamos a hacerlo primero en ACCESS.

Con ON le indicamos que ambas tablas se encuentran relacionadas a través del campo código
cliente. La especificación de esto en la consulta es así:

Al llamarse igual los campos en las dos tablas, ponemos clientes.[código cliente] y pedidos.
[código cliente]. Así nos saca todos los clientes que han hecho pedidos, pero vamos a poner
que salgan solo los de Madrid (SEPARACIONES ENTRE [], EVITAR PONER NOMBRES CON
SEPARACIÓN, TODOJUNTOSIEMPRE):
 Hay que seguir moviendo
hacia allá para ver todo

Vamos a importar a PHPmyAdmin para trabajar en MySQL. Una vez las tenemos importadas
como hicimos anteriormente, procedemos a relacionarlas:

Vamos a la de clientes, luego pulsamos en estructura y luego INDICES, le damos y creamos uno
en una columna y nos sale que tipo de índice queremos crear. Ponemos que es PRIMARY, y
luego especificamos la columna que será CODIGOCLIENTE. Damos a continuar y ya se habrá
creado:

Vamos ahora a la tabla de PEDIDOS. Tenemos que indicar clave primary que es
numerodepedido (como el de arriba), y cuál será el campo común con la tabla CLIENTES (aquí
abajo esta):
 Campo para clave primaria

Campo para clave indexada

Sin movernos de la tabla de pedidos, vamos a Vista de Relaciones (cuadro rosa), luego
seleccionamos lo que vemos en la imagen, y establecemos el codigocliente (campos común).
Vamos a relacionarlo con la tabla de clientes, usando en la tabla de clientes la clave primaria
codigocliente. Seleccionamos DELETE en CASCADE y UPDATE en CASCADE (que si borras un
registro de la tabla, se borran todos los que tengan relación con esa)

Una vez tenemos todas las relaciones puestas, vamos a realizar las consultas para practicar
INNER, LEFT y RIGHT JOIN.

Haremos una consulta que nos muestre todos los pedidos que nos han hecho los clientes de
Madrid, pero que solo nos muestre algunos datos de los mismos:

Como hemos usado INNER JOIN nos va a mostrar los que cumplan los dos requisitos: que sean
clientes y que nos hayan hecho pedidos. Si lo cambiamos a LEFT JOIN nos sacará todos los
clientes, hayan hecho pedidos o no. Para ello, hay que agregar algo más, que es tener en
cuenta que en la tabla de pedidos el CODIGOCLIENTE sea NULO, ya que nunca ha hecho un
pedido:

Si ponemos RIGHT JOIN solo mostrará los clientes que si nos hayan hecho pedidos. Se puede
usar como el otro porque siempre van a estar como clientes y además son de los que compran:

Subconsultas

La subconsulta es una consulta dentro de otra, es decir, un SELECT dentro de otro SELECT. Es
un padre con un hijo, este SELECT hijo va entre paréntesis y se va a usar como filtro o criterio
del SELECT padre. Estamos comparando los registros que devuelve el SELECT INTERIOR CON EL
SELECT EXTERIOR. Se usarán mucho los operadores lógicos y de comparación. Tendremos unos
nuevos operadores de comparación que aquí usaremos bastante y son: IN, ANY y ALL. Veamos
ejemplos:

Subconsulta escalonada: El SELECT interno devuelve una única columna con un único registro
y eso se utiliza como criterio en la consulta padre.

Vamos a crear una consulta que nos devuelva el nombre y la sección de aquellos productos
cuyo precio sea superior a la media, para ello, vamos a la tabla productos, y tenemos que
hacer dos consultas (una dentro de otra):

Esto es el criterio, lo tenemos que crear,

queremos comparar media pues tenemos
que sacar antes la media

Solo saldrá el mayor que la media, que es solo el abrigo de 50.000.

Subconsultas de listas: Esta en vez de devolver un solo registro devuelve una lista de registros.
Se usan mucho los operadores IN, ANY y ALL.

Vamos a hacer una consulta que devuelva los artículos cuyo precio ES superior que todos los
artículos de cerámica uno a uno, es decir, no superior al total, sino a todos los CERÁMICA:

Esto es el criterio, lo tenemos que crear Y

VOLVEMOS A COMPARAR. Sale todo lo
que sea sup al precio de esta lista.

Si ponemos esto mismo, con ANY en lugar de ALL, devolverá CUALQUIERA mayor que lo que
tenemos comparando, asique devuelve muchos más registros que el ALL.

Vamos a repetir un ejemplo con estos dos operadores. Haremos una subconsulta que nos
muestre en principio todos los artículos de la tabla de productos cuyo precio sea superior a
todos los artículos de juguetería. Luego haremos lo mismo cambiando el todo por cualquier
artículo de juguetería.

Si, solo sale el abrigo. Es el único que es más caro que toda la lista de juguetes junta (vamos,
hay un juguete carísimo de 1500 y pico pavos, y ni con eso más todo lo demás sumado superan
al abrigo).

Vamos a hacer la misma consulta pero cambiamos ALL por ANY:

Aquí ya nos devuelve todos los artículos cuyo precio sea superior a 40€(es el juguete más
barato). Porque devuelve lo que sea, cualquiera, superior al precio de cualquier artículo de
juguetería, por ejemplo, un destornillador de 7€ no lo va a devolver. Esto es jodido de pillar.

Vamos a ver ahora IN y NOT IN. Son dos predicados, que significan: o están o no están. Ya
sabemos que la subconsulta filtra. Con estos dos, vemos que registros están y que registros no
están en los que nos devuelve las subconsultas:

Esta vez lo haremos en ACCESS porque es más fácil ver las relaciones así:
Con el predicado IN podemos hacer una consulta del nombre y precio de los productos que se
han pedido más de 20 unidades.

Esto marcado en rojo, nos devuelve una única columna, que es codigoartículo pero solo nos va
a sacar los que las unidades vendidas (en productospedidos) sean más de 20 unidades.

Luego, con ese criterio, va a sacar el nombreartículo y el precio de productos donde el

codigoarticulo cumpla la condición entre paréntesis y en rojo (es OTRA TABLA, PERO ESTAN
RELACIONADAS ASIQUE ESTA CONSULTA VALE).

Vamos a repetir la misma consulta pero en Vista diseño para que sea más fácil verlo y ver la
relación. Para ello hacemos los mismos pasos pero en esta pantalla seleccionamos
PRODUCTOS Y PRODUCTOSPEDIDOS:
 Obtendremos esto y vamos a
trabajar con el recuadro de abajo
señalado en azul

En este caso, seleccionamos que queremos ver de la tabla productos (nomarticulo y precio) y
de la tabla productospedidos las unidades y que sean mayor que 20 unidades pedidas.
Desmarcamos mostrar para que no saque todo, solo lo del criterio.

Para poder hacer este tipo de consultas tan visuales que tenemos aquí arriba en
ACCESS,necesitamos que las tablas estén relacionadas entre sí, si no, no se podría. Saca cosas
sin sentido. En SQL no importa si las tablas están relacionadas o no (SQL es la consulta que
hemos guardado como Subconsulta 1 en este ejemplo).

En realidad, con INNER JOIN se pueden sacar este mismo tipo de resultados y además, para
ello no hace falta que las tablas estén relacionadas. Pero sería mucho más complicado, aunque
a mí no me lo parece. Siempre y cuando no esté con más tablas y tengas que meter más:

El NOT IN es que no está. Por ejemplo, vamos a sacar a los clientes que no han pagado con
tarjeta o que no han realizado pedidos.
Vamos a explicar: Select empresa, de la tabla clientes donde codigocliente (este criterio
siempre estará, por eso lo usamos) NOT IN no está, en select codigocliente (lo mismo, aquí
buscamos a los clientes) from pedidos (no han pedido nada, asique no debe estar aquí) donde
la forma de pago es con tarjeta (si no está con forma de pago de tarjeta, entonces habrá
pagado de otra forma, si ha pedido algo claro). La cosa es que, en la subconsulta estamos
diciendo que no está en PEDIDOS PORQUE NO HA PEDIDO NADA y que ADEMAS, SI HA PEDIDO
ALGO, lo ha pagado DE FORMA DISTINTA A CON TARJETA. El resultado:

TODOS estos y más, no los saco

todos, han hecho pedidos y han
pagado sin tarjeta.

Consultas de acción

Son las que modifican la info de las tablas, actualizándola o creando tablas nuevas a partir de
otras que ya están o eliminando info, o anexando información entre tablas.

Por ejemplo, incrementar el precio de la sección de deportes. Se crea una consulta de

actualización para esto.

La de creación de tablas, por ejemplo, si quieren solo la información de los clientes de

Barcelona, podemos pasárselo por una tabla nueva, creando una tabla nueva con los datos de
ese tipo de cliente a partir de la tabla de clientes (en esta estarán de todos los sitios de
España).
Las de datos anexados, por ejemplo, alguien nos da info de una tabla nueva que no tenemos, y
una consulta de datos anexados nos permite agregarlos.

Vamos a trabajar con comando DDL y DML. Vamos a ir viendo como son en MySQL y en
ACCESS, que son distintas.

Vamos a ACCESS primero, y queremos incrementar el precio en 10€ de todos los artículos de
deporte de la tabla PRODUCTOS. Como es Windows, nos sale mensaje de advertencia. Damos
que sí, y nos aumenta en 10€ todo lo que sea de deporte:

Si quieres deshacer esto, es hacer otra actualización, y ponemos que reste esos 10€ (lo
tenemos hecho ya en el ejemplo). En este caso, en MySQL va igual.

Hacemos otro cambio, pero esta vez cambiamos el nombre de la sección de deportes a
deportivos. En MySQL va igual:

Vamos con las de Creación de tablas: Es a partir de otra.

Imaginemos que necesitamos tener una tabla nueva con los clientes de Madrid, con el objetivo
de trabajar solo con esa tabla o para pasar esa info. Vamos a poner el ejemplo en ACCESS por
un lado, y en MySQL por otro, son distintas:
Nos indica una nueva advertencia que va a pegar 12 filas (12 clientes de Madrid) en una nueva
tabla.

En MySQL lo hacemos con CREATE TABLE.

Vamos ahora a ver las de eliminación. No vamos a ejecutar las consultas de eliminación, para
que no nos borre nada. En la pregunta de seguridad de ACCESS, damos que NO. Vamos a
eliminar los clientes de Madrid.

Otra consulta más. Vamos a eliminar todos los artículos deportivos que estén entre 50 y 100
euros:

Vuelve a salir el mensaje, solo hay 3 artículos con ese rango de precios. Decimos que NO, si
sale esto es que estamos haciéndolo bien.

Vamos a poner la hoja secundaria de Pedidos a la tabla clientes:

 1 2

4
Video 13

Con una consulta INNER JOIN vemos los clientes que si han hecho pedidos, vamos a buscarlo
solo por nombre de la empresa:

Si te fijas, el Beltrán, como ha hecho varios pedidos, sale por cada pedido que ha hecho, y a
nosotros nos interesa que no se repitan, que me saque solo a ese cliente una vez, haya hecho
1 pedido o 100. Para esto, sirven DISTINCT Y DISTINCTROW. Esto le dice que me muestra un
solo registro por empresa, y va así:

El DISTINCTROW no muestra registros repetidos. Distingue filas, mira todo el registro y si se

repite, no lo va a sacar. Vamos a verlo de MySQL, porque es mejor trabajarlo aquí porque ya
tenemos un artículo repetido. Poniendo esto delante, los repetidos no salen:
Volvemos a ACCESS. Le pedimos con este tipo de consulta, que me eliminen los clientes que no
han hecho pedidos. Tenemos que tener en cuenta el DISTINCTROW, y la consulta es INNER,
LETF o RIGHT JOIN. INNER no sirve, ni RIGHT tampoco. Tenemos que usar LEFT para que coja a
todos los que no han hecho pedidos y que son clientes:

NOTA: A partir del minuto 20 el vídeo número 13 se vuelve algo caótico. Volver a ver bien.

Datos anexados

Estas consultas consisten en usar el INSERT INTO. Vamos a verlo de forma visual:

Esto te permite anexar todos los registros o parte de los mismos de una tabla a otra. Tienen
que tener mismo tipo de datos y mismo número de campos:

Vamos a trabajar con ello. En nuestro ejemplo, tenemos la tabla clientes por un lado, y la tabla
clientesmadrid por otro. En la de clientes no estarán los clientes de Madrid.

Una consulta de datos anexados nos permite unir la info de una tabla con la otra. Vamos a
realizarlo:

Vuelve a saltar lo de la advertencia, aceptamos y los ordena por el campo clave, tal y como
estaban antes. En el vídeo se hace por MySQL también, pero yo no tengo lo de clientesmadrid
en SQL, pero voy a poner la consulta como ejemplo. MySQL NO ordena, los pone todos al final:

Ahora bien, si queremos hacer esto mismo, pero con solo unos campos específicos, hay que
especificar tanto en la parte de INSERT INTO entre () y en el SELECT sin los ():
NOTA: No podemos ignorar el campo CÓDIGOCLIENTE porque es clave, este SIEMPRE hay que
ponerlo para poder insertar.

Referencias cruzadas

Las consultas de referencias cruzadas es lo mismo que una tabla dinámica de Excel. Estas son
las partes que forman una tabla dinámica de Excel:

También son las partes que forman parte de las referencias cruzadas, tienen la misma
estructura. Podremos, de esta forma, ver el resultado de las consultas en formato de tabla,
que puede ayudar mucho a la hora de consultar muchos datos.

Vamos a implementar nuevas instrucciones y otras que ya conocemos para hacer referencia a
las partes de cada estructura de la imagen. Son las siguientes:

Combinándolas correctamente, haremos consultas de referencias cruzadas. Trabajaremos en

ACCESS porque MySQL no admite este tipo de consultas:

En esta consulta vamos a ver el nombre del artículo, la sección y el precio de cada artículo.
Podemos con una normal, o ver esta información en formato de tabla con las referencias
cruzadas. Hay un asistente dentro de ACCESS pero vamos a hacerlo en SQL.

Hay que tener en cuenta lo siguiente en referencia a esta imagen:

  Campo columnas: Pon lo que menos tenga, si salen muchas columnas será jodido de
leer. Ejemplo, sección
 Campo Totales: Aquí todo lo que sea operación matemática.
 Campo filas: Aquí, lo que más tenga, por ejemplo, si son nombres de productos ponlo
aquí

Esta agrupando todo lo que se llama igual. Por ejemplo, lo del destornillador de 15,10, es LA
SUMA DE TODOS LOS DESTORNILLADORES. Están por NOMBREARTÍCULO, asique suma todo lo
que sea igual.

Si ponemos NOMBREARTÍCULO donde está ahora la SECCIÓN y viceversa, el orden cambia,

pero el contenido es igual. Se vería así:
 Vamos a poner otro ejemplo más. En este caso, vamos cambiar la operación, vamos a hacer
que cuente precios. Es igual pero en lugar de SUM (PRECIO) le decimos COUNT (PRECIO):

Salen muchos, de algunos solo hay

una unidad, y de otros más. Está
contando por PRECIO, para
solucionarlo, hay que ponerlo por
CODIGOARTÍCULO, que es campo
clave, hay que rellenarlo SIEMPRE.

Seguimos complicándolo. Clientes está relacionada con pedidos, y así, con esto podemos ver
los pedidos que nos han hecho las empresas. Hay que antes hacer una consulta previa, que es:

Cuando queremos hacer una consulta de referencias cruzadas en la que participan DOS
TABLAS, como es en este caso, vas a tener que hacer al principio una consulta de selección
normal en la que participen las dos tablas, que estén los campos a visualizar. Tenemos que
guardar esa consulta ANTES. Una de referencia entre dos tablas directamente, el gestor de
bases de datos NO LO PERMITE:

En nuestro ejemplo, lo primero, determinar que campos quiero ver de la tabla de clientes
(EMPRESA, POBLACIÓN) y de la tabla de pedidos (FORMADEPAGO):

Esta consulta la guardamos como PREVIA. La consulta de referencia estará basada en esta
consulta PREVIA.
En la zona de filas, podemos incluir MAS DE UN CAMPO. Vamos a poner un ejemplo:

SOLO UNA TABLA, LA DE

PRODUCTOS. POR ESO SE HACE
DIRECTAMENTE SIN CONSULTA
PREVIA

DOS EN GROUP BY, POR ESO

SALEN DOS FILAS CON ESTO

DDL Creación de tablas

Estos comandos nos permiten crear tablas, eliminarlas, crear nuevos campos, etc. Ya hemos
visto los DML y ahora vamos a por los DDL:

CREATE, ALTER, DROP Y TRUNCATE.

Antes de empezar, debemos saber que en el lenguaje estándar SQL, podemos distinguir tres
tipos de tablas, que son las de la imagen:
De momento, nos centramos en las tablas base, que son las que más vamos a manejar. Más
adelante, veremos las tablas que derivan de las tablas base, aunque las PERSISTENTES son las
que hemos manejado hasta ahora.

Con el comando CREATE creamos una nueva tabla. La sintaxis es:

En cuanto al tipo de dato que va a almacenar, tenemos las siguientes categorías:

Vamos a dejar en stand by los construidos y los definidos por el usuario, y vamos a centrarnos
en los PREDEFINIDOS, que son los que hemos usado hasta ahora. Hay subtipos por cada tipo,
pero memorizarlos es un poco locura, asique nos limitaremos a buscarlos cada vez que
tengamos que utilizarlos.

Vamos a crear una nueva tabla dentro de la base de datos curso_sql_1, que llamaremos
PRUEBA y que solo tendrá un campo nombre de tipo VARCHAR con longitud de 20 caracteres:
Aquí arriba a la derecha, hay cosas que ha puesto por defecto porque no las hemos
especificado.

En ACCESS es EXACTAMENTE IGUAL, pero nos detecta que es una DDL, del resto, igual, misma
sintaxis y todo. Eso sí, no lanza ninguna aviso, solo la crea y ya.

Ahora vamos a eliminar con DROP esta tabla PRUEBAS que hemos creado. Si sigue saliendo,
refresca la página:

Procedemos ahora, a crear otra más, pero esta vez con más campos, para complicarlo un poco.
Vamos a crear una tabla para meter datos de personas, y además, en la parte del carnet
pondremos si tiene carnet o no (BOOLEAN, de tipo sí o no, true o false):

Indica el tamaño. BOOLEAN es solo un espacio, sí o no,

sale así por defecto. Edad es mayor, sale 4 por defecto.

En ACCESS es EXACTAMENTE IGUAL todo. Pero en ACCESS los tipos de datos son distintos.
Vamos a verlo con una captura:
En esta última parte, vamos a implementar un tipo de dato AUTONUMÉRICO. En ACCESS es
con el COUNTER y en MySQL con INT AUTO_INCREMENT. Vamos a probar primero con ACCESS
y luego con MySQL.

Con ACCESS creamos de nuevo la tabla PRUEBA pero le vamos a agregar lo del COUNTER con el
campo IDALUMNO:

La abrimos en Vista diseño y nos aparece que es un campo Autonumérico:

En MySQL:

Hay que asignar el campo autonumérico como PRIMARY KEY en

MySQL SIEMPRE. Si no lo hacemos, nos dará error.

Seguimos con los comandos de modificación, eliminación y agregar campos nuevos a tablas
existentes.
Empezamos a agregar campos a una tabla ya creada en ACCESS. Por ejemplo, vamos a la de
clientesmadrid. Por ejemplo, queremos agregar un campo que sea fechabaja y será del tipo
fecha-hora. Usaremos ALTER y ADD COLUMN FECHABAJA DATE. Queda así:

No nos sale advertencia de nada, pero nos indica que es de tipo definición de datos. En vista
diseño nos aparece el tipo de dato.

En este segundo ejemplo, vamos a hacerlo en MySQL. Vamos, habiendo creado una nueva
tabla con dos campos (ID y nombre) a agregar una nueva columna:

Para eliminarlo es poner ALTER TABLE Y LUEGO DROP. Si pongo solo drop, borra tabla
completa:

En ACCESS se hace igual asique no vamos a repetirlo.

Podemos alterar el tipo de dato de los campos volviendo a usar ALTER después de especificar
qué campo es el que queremos alterar. Le decimos ALTER TABLA y ALTER CAMPO:
Vamos ahora a ver cómo establecer el valor por defecto de un campo dentro de una tabla en
MySQL, SET DEFAULT, es la cláusula que vamos a usar. No todos los gestores de bases de datos
la soportan, pero podemos hacerlo a través de PHPmyAdmin:

En nuestro ejemplo, la tabla PRUEBAS2 tiene por defecto los datos NULL, quiere decir que, si
no introducimos nada, el valor por defecto es NULL y no sale nada. Crearemos un nuevo
campo, lugar de nacimiento, de tipo varchar y por defecto sale NULL:

Una vez lo tenemos y vemos que es NULL (si no, lo pones, da igual). Para pasarlo a tipo
‘DESCONOCIDO’ hacemos lo de abajo. Va entre ‘ ‘ porque es texto:

Para quitar el valor por defecto, usaremos DROP también tal cual está aquí abajo:

Vuelve a estar por defecto:

Con ACCESS esto no sirve.

Índices

Los índices sirven para buscar cosas con mayor rapidez en una base de datos. Si creas un índice
en una tabla, las búsquedas o consultas que realices en un futuro en esa tabla se hará más
rápido. El problema es que NO FORMAN PARTE DEL ESTANDAR SQL, asique cada gestor de
BBDD va a tener la suya propia. Vamos a ver cómo crear y modificar índices en un gestor de
BBDD ACCESS y en MySQL. Los tipos de índices son los siguientes:
Vamos a verlos todos, y comenzamos por los INDICES DE CLAVE PRIMARIA:

Empezaremos creando una tabla sencilla, vamos a Crear->Diseño de consulta->cerramos

abajo->SQL. La creamos con esta consulta:

En este punto, habría que especificar qué campo o campos van a ser clave primaria. Se hace
poniéndolo en la consulta así:

Luego de esto vamos a abrir la tabla EJEMPLO2 (arriba no lo pone, pero es ejemplo2) y vemos
que la clave primaria esta de forma correcta:

Se puede eliminar dándole al DNI en la tabla y luego a Clave Principal (lo del cuadro azul).

Podemos agregar una clave primaria con el comando ALTER cuando tengo la clave ya creada:
Las claves primarias pueden estar formadas por un solo campo o por varios (multicampo) y no
se pueden repetir los campos primarios:

Un solo índice, que da el nombre ACCESS

directamente, y que está compuesto de los
dos campos

Esto es lo que sale si intento repetir nombre y

apellidos al meter datos en la tabla. Las claves
primarias son para esto, no meter cosas
duplicadas. Si cambia el apellido o nombre si deja,
pero no los dos iguales. También sale error si
dejamos nombre o apellido sin rellenar

Los índices ordinarios SI PERMITEN CAMPOS VACIOS y además nulos. Nos permitirá hacer
búsquedas de forma más rápida.

Vamos a crear un índice ordinario con el apellido para hacer las búsquedas más rápido.

Nos obliga a que indiquemos el nombre del índice, a diferencia del otro, que ACCESS lo pone
de forma automática, aquí lo dejan así.
Una vez ejecutemos lo de arriba, vamos a Vista diseño, luego a INDICES y vemos que está
como índice el apellido:

Ahora si vamos a poner de todo, duplicados, distintos, mismos apellidos, no hay problema. La
única utilidad que tiene es buscar más rápido.

Seguimos con índices, esta vez serán los índices únicos. Estos permiten campos vacíos pero no
permiten duplicados. Para crearlos es así:

Vamos ahora a ver como se crea el índice compuesto. Lo forman varias columnas, y su sintaxis
es. Tiene sentido cuando no podemos tener varias personas con mismo nombre y apellidos,
pero no con las dos cosas juntas. El índice primario NO PERMITE CAMPOS VACIOS y este si, por
eso nos puede servir:
Es como el anterior, el de índice único, pero podemos poner más de un campo.

Eliminación de INDICES

Procedemos ahora a ver como se eliminan los índices. Vamos antes a crear un índice nuevo,
que será el DNI:

Vamos ahora a eliminar:

Si es multicampo o hay más de un índice, podemos hacer esto pero al final, donde pone ON
EJEMPLO2 ponemos los campos que son índices y que queremos eliminar.

Esto es más complicado con las claves primarias. Vamos a verlo:

Tenemos que buscar el nombre que ACCESS le da dado, tenemos que copiarlo y ahora si se
podría eliminar haciendo lo siguiente:

La cláusula que usamos, DROP CONSTRAINT es válida para SQL Server, Oracle y ACCESS. Más
adelante la pondremos en MySQL que es más simple:

En MySQL es tan sencillo como esto:

 TRIGGERS o DISPARADORES

Imaginemos que tenemos una BBDD y tenemos una tabla, y queremos que, al realizar una
acción concreta en esa tabla, ocurra algo, se desencadene una acción. Esto se llama EVENTO
(una acción que se desencadena cuando ocurre algo, en este caso en una tabla de BBDD).

Un trigger es un objeto que creas en tu BBDD, y siempre va a estar asociado a una tabla. En
una tabla de una BBDD pueden ocurrir en esencia tres cosas. El trigger, desencadenará una
acción cuando ocurra una de las tres cosas que señalamos:

¿Y por qué voy a necesitar esto? Imagínate que tú, como admin, necesitas llevar un registro de
quien ha añadido cosas, quien lo está haciendo y cuando lo está haciendo. Por ejemplo, en una
empresa con 20 trabajadores, necesitamos saber que trabajadores han estado introduciendo
info y cuando. Eso lo puede hacer el trigger, que desencadenará una acción después de que un
usuario haya insertado un registro en esa tabla, por ejemplo, almacena en otra tabla distinta el
nombre del usuario que lo hizo, fecha y hora, número de veces que metió información nueva,
etc. Gracias al trigger, esto será automático.

Con la acción de actualizar, por ejemplo, si lo hacemos y como sabemos, no hay vuelta atrás,
no se puede deshacer, a no ser que se realice una consulta que haga lo contrario (por ejemplo,
aumento el precio un 5%, y para deshacerlo después, tengo que hacer otra consulta para
disminuir el precio un 5%). Muchas veces, para evitar esto, se hace una acción de respaldo, y
aquí entra el trigger. Antes de realizar el cambio de precio, se copia en otra tabla como lo
teníamos antes de la actualización y luego si se procede a hacer la actualización.

Lo mismo si vas a eliminar información de una BBDD. Se crea una copia de seguridad de los
registros que se eliminaron.

Son utilizados sobre todo, para tareas de mantenimiento y administración en BBDD. Estos
triggers NO SE APLICAN EN ACCESS. En la versión 2010 crearon unas macros que simulan las
acciones comunes de un trigger, pero no son iguales. Vamos a trabajar entonces en MySQL.
Lo de la imagen de arriba, es importante determinarlo. Por ejemplo, queremos que si alguien
inserta algo en la BBDD, en esa tabla concreta, nos cree en una tabla aparte los datos del
usuario que lo registró, el código del registro o el campo y la fecha en la que inserto ese
registro. Hay que pensar, si queremos que el trigger realice la acción ANTES de hacer ese
registro en la tabla, o después. En este caso, no tiene sentido hacerlo antes, porque antes no
había nada y lo que queremos que quede registrado es la acción que va a realizar el usuario.

Vamos a ver un ejemplo de INSERT donde nos interese que sea antes. Por ejemplo, están
insertando a un cliente, están rellenando los datos y me pone que la edad es negativa. Imagina
que creamos un trigger que comprueba que la edad es positiva, aquí se tiene que ejecutar
ANTES, porque no puede dejarme insertar la información si el dato no es válido.

Por ejemplo, si son modificaciones, entonces si nos interesa que sea ANTES DE QUE SE REALICE
LA MODIFICACIÓN, porque si no, no tendríamos un respaldo, una copia de como estaba antes
de la modificación. Con la ELIMINACION es igual.

Un ejemplo más, imagina que quieres eliminar a un cliente, pero este tiene pedidos hechos y
sin cerrar. Pones un trigger que comprueba que el cliente tiene pedidos pendientes, por tanto,
ANTES de que lo elimines, se desencadena y no te va a permitir eliminarlo o te indicará que se
eliminen antes los pedidos, etc.

O lo mismo pero al revés, quieres hacer un pedido, pero cuando pones el cliente, que el trigger
te diga que no existe.

Nos vamos a MySQL, y en nuestra BBDD tenemos una tabla que se llama PRODUCTOS.
Crearemos una tabla que todavía no tenemos y guardaremos un registro de que vamos
insertando. Y una vez las tenemos, haremos un trigger asociado a la tabla de productos que lo
que va a hacer es que, después de agregar un nuevo producto (AFTER) rellena la tabla nueva
con el código, el nombre, el precio y el momento exacto de cuando se insertó.

Creamos una tabla nueva, creamos los campos que queremos, con el tipo de dato que
queremos y al final del todo, ponemos un dato llamado INSERTADO en el que va a figurar el
momento exacto de cuando se insertó.

El siguiente paso es crear un trigger asociado a la tabla de productos, de forma que, cuando
ocurra una acción en esa tabla de productos, que será insertar, y que será de tipo after,
realizará una acción:
Para nombrar a los trigger, por convención, se suele usar la siguiente nomenclatura
(nombredelatabla_cuandosevaaejecutar (letra)_instruccionarealizar(letra))-> PRODUCTOS_AI

También tenemos que indicarle si la acción se desencadenará cuando se inserte un registro,

cuando se inserten todos o varios. Esto se hace poniendo FOR EACH ROW (por cada registro) o
con FOR EACH STATEMENT (por cada sentencia, varios registros) Nosotros lo haremos por cada
uno de momento:

Lo complejo de verdad, viene a partir de lo de INSERT INTO. Tenemos que indicar INSERT INTO
en la nueva tabla de reg_productos, todos los campos que ponemos entre paréntesis, y en
esos campos, un valor nuevo en cada uno de los campos de la tabla reg_productos. Al final, en
el campo de INSERTADO no ponemos nada, en esencia porque como queremos el momento
de ahora, ponemos NOW() y ya nos saca la fecha y hora del momento exacto.

Para ver este disparador (trigger) que hemos creado, vamos a la tabla de productos, y
desplegamos como vemos en la imagen:

Vamos a probar el trigger. Metemos un nuevo registro en la tabla de productos:

Ahora comprobamos si el trigger funciona. Vamos a mirarlo en la tabla de reg_productos:

Ahora veremos los siguientes tipos de triggers:

En que consiste un trigger de actualización: -imagina una tabla de productos, con sus campos,
y vamos a ejecutar una sentencia SQL que va a actualizar un registro o un grupo de registros:

Vamos a actualizar esto, subimos el precio. Cuando

actualicemos esto, NO HAY VUELTA ATRÁS. Por eso,
Video 21
se usan los triggers de actualización, y se crea una
copia de respaldo. Para eso son los triggers de
actualización. Se ejecutan antes de actualizar y
guarda la info de antes en otra tabla.

Además en esa tabla de respaldo, podemos añadir cosas nuevas, por ejemplo, el precio que
tenía antes de la actualización y también el nuevo, el día y hora en que se cambió, que usuario
lo hizo, etc.
En este momento entran en juego
las sentencias OLD Y NEW. En
precio guardamos el dato nuevo
(NEW) y el P.Ant el viejo (OLD)

Aquí, con AFTER Y BEFORE vemos claro una cosa. No vamos a poder guardar el precio antiguo
si usamos BEFORE, asique vamos a tener que usar si o si, AFTER.

Vamos a ir viéndolo en la práctica. Tenemos que crear una nueva tabla, la que tenemos de
reg_productos no nos sirve porque tiene solo cuatro campos, y queremos trabajar con campos
tanto para datos antiguos como para datos nuevos, asique necesitamos más campos,
concretamente, un campo nuevo para cada uno de los antiguos, básicamente porque no
sabemos que campos va a modificar el usuario. También en este ejemplo, agregaremos el
campo usuario y el campo fecha-hora de actualización. Lo hacemos en PHPmyAdmin, y usamos
esta sentencia SQL:
Una vez tenemos esto, vamos con el trigger. Es otra sentencia larga:

Empezamos creando un trigger, en el que especificamos que después de actualizar la tabla

productos (BEROFE UPDATE productos) por cada fila inserta en la tabla productos actualizados
(FOR EACH ROW INSERT INTO ON productos_actualizados), los datos anteriores en las
columnas con ANT delante y además inserte también los datos nuevos en las columnas con
NEW delante. Le decimos que meta esos valores(VALUES, ESTO NOS HACE FALTA SIEMPRE
PARA INDICAR QUE SON DATOS Y QUE LOS VAMOS A METER) y usamos el mismo orden que lo
anterior, que a su vez, usa el mismo orden que las columnas ya hecha en la tabla
productos_actualizados, primero los que tienen delante ANT y luego los NEW. Finalmente
usamos la función propia de SQL CURRENT USER() para que meta el nombre del usuario que ha
hecho esa modificación en la columna correspondiente y NOW() para que deje reflejada en la
otra columna la fecha y hora de la modificación.

Una vez hecho todo esto, refrescamos la página, vamos a la tabla productos y vemos que el
trigger está creado:
El trigger de PRODUCTOS_AI, se ejecuta después de insertar (AFTER INSERT). Vamos a
modificar el precio del serrucho en la tabla productos. Se guardará el precio de antes y el
nuevo, con usuario saldrá ROOT y la hora y fecha.

Con esto, solo cambiará una fila, la del serrucho, cuyo código es AR07.

Me está dando error porque si, asique no lo vemos, pero el trigger debería dispararse con esto
y pasar a la nueva tabla los datos que configuramos en el trigger.

Trigger de eliminación

Vamos a ver cómo crear uno de eliminación. Son muy útiles para crear copias de seguridad de
registros eliminados, y además guardar la persona que lo hizo, fecha y hora. Crearemos una
nueva tabla, porque lo mejor es separar los registros eliminados de los modificados.

Creamos el trigger:
En mi ejemplo voy a eliminar el serrucho. Antes de esto saltó advertencia.

Vamos ahora a ver la tabla de productos eliminados y nos aparece esto:

Para poner quien hizo el registro y la fecha, vamos a ver como poder modificar un trigger.
También hay que modificar la tabla para que tenga los campos usuario y fecha. Empezamos
con la tabla:

El trigger se modifica desde el panel de modificación, que es gráfico y sencillo ya que solo
queremos añadir dos cosas. Si no fuera así, podemos hacerlo por sentencia SQL, pero eso
implica eliminar y volver a crear (DROP Y CREATE). Se puede poner todo en la misma sentencia,
pero en este caso vamos a hacerlo simple. Pinchamos en el trigger, y lo que se abre es el modo
edición. Hay que ponerlo en el mismo lugar y también lo del CURRENT_USER y NOW (no está
en la imagen, pero va al final de cada paréntesis):
MySQL nos da, cuanto terminamos lo de arriba, de forma automática la siguiente sentencia:

Es la forma de modificar que hemos hecho pero en sentencia SQL.

Vamos a probar eliminando el producto AR40, vamos a la tabla eliminados y comprobamos:

Esto nos aparece ahora, una

vez lo hemos agregado. No
es retroactivo, se ejecuta a
partir de cuándo lo creamos.

DROP TRIGGER IF EXIST: Esto quiere decir, si existe lo hará, si no pues no lo hace, pero
evitamos que de error, asique continua con la sentencia SQL. Sin el IF EXIST da error. La
sentencia para eliminar y volver a crear en la misma es así:

Procedimientos almacenados

¿Qué es un procedimiento almacenado?

Imaginemos que trabajamos contra una BBDD, en la cual hay varias personas con varias
aplicaciones trabajando contra esa BBDD. Imagina que esas aplicaciones, todas, hacen las
mismas tareas o muy similares, y esos usuarios (imagínate que son seis) hacen las mismas
consultas basadas en la misma tabla. En estas situaciones, es muy útil la creación de
procedimientos almacenados por dos motivos principales, de eficiencia y motivo de seguridad.

Consiste en almacenar en un procedimiento, estas instrucciones repetitivas que se ejecutan

desde diferentes aplicaciones, puestos y usuarios. Creamos en el servidor un procedimiento
con la instrucción, y después lo que tenemos que hacer, en vez de ejecutar en cada aplicación
esa instrucción SQL, únicamente llamamos a ese procedimiento desde todas las aplicaciones.
Para hacer esto, se necesitan algunos conocimientos de programación, ya que debemos saber
que es una variable, que es un parámetro, un paso de valor por parámetros, lo que es un
bucle, un condicional. Lo ideal es, que esos conocimientos de programación se tengan en
VisualBasic o PASCAL.
Vamos a crear nuestro primer procedimiento, trabajando en PHPmyAdmin. ACCESS no permite
procedimientos almacenados. En MySQL a partir de la versión 5.0.

En la consola SQL vamos a poner una consulta que nos saque todos los clientes de la población
de Madrid. Consiste en poner justo encima CREATE PROCEDURE NOMBRE_QUE_QUIERAS ():

Una vez lo ejecutamos, nos guardará el procedimiento en un nuevo apartado que aparecerá en
nuestra BBDD una vez refresquemos la página:

Si pinchamos encima de MUESTRA_CLIENTES, tenemos la opción de editarlo en este panel:

Si pinchamos encima de Procedures, nos manda a este panel, donde podemos ver los
procedimientos que tenemos y lo podremos ejecutar:
 Desde el panel visual de PHPmyAdmin, cuando ejecutamos cualquier instrucción, siempre lo
traduce al lenguaje SQL, nos indica cómo se llama a un procedimiento desde una aplicación o
desde SQL. Para llamar a un procedimiento, hay que usar la instrucción CALL, tal y como se nos
muestra en la “traducción” que vemos en el panel visual una vez le damos a ejecutar el
procedimiento:

La llamada va así:

Con esto, conseguimos que los usuarios que usan las aplicaciones tengan acceso a las
instrucciones SQL, no dejamos lugar a inyecciones o modificar el código. Solo pueden llamar a
procedimientos, lo demás, está encapsulado, protegido.

Vamos con otro ejemplo, que reciba parámetros en este caso: crearemos un procedimiento
que actualice la tabla de productos, para de esta forma, desde la llamada al procedimiento
poder cambiar el precio de un artículo en concreto.

En este caso, cuando pongamos CREATE PROCEDURE ACTUALIZA_PRODUCTOS () dentro de los

paréntesis vamos a poner parámetros, tal y como hacemos en cualquier lenguaje de
programación. Necesitamos dos parámetros, en este caso, el precio, y la clave, que aquí es
CÓDIGOARTÍCULO. Explicamos mejor con la imagen:

Como vamos a poner un nuevo precio Aquí ponemos el parámetro nuevo código,
actualizándolo, creamos este parámetro que en realidad no será nuevo, vamos a
n_precio y decimos el tipo de dato que es. cogerlo directamente de CÓDIGOARTÍCULO,
Siempre crearemos parámetros nuevos pero aquí si tiene que ser un parámetro
en estos procedimientos cuando toque. nuevo. Mantenemos el mismo tipo de dato
que es CÓDIGOARTÍCULO
Con esto de aquí ya tendremos el procedimiento hecho, lo ejecutamos y se guarda como el
anterior. Solo que ahora tiene una diferencia:

Una vez tengamos el procedimiento creado, esto tiene ahora una particularidad, y es que, a la
hora de hacer la llamada con CALL ACTUALIZA_PRODUCTO () dentro de los paréntesis, hay que
pasarle LOS DOS PARÁMETROS QUE DETERMINARÁN QUE PRECIO Y QUE PRODUCTO
QUEREMOS ACTUALIZAR. Es decir, si yo quiero poner un nuevo precio (N_PRECIO) A UN
PRODUCTO CON EL CÓDIGOARTÍCULO (CÓDIGO en el parámetro que pasamos, que ya
ponemos que es igual) tengo que especificar el precio nuevo y el código del producto sobre el
que quiero actualizar el precio, que habrá que poner entre ` ` porque es VARCHAR. Por
ejemplo:

Como vamos a poner un nuevo precio

actualizándolo, se pone tal cual por
parámetro que nos pide. El otro
parámetro es el código, que al ser
VARCHAR, texto, va entre ‘’

También podemos ejecutarlo desde el panel de procedimientos, y si le damos a ejecutar nos

pide los parámetros directamente:

Esta instrucción SQL se ejecuta en el servidor. De forma más segura gracias a los
procedimientos, ya que no saben cómo está construida la instrucción.

Junto con los trigger, podemos crear uno que bajo un evento en concreto, se ejecute un
procedimiento almacenado, que puede tener dentro varias acciones a realizar.
En este penúltimo vídeo, vamos a ver lo siguiente:

En PHPMyAdmin vamos a crear un procedimiento nuevo. La utilidad que va a tener es poco

práctica, es para que se entiendan bien algunas estructuras importantes que podemos crear en
un procedimiento, como por ejemplo, la declaración de variables o lo que es, un bloque de
ejecución.

Vamos a crear un procedimiento almacenado que sea capaz de sacar la edad en función del
año de nacimiento que nosotros le pasemos por parámetro:

En este caso, vamos a poner más de una instrucción de código. Si vamos a poner varias,
tenemos que indicarle al procedimiento donde comienza la instrucción y donde acaba, esto se
hace poniendo BEGIN y END. Para declarar una variable dentro del bloque de código, le
añadimos DECLARE y el nombre de la variable y el tipo. Podemos ponerle un DEFAULT como
aquí, o no. En la del año actual si hace falta ponerlo.

En este bloque, todo debe acabar con ; , y es el DELIMITADOR. También hace falta un
DELIMITADOR DE BLOQUE, y necesita otro delimitador. Para no confundirnos, se declara con la
función delimiter arriba del todo y poniendo un símbolo por dos ($$, //, @@, etc). Luego lo
añadimos al final del bloque, junto con un DELIMITER ; más. Fijarse en la imagen:

Una vez le damos a Go, lo guardamos, en el panel de edición lo vemos:

Si vamos al panel, y pinchamos en PROCEDURES, luego en ejecutar el de CALCULA_EDAD, nos
lleva aquí, nos pide que metamos un entero para hacer el cálculo de dentro:

Procedimientos y triggers

Vamos a crear trigger condicionales. Imaginemos que queremos crear un trigger para nuestra
tabla de productos. Imaginemos que es frecuente que, en nuestra tabla hagamos
actualizaciones de precio, pero de alguna forma queremos establecer un control en nuestros
precios, y que no se puedan realizar actualizaciones con precios disparatados, y que no se
pueda poner un precio en negativo. Vamos a tener que comprobar antes (BEFORE) de
actualizar, que el precio este entre 0 y 1000, si es así, nos ejecutará el UPDATE. Si no, lo dejará
como esta. Si quieres cambiar el precio a más de 1000, no lo hará, y dejará puesto los 1000.

Aquí ponemos que si el precio se pone en negativo, lo cambie a cero

Aquí ponemos que si el precio se pone +1000, lo pone en 1000.

End del IF. Usamos else if. El delimiter en necesario para los triggers de
este tipo.

Una vez esto esté guardado, el trigger se ejecutará cuando queramos hacer alguna
actualización de los precios. Si no se cumple lo del negativo o más de 1000, no se dispara.

Vistas

Las vistas son similares a una consulta de ACCESS. Las ventajas que tiene es la privacidad de la
información.
Vamos a crear una vista con el gestor de datos MySQL. No son exclusivas de MySQL, pero
ACCESS no tiene vistas.

Nos va a mostrar una serie de artículos. La vista es una especie de acceso directo. Esta nos
ofrece tres columnas, que son las que necesitamos ver en cada momento.

Lo que vemos es una nueva sección que sale a la izquierda (View):

La gran ventaja, es la consulta de las tablas y lo que nos interesa de ellas, sin estar haciendo
consultas o entrando en cada tabla y verlo todo. Son actualizables, si cambiamos algo, se
reflejará aquí. Vamos a la tabla productos nuevos:
Vamos ahora a crear otra vista que nos muestre solo los artículos de cerámica:

Vid

Para eliminarlas, el comando a usar es DROP:

Y algunos gestores de BBDD soportan la modificación de las Vistas. PhpMyAdmin es uno de

ellos, asique vamos a probarlo. En la vista art_deportes, vamos a poner que quiero que me
muestra ahora los artículos de deporte en España:

Todo esto, ahora es practicarlo. Por ejemplo, con JAVA, se puede empezar a ver JDBC, y se
necesita SQL para poder acceder a los datos. Vamos a tener que usar mucho Internet para
buscar las instrucciones, pero sabiendo SQL, ya entendemos lo que sea que encontremos.