UNEFA Ingeniera en Sistemas Laboratorio de Base de Datos Laboratorio N3: Integridad referencial en MySQL Funciones y Stored Procedures Triggers

Objetivo: Cuando culmine este laboratorio el estudiante estar en la capacidad de crear, eliminar y cambiar claves primarias y forneas, gestionar y recuperar datos ms rpidamente por medio de la creacin de ndices en las tablas de la base de datos, y analizar el rendimiento de los ndices creados. Adems conocer las caractersticas principales de los procedimientos almacenados y triggers, el uso que se le puede dar y cmo se definen. Integridad referencial en MySQL
MySQL soporta cinco tipos de tablas: MyISAM, ISAM, HEAP, BDB (Base de datos Berkeley), e InnoDB. BDB e InnoDB son ambas tipos de tablas transaccionales. Adems de poder trabajar con transacciones en MySQL, las tablas del tipo InnoDB tambin tienen soporte para la definicin de claves forneas, por lo que se nos permite definir reglas o restricciones que garanticen la integridad referencial de los registros. A partir de la versin 4.0, MySQL ha agregado InnoDB a la lista de tipos de tablas soportados en una instalacin tpica. Nota: para asegurarnos que tenemos soporte para el tipo de tablas InnoDB podemos ejecutar la siguiente sentencia: mysql> SHOW VARIABLES LIKE '%innodb%'; +---------------------------------+------------------------+ | Variable_name | Value | +---------------------------------+------------------------+ | have_innodb | YES | | innodb_additional_mem_pool_size | 1048576 | | innodb_buffer_pool_size | 8388608 |

| innodb_data_file_path | ibdata1:10M:autoextend | | innodb_data_home_dir | | | innodb_file_io_threads | 4 | | innodb_force_recovery | 0 | | innodb_thread_concurrency | 8 | | innodb_flush_log_at_trx_commit | 1 | | innodb_fast_shutdown | ON | | innodb_flush_method | | | innodb_lock_wait_timeout | 50 | | innodb_log_arch_dir | . | | innodb_log_archive | OFF | | innodb_log_buffer_size | 1048576 | | innodb_log_file_size | 5242880 | | innodb_log_files_in_group | 2 | | innodb_log_group_home_dir | . | | innodb_mirrored_log_groups | 1 | | innodb_max_dirty_pages_pct | 90 | +---------------------------------+------------------------+ 20 rows in set (0.00 sec) La variable ms importante es por supuesto have_innodb que tiene el valor YES. Claves primarias Para entender lo que son las claves forneas, tal vez sea necesario entender primero lo que son las claves primarias. Es un hecho que las claves juegan un papel muy importante no slo en MySQL, sino en cualquier base de datos relacional. De manera simple, las claves proporcionan una manera rpida y eficiente de buscar datos en una tabla, adems de que permiten preservar la integridad de los datos. Una clave candidata es un campo, o una combinacin de campos, que identifican de manera nica un registro de una tabla. stas no pueden contener valores nulos, y su valor debe ser nico. Una clave primaria es una clave candidata que ha sido diseada para identificar de manera nica a los registros de una tabla a travs de toda la estructura de la base de datos. La seleccin de una clave primaria es muy importante en el diseo de una base de datos, ya que es un elemento clave de los datos que facilita la unin de tablas y el concepto total de una base de datos relacional.

Las claves primarias deben ser nicas y no nulas, de manera que garanticen que una fila de una tabla pueda ser siempre referenciada a travs de su clave primaria. MySQL requiere que se especifique NOT NULL para las columnas que se van a utilizar como claves primarias al momento de crear una tabla. Claves forneas e integridad referencial Podemos decir de manera simple que integridad referencial significa que cuando un registro en una tabla haga referencia a un registro en otra tabla, el registro correspondiente debe existir. Por ejemplo, consideremos la relacin entre una tabla cliente y una tabla venta. +------------+ | cliente | +------------+ | id_cliente | | nombre | +------------+ +-------------+ | venta | +-------------+ | id_factura | | id_cliente | | cantidad | +-------------+ Para poder establecer una relacin entre dos tablas, es necesario asignar un campo en comn a las dos tablas. Para este ejemplo, el campo id_cliente existe tanto en la tabla cliente como en la tabla venta. La mayora de las veces, este campo en comn debe ser una clave primaria en alguna de las tablas. Vamos a insertar algunos datos en estas tablas.

Tabla cliente +------------+--------------+ | id_cliente | nombre | +------------+--------------+ | 1 | Juan penas | | 2 | Pepe el Toro | +------------+--------------+ Tabla venta +------------+------------+----------+ | id_factura | id_cliente | cantidad | +------------+------------+----------+ | 1 | 1 | 23 | | 2 | 3 | 39 | | 3 | 2 | 81 | +------------+------------+----------+

Hay dos registros en la tabla cliente, pero existen 3 id_cliente distintos en la tabla venta. Habamos dicho que las dos tablas se relacionan con el campo id_cliente, por lo tanto, podemos decir que Juan Penas tiene una cantidad de 23, y Pepe el Toro 81, sin embargo, no hay un nombre que se corresponda con el id_cliente 3. Las relaciones de claves forneas se describen como relaciones padre/hijo (en nuestro ejemplo, cliente es el padre y venta es el hijo), y se dice que un registro es hurfano cuando su padre ya no existe. Cuando en una base de datos se da una situacin como esta, se dice que se tiene una integridad referencial pobre (pueden existir otra clase de problemas de integridad). Generalmente esto va ligado a un mal diseo, y puede generar otro tipo de problemas en la base de datos, por lo tanto debemos evitar esta situacin siempre que sea posible. En el pasado, MySQL no se esforzaba en evitar este tipo de situaciones, y la responsabilidad pasaba a la aplicacin. Para muchos desarrolladores, esta no era una situacin del todo grata, y por lo tanto no se consideraba a MySQL para ser usado en sistemas "serios". Por supuesto, esta fue una de las cosas ms solicitadas en las anteriores versiones de MySQL; que se tuviera soporte para claves forneas, para que MySQL mantenga la integridad referencial de los datos. Una clave fornea es simplemente un campo en una tabla que se corresponde con la clave primaria de otra tabla. Para este ejemplo, el campo id_cliente en la tabla venta es la clave fornea. Ntese que este campo se corresponde con el campo id_cliente en la tabla cliente, en dnde este campo es la clave primaria. Las claves forneas tienen que ver precisamente con la integridad referencial, lo que significa que si una clave fornea contiene un valor, ese valor se refiere a un registro existente en la tabla relacionada.

Claves forneas en MySQL Estrictamente hablando, para que un campo sea una clave fornea, ste necesita ser definido como tal al momento de crear una tabla. Se pueden definir claves forneas en cualquier tipo de tabla de MySQL, pero nicamente tienen sentido cuando se usan tablas del tipo InnoDB.

A partir de la versin 3.23.43b, se pueden definir restricciones de claves forneas con el uso de tablas InnoDB. InnoDB es el primer tipo de tabla que permite definir estas restricciones para garantizar la integridad de los datos. Para trabajar con claves forneas, necesitamos hacer lo siguiente: Crear ambas tablas del tipo InnoDB. Usar la sintaxis FOREIGN KEY(campo_fk) REFERENCES nombre_tabla (nombre_campo) Crear un ndice en el campo que ha sido declarado clave fornea.

InnoDB no crea de manera automtica ndices en las claves forneas o en las claves referenciadas, as que debemos crearlos de manera explcita. Los ndices son necesarios para que la verificacin de las claves forneas sea ms rpida. A continuacin se muestra como definir las dos tablas de ejemplo con una clave fornea. CREATE TABLE cliente ( id_cliente INT NOT NULL, nombre VARCHAR(30), PRIMARY KEY (id_cliente) ) TYPE = INNODB; CREATE TABLE venta ( id_factura INT NOT NULL, id_cliente INT NOT NULL, cantidad INT, PRIMARY KEY(id_factura), INDEX (id_cliente), FOREIGN KEY (id_cliente) REFERENCES cliente(id_cliente) ) TYPE = INNODB; La sintaxis completa de una restriccin de clave fornea es la siguiente: [CONSTRAINT smbolo] FOREIGN KEY (nombre_columna, ...) REFERENCES nombre_tabla (nombre_columna, ...) [ON DELETE {CASCADE | SET NULL | NO ACTION | RESTRICT}] [ON UPDATE {CASCADE | SET NULL | NO ACTION | RESTRICT}]

Las columnas correspondientes en la clave fornea y en la clave referenciada deben tener tipos de datos similares para que puedan ser comparadas sin la necesidad de hacer una conversin de tipos. El tamao y el signo de los tipos enteros debe ser el mismo. En las columnas de tipo carcter, el tamao no tiene que ser el mismo necesariamente. Si MySQL da un error cuyo nmero es el 1005 al momento de ejecutar una sentencia CREATE TABLE, y el mensaje de error se refiere al nmero 150, la creacin de la tabla fall porque la restriccin de la clave fornea no se hizo de la manera adecuada. De la misma manera, si falla una sentencia ALTER TABLE y se hace referencia al error nmero 150, esto significa que la definicin de la restriccin de la clave fornea no se hizo adecuadamente. A partir de la versin 4.0.13 de MySQL, se puede usar la sentencia SHOW INNODB STATUS para ver una explicacin detallada del ltimo error que se gener en relacin a la definicin de una clave fornea. Si en una tabla, un registro contiene una clave fornea con un valor NULO, significa que no existe ninguna relacin con otra tabla. A partir de la versin 3.23.50, se pueden agregar restricciones de clave fornea a una tabla con el uso de la sentencia ALTER TABLE. La sintaxis es: ALTER TABLE nombre_tabla ADD [CONSTRAINT smbolo] FOREIGN KEY(...) REFERENCES otra_tabla(...) [acciones_ON_DELETE][acciones_ON_UPDATE] Por ejemplo, la creacin de la clave fornea en la tabla venta que se mostr anteriormente pudo haberse hecho de la siguiente manera con el uso de una sentencia ALTER TABLE: CREATE TABLE venta ( id_factura INT NOT NULL, id_cliente INT NOT NULL, cantidad INT, PRIMARY KEY(id_factura), INDEX (id_cliente) ) TYPE = INNODB; ALTER TABLE venta ADD FOREIGN KEY(id_cliente) REFERENCES cliente(id_cliente);

En las versiones 3.23.50 y menores no deben usarse las sentencias ALTER TABLE o CREATE INDEX en tablas que ya tienen definidas restricciones de claves forneas o bien, que son referenciadas en restricciones de claves forneas: cualquier sentencia ALTER TABLE elimina todas las restricciones de claves forneas definidas para la tabla. No debe usarse una sentencia ALTER TABLE en una tabla que est siendo referenciada, si se quiere modificar el esquema de la tabla, se recomienda eliminar la tabla y volverla a crear con el nuevo esquema. Cuando MySQL hace un ALTER TABLE, puede que use de manera interna un RENAME TABLE, y por lo tanto, se confundan las restricciones de clave fornea que se refieren a la tabla. Esta restriccin aplica tambin en el caso de la sentencia CREATE INDEX, ya que MySQL la procesa como un ALTER TABLE. Cuando se ejecute un script para cargar registros en una base de datos, es recomendable agregar las restricciones de claves forneas va un ALTER TABLE. De esta manera no se tiene el problema de cargar los registros en las tablas de acuerdo a un orden lgico (las tablas referenciadas deberan ir primero).

Insercin de registros con claves forneas La integridad referencial se puede comprometer bsicamente en tres situaciones: cuando se est insertando un nuevo registro, cuando se est eliminando un registro, y cuando se est actualizando un registro. La restriccin de clave fornea que hemos definido se asegura que cuando un nuevo registro sea creado en la tabla venta, ste debe tener su correspondiente registro en la tabla cliente. Una vez que hemos creado las tablas, se insertan algunos datos que sirvan para demostrar algunos conceptos importantes: mysql> INSERT INTO cliente VALUES(1,'Juan Penas'); Query OK, 1 row affected (0.05 sec) mysql> INSERT INTO cliente VALUES(2,'Pepe el toro'); Query OK, 1 row affected (0.05 sec) mysql> INSERT INTO venta VALUES(1,1,23); Query OK, 1 row affected (0.03 sec) mysql> INSERT INTO venta VALUES(3,2,81); Query OK, 1 row affected (0.03 sec)

En este momento no hay ningn problema, sin embargo, vamos a ver que sucede cuando se intenta insertar un registro en la tabla venta que se refiera a un cliente no existente cuyo id_cliente es 3: mysql> INSERT INTO venta VALUES(2,3,39); ERROR 1216: Cannot add or update a child row: a foreign key constraint fails El hecho es que MySQL no permite insertar este registro, ya que el cliente cuyo id_cliente es 3 no existe. La restriccin de clave fornea asegura que los datos mantienen su integridad. Sin embargo, qu sucede cuando se elimina algn registro? Vamos a agregar un nuevo cliente, y un nuevo registro en la tabla venta, posteriormente eliminaremos el registro de nuestro tercer cliente: mysql> INSERT INTO cliente VALUES(3,'Pepe pecas'); Query OK, 1 row affected (0.05 sec) mysql> INSERT INTO venta VALUES(2,3,39); Query OK, 1 row affected (0.05 sec) mysql> DELETE FROM cliente WHERE id_cliente=3; ERROR 1217: Cannot delete or update a parent row: a foreign key constraint fails Debido a nuestra restriccin de clave fornea, MySQL no permite que se elimine el registro de cliente cuyo id_cliente es 3, ya que se hace referencia a ste en la tabla venta. De nuevo, se mantiene la integridad de los datos. Sin embargo existe una forma en la cual podramos hacer que la sentencia DELETE se ejecute de cualquier manera, y la veremos brevemente, pero primero necesitamos saber cmo eliminar (quitar) una clave fornea.

Eliminar una clave fornea No se puede slo eliminar una restriccin de clave fornea como si fuera un ndice ordinario. Veamos que sucede cuando se intenta. mysql> ALTER TABLE venta DROP FOREIGN KEY; ERROR 1005: Can't create table '.test#sql-228_4.frm' (errno: 150)

Para eliminar la clave fornea se tiene que especificar el ID que ha sido generado y asignado internamente por MySQL a la clave fornea. En este caso, se puede usar la sentencia SHOW CREATE TABLE para determinar dicho ID. mysql> SHOW CREATE TABLE venta;
+--------+------------------------------------------------------+ | Table | Create Table | +--------+------------------------------------------------------+ | venta | CREATE TABLE 'venta' ( | | | 'id_factura' int(11) NOT NULL default '0', | | | 'id_cliente' int(11) NOT NULL default '0', | | | 'cantidad' int(11) default NULL, | | | PRIMARY KEY ('id_factura'), | | | KEY 'id_cliente' ('id_cliente'), | | | CONSTRAINT 'venta_ibfk_1' FOREIGN KEY ('id_cliente')| | | REFERENCES 'cliente' ('id_cliente') ) TYPE=InnoDB | +--------+------------------------------------------------------+

1 row in set (0.00 sec) En este ejemplo, la restriccin tiene el ID 0_22 (es muy probable que este valor sea diferente en cada caso). mysql> ALTER TABLE venta DROP FOREIGN KEY venta_ibfk_1; Query OK, 3 rows affected (0.23 sec) Records: 3 Duplicates: 0 Warnings: 0 Eliminar registros con claves forneas Una de las principales bondades de las claves forneas es que permiten eliminar y actualizar registros en cascada. Con las restricciones de clave fornea podemos eliminar un registro de la tabla cliente y a la vez eliminar un registro de la tabla venta usando slo una sentencia DELETE. Esto es llamado eliminar en cascada, en donde todos los registros relacionados son eliminados de acuerdo a las relaciones de clave fornea. Una alternativa es no eliminar los registros relacionados, y poner el valor de la clave fornea a NULL (asumiendo que el campo puede tener un valor nulo). En nuestro caso, no podemos poner el valor de nuestra clave fornea id_cliente en la tabla venta, ya que se ha definido como NOT NULL. Las opciones estndar cuando se elimina un registro con clave fornea son: ON DELETE RESTRICT ON DELETE NO ACTION ON DELETE SET DEFAULT

ON DELETE CASCADE ON DELETE SET NULL

ON DELETE RESTRICT es la accin predeterminada, y no permite eliminar el registro si existe un registro asociado, como se mostr en el ejemplo anterior. ON DELETE NO ACTION hace lo mismo. ON DELETE SET DEFAULT actualmente no funciona en MySQL - se supone que pone el valor de la clave fornea al valor por omisin (DEFAULT) que se defini al momento de crear la tabla. Si se especifica ON DELETE CASCADE, y una fila en la tabla padre es eliminada, entonces se eliminarn las filas de la tabla hijo cuya clave fornea sea igual al valor de la clave referenciada en la tabla padre. Esta accin siempre ha estado disponible en MySQL. Si se especifica ON DELETE SET NULL, las filas en la tabla hijo son actualizadas automticamente poniendo en las columnas de la clave fornea el valor NULL. Si se especifica una accin SET NULL, debemos asegurarnos de no declarar las columnas en la tabla como NOT NULL. A continuacin se muestra un ejemplo de la tcnica de eliminar en cascada: mysql> ALTER TABLE venta ADD FOREIGN KEY(id_cliente)REFERENCES cliente(id_cliente) ON DELETE CASCADE; Query OK, 3 rows affected (0.23 sec) Records: 3 Duplicates: 0 Warnings: 0 Vamos a ver cmo estn los registros antes de ejecutar la sentencia DELETE: mysql> SELECT * FROM cliente; +------------+--------------+ | id_cliente | nombre | +------------+--------------+ | 1 | Juan Penas | | 2 | Pepe el toro | | 3 | Pepe pecas | +------------+--------------+ 3 rows in set (0.00 sec) mysql> SELECT * FROM venta; +------------+------------+----------+

| id_factura | id_cliente | cantidad | +------------+------------+----------+ | 1 | 1 | 23 | | 2 | 3 | 39 | | 3 | 2 | 81 | +------------+------------+----------+ 3 rows in set (0.00 sec) Ahora eliminaremos a Pepe Pecas de la base de datos: mysql> DELETE FROM cliente WHERE id_cliente=3; Query OK, 1 row affected (0.05 sec)

mysql> SELECT * FROM venta; +------------+------------+----------+ | id_factura | id_cliente | cantidad | +------------+------------+----------+ | 1 | 1 | 23 | | 3 | 2 | 81 | +------------+------------+----------+ 2 rows in set (0.00 sec) mysql> SELECT * FROM cliente; +------------+--------------+ | id_cliente | nombre | +------------+--------------+ | 1 | Juan Penas | | 2 | Pepe el toro | +------------+--------------+ 2 rows in set (0.00 sec) Con la tcnica de eliminar en cascada, se ha eliminado el registro de la tabla venta al que estaba relacionado Pepe Pecas. Actualizacin de registros con claves forneas Las opciones correspondientes a ON UPDATE estn disponibles a partir de la versin 4.0.8. Estas opciones son muy similares cuando se ejecuta una sentencia UPDATE, en lugar de una sentencia DELETE. Estas son: ON UPDATE CASCADE ON UPDATE SET NULL

ON UPDATE RESTRICT

Vamos a ver un ejemplo, pero antes que nada, tenemos que eliminar la restriccin de clave fornea (debemos usar el ID especfico de nuestra tabla). mysql> ALTER TABLE venta DROP FOREIGN KEY 0_26; Query OK, 2 rows affected (0.22 sec) Records: 2 Duplicates: 0 Warnings: 0 mysql> ALTER TABLE venta ADD FOREIGN KEY(id_cliente) REFERENCES cliente(id_cliente) ON DELETE RESTRICT ON UPDATE CASCADE; Query OK, 2 rows affected (0.22 sec) Records: 2 Duplicates: 0 Warnings: 0 NOTA: Se debe especificar ON DELETE antes de ON UPDATE, ya que de otra manera se recibir un error al definir la restriccin. Ahora est lista la clave fornea para una actualizacin en cascada. Este es el ejemplo:

mysql> SELECT * FROM venta; +------------+------------+----------+ | id_factura | id_cliente | cantidad | +------------+------------+----------+ | 1 | 1 | 23 | | 3 | 2 | 81 | +------------+------------+----------+ 2 rows in set (0.00 sec) mysql> UPDATE cliente SET id_cliente=10 WHERE id_cliente=1; Query OK, 1 row affected (0.05 sec) Rows matched: 1 Changed: 1 Warnings: 0 mysql> SELECT * FROM venta; +------------+------------+----------+ | id_factura | id_cliente | cantidad | +------------+------------+----------+ | 1 | 10 | 23 | | 3 | 2 | 81 | +------------+------------+----------+

2 rows in set (0.00 sec) En este caso, al actualizar el valor de id_cliente en la tabla cliente, se actualiza de manera automtica el valor de la clave fornea en la tabla venta. Esta es la actualizacin en cascada. ndices y Optimizacin de consultas Hacer que una consulta trabaje es una cosa, pero obtener una consulta que trabaje lo ms rpidamente es otra muy diferente. Podemos acelerar nuestras consultas de dos maneras bsicamente, una de ellas es afinando nuestro servidor para que responda lo mejor posible, y la otra es haciendo uso de los ndices de una manera inteligente. Los ndices son usados para encontrar rpidamente los registros que tengan un determinado valor en alguna de sus columnas. Sin un ndice, MySQL tiene que iniciar con el primer registro y leer a travs de toda la tabla para encontrar los registros relevantes. An en tablas pequeas, de unos 1000 registros, es por lo menos 100 veces ms rpido leer los datos usando un ndice, que haciendo una lectura secuencial. Cuando MySQL trata de responder una consulta, examina una variedad de estadsticas acerca de los datos y decide como buscar los datos que se desean de la manera ms rpida. Sin embargo, como se acaba de mencionar, cuando en una tabla no existen ndices en los cuales pueda auxiliarse MySQL para resolver una consulta se tendrn que leer todos los registros de la tabla de manera secuencial. Esto es comnmente llamado un "escaneo completo de una tabla", y es muchas veces algo que se debe evitar. En particular, debemos evitar los escaneos completos de tablas por las siguientes razones: tabla es insignificante cuando se tienen pocos datos, pero puede convertirse en un problema a medida que va aumentando la cantidad de registros en nuestra tabla. Existe una relacin proporcional entre el nmero de registros que tiene una tabla y la cantidad de tiempo que le toma a MySQL revisarla completamente. Concurrencia. Mientras MySQL est leyendo los datos de una tabla, ste la bloquea, de tal manera que nadie ms puede escribir en ella, aunque si pueden leerla. Cuando MySQL est actualizando o eliminando filas de una tabla, ste la bloquea, y por lo tanto nadie puede al menos leerla.

Sobrecarga de CPU. El proceso de verificar cada uno de los registros en una

Sobrecarga de disco. En una tabla muy grande, un escaneo completo

consume una gran cantidad de entrada/salida en el disco. Esto puede alentar significativamente el servidor de bases de datos, especialmente si se tiene un disco IDE algo antiguo.

En resumen, lo mejor es tratar de que los escaneos completos de tablas sean mnimos, especialmente si nuestra aplicacin necesita escalabilidad en tamao, nmero de usuarios, o ambos. Es en estos casos donde la indexacin puede ayudarnos. De manera simple, un ndice le permite a MySQL determinar si un valor dado coincide con cualquier fila en una tabla. Cuando indexamos una columna en particular, MySQL crea otra estructura de datos (un ndice) que usa para almacenar informacin extra acerca de los valores en la columna indexada. Los valores indexados son llamados frecuentemente claves. Aunque esta es la manera simple de explicar los ndices, realmente es un poco ms complejo, ya que MySQL almacena todas las claves del ndice en una estructura de datos de rbol. Esta estructura de datos de rbol le permite a MySQL encontrar claves muy rpidamente. Cuando MySQL encuentre que hay un ndice en una columna, lo usar en vez de hacer un escaneo completo de la tabla. Esto reduce de manera importante los tiempos de CPU y las operaciones de entrada/salida en disco, a su vez que se mejora la concurrencia porque MySQL bloquear la tabla nicamente para obtener las filas que necesite (en base a lo que encontr en el ndice). Cuando tenemos grandes cantidades de datos en nuestras tablas, la mejora en la obtencin de los datos puede ser muy significativa. Creacin de ndices Existen cuatro tipos de ndices que podemos utilizar en MySQL; de clave primaria, nicos, de texto completo, y ordinarios. Cada uno de ellos ser explicado a continuacin.

ndices de clave prim aria

Una clave primaria es un ndice sobre uno o ms campos donde cada valor es nico y ninguno de los valores son NULL. Para crear un ndice de clave primaria tenemos bsicamente dos opciones:

1. Crear el ndice de clave primaria al momento de crear la tabla. En este caso se usa la opcin PRIMARY KEY al final de la definicin de los campos, con una lista de los campos que sern parte del ndice. CREATE TABLE nombreTabla(campo1 tipoDato, [campo2...,] PRIMARY KEY (campo1 [,campo2...]) ); Hacemos nfasis en que la palabra clave NOT NULL es obligatoria para un campo cuando ste vaya a formar parte de una clave primaria; como mencionamos anteriormente, las claves primarias no pueden contener valores nulos. Si intentamos crear una clave primaria sobre un campo nulo, MySQL marcar un error.
2.

Crear una clave primaria en una tabla existente con el uso del comando ALTER TABLE: ALTER TABLE nombreTabla ADD PRIMARY KEY(campo1 [,campo2...]); Por ejemplo, suponiendo que ya tenemos en nuestro sistema una tabla que fue creada de la siguiente manera (sin clave primaria, y con el campo id aceptando valores NULL): CREATE TABLE usuarios(id int, nombre varchar(50), apellidos varchar(70)); Podemos crear una clave primaria sobre el campo id con esta sentencia: ALTER TABLE usuarios MODIFY id INT NOT NULL, ADD PRIMARY KEY(id); Para observar los cambios que hemos hecho, podemos examinar las columnas de la tabla usuarios con una sentencia DESCRIBE: mysql> DESCRIBE usuarios;
+-----------+-------------+------+-----+---------+-------+ | Field | Type | Null | Key | Default | Extra | +-----------+-------------+------+-----+---------+-------+ | id | int(11) | | PRI | 0 | | | nombre | varchar(50) | YES | | NULL | | | apellidos | varchar(70) | YES | | NULL | | +-----------+-------------+------+-----+---------+-------+

3 rows in set (0.00 sec)

El campo id no tiene un valor YES en la columna Null, lo que indica que este campo ya no podr almacenar valores nulos. Se puede observar tambin que se tiene un valor PRI en la columna Key, lo que indica que este campo es una clave primaria. Las claves primarias pueden constar de ms de un campo. Hay algunas veces en las que un solo campo no puede identificar de manera nica a un registro.

ndices ordinarios
Un ndice que no es primario permite valores duplicados (a menos que los campos hayan sido especificados como UNIQUE). Para crear un ndice ordinario tenemos bsicamente dos opciones: 1. Podemos crear un ndice ordinario al mismo tiempo que creamos la tabla con el uso de la opcin INDEX.

CREATE TABLE nombreTabla(campo1 tipoDato, campo2 tipoDato,.. INDEX [nombreIndice] (campo1 [,campo2...])); 2. De igual manera, podemos crear el ndice con el uso de la sentencia ALTER TABLE si es que la tabla ya existe.

ALTER TABLE nombreTabla ADD INDEX [nombreIndice] (campo1 [,campo2...]); Tambin es posible usar la sentencia CREATE INDEX para crear un ndice en una tabla existente. CREATE INDEX nombreIndice ON nombreTabla(campo1 [,campo2...]); Ambas sentencias piden el nombre del ndice, sin embargo con la sentencia CREATE INDEX el nombre es obligatorio. Por ejemplo, para la siguiente definicin de tabla: CREATE TABLE usuarios(id int, nombre varchar(50), apellidos varchar(70));

Se puede crear un ndice en la columna apellidos con una sentencia ALTER TABLE: ALTER TABLE usuarios ADD INDEX idx_apellidos (apellidos); O bien, con una sentencia CREATE INDEX: CREATE INDEX idx_apellidos ON usuarios(apellidos);

ndices de texto com pleto

Los ndices de texto completo son del tipo FULLTEXT, se usan en tablas del tipo MyISAM, y pueden contener uno o ms campos del tipo CHAR, VARCHAR y TEXT. Un ndice de texto completo est diseado para facilitar y optimizar la bsqueda de palabras clave en tablas que tienen grandes cantidades de informacin en campos de texto. Para crear un ndice de texto completo tenemos bsicamente dos opciones: 1. Crear el ndice al momento de crear la tabla. CREATE TABLE nombreTabla( campo1 TIPO, campo2 TIPO, FULLTEXT [nombreIndice] (campo1 [campo2,...]) ); 2. Crear el ndice una vez que ha sido creada la tabla. ALTER TABLE nombreTabla ADD FULTEXT [nombreIndice] (campo1 [,campo2,...]); La siguiente sentencia tambin se puede usar para crear un ndice cuando la tabla ya existe. CREATE FULLTEXT INDEX nombreIndice ON nombreTabla(campo1 [,campo2,...]); nicamente para fines ilustrativos, consideremos la siguiente definicin de tabla: CREATE TABLE usuarios(id int, nombre varchar(50), apellidos varchar(70)); Podramos crear un ndice FULLTEXT en la columna nombre, en la columna apellidos, o bien, un ndice que ocupe ambos campos. A continuacin se muestran los tres casos.

CREATE FULLTEXT INDEX idx_nombre ON usuarios(nombre); CREATE FULLTEXT INDEX idx_apellidos ON usuarios(apellidos); CREATE FULLTEXT INDEX idx_nombre_apellidos ON usuarios(nombre,apellidos); Nota: Cuando se tienen grandes cantidades de datos, es mucho ms rpido cargar los datos en una tabla que no tiene ndices de texto completo y despus crear los ndices necesarios, ya que la carga de datos en una tabla que ya tiene ndices de este tipo es un proceso lento.

ndices nicos
Los ndices nicos son bsicamente como los ndices ordinarios, excepto que los valores duplicados no son permitidos. Para crear un ndice UNIQUE se tienen bsicamente dos opciones: 1. Crear un ndice nico cuando la tabla es creada con el uso de la opcin UNIQUE. CREATE TABLE nombreTabla(campo1 tipoDato, campo2 tipoDato,.. UNIQUE [nombreIndice] (campo1 [,campo2...])); 2. O bien, si la tabla ya existe, se usa la sentencia ALTER TABLE.

ALTER TABLE nombreTabla ADD UNIQUE [nombreIndice] (campo1, campo2) ... De igual manera, tambin es posible usar la sentencia CREATE INDEX para crear un ndice nico en una tabla existente. CREATE UNIQUE INDEX nombreIndice ON nombreTabla(campo1 [,campo2...]); nicamente para fines ilustrativos, consideremos de nuevo la siguiente definicin de tabla: CREATE TABLE usuarios(id int, nombre varchar(50), apellidos varchar(70));

Podramos crear un ndice UNIQUE en la columna nombre, y un ndice UNIQUE en la columna apellidos. ALTER TABLE usuarios ADD UNIQUE idx_nombre (nombre); CREATE UNIQUE INDEX idx_apellidos ON usuarios(apellidos); En el primer caso hacemos uso del comando ALTER TABLE, y en el segundo caso creamos el ndice con la sentencia CREATE INDEX.

ndices com puestos

Los ndices compuestos son simplemente aquellos que estn basados en mltiples columnas. MySQL nicamente usa un ndice por tabla cuando est procesando una consulta. Esto significa que si tenemos varias columnas que frecuentemente aparecen juntas en una clusula WHERE, tenemos la oportunidad de acelerar estas consultas al crear un ndice compuesto. Si una tabla tiene un ndice formado por mltiples columnas, cualquier prefijo ms a la izquierda puede ser usado por el optimizador de consultas de MySQL para encontrar las filas. Por ejemplo, si tenemos un ndice compuesto por tres columnas (col1, col2, col3), tendramos capacidades de bsqueda en (col1), (col1, col2) y (col1, col2, col3). MySQL no puede usar un ndice parcial si las columnas no forman un prefijo ms a la izquierda del ndice. Supongamos que tenemos unas sentencias SELECT como estas: mysql> SELECT * FROM algunaTabla WHERE col1=valor1; mysql> SELECT * FROM algunaTabla WHERE col2=valor2; mysql> SELECT * FROM algunaTabla WHERE col2=valor2 AND col3=valor3; Si el ndice existe en (col1, col2, col3), slo la primera de estas consultas usar el ndice. La segunda y la tercera involucran a las columnas en el ndice, pero (col2) y (col2, col3) no son los prefijos ms a la izquierda de (col1, col2, col3). Este es otro ejemplo. Consideremos la siguiente definicin de una tabla: CREATE TABLE usuarios(id int, nombre varchar(50), apellidos varchar(70));

Si frecuentemente hacemos consultas en la tabla usuarios basadas en el nombre como en los apellidos, podemos beneficiarnos de un ndice compuesto en las columnas nombre y apellidos. ALTER TABLE usuarios ADD INDEX idx_nombre(nombre, apellidos); Debido a la forma en que MySQL construye los ndices compuestos, ste puede usar el ndice idx_nombre para resolver consultas basadas slo en el nombre, o en el nombre y los apellidos, sin embargo, no usar el ndice en una consulta que haga referencia nicamente a la columna apellidos. Por ejemplo, de las siguientes tres consultas, slo las dos primeras haran uso de nuestro ndice idx_nombre. SELECT * FROM usuarios WHERE nombre='Eduardo'; SELECT * FROM usuarios WHERE nombre='Eduardo' AND apellidos='Zarate M'; SELECT * FROM usuarios WHERE apellidos='Zarate M'; La idea es que los ndices compuestos pueden usarse frecuentemente para acelerar algunas consultas complejas, pero necesitamos entender sus limitaciones y debemos ejecutar algn tipo de prueba en vez de asumir que estos ndices siempre nos van a ayudar.

ndices de parte de cam pos

En las columnas CHAR y VARCHAR se nos permite crear un ndice que no use el campo por completo. Retomemos el ejemplo anterior de la tabla usuarios. A pesar de que el nombre de una persona puede ser de hasta 50 caracteres, es muy comn que los nombres de las personas sean diferentes en los primeros 10 caracteres. Al usar un ndice de 10 caracteres en lugar de 50, el ndice ser ms pequeo, y permitir que las consultas INSERT y UPDATE sean ms rpidas, a la vez que no se afecta la velocidad de las consultas SELECT. Para crear un ndice como parte de un campo, slo se tiene que especificar el tamao entre parntesis despus del nombre de la columna. Por ejemplo, nuestro ndice idx_nombre pudo haber sido creado tambin de la siguiente manera: ALTER TABLE usuarios ADD INDEX idx_nombre(nombre(10), apellidos(20));

Eliminar o cambiar un ndice Algunas veces tendremos la necesidad de cambiar o eliminar un ndice. Cuando hagamos algn cambio en el ndice, necesitamos eliminar primero el ndice y entonces reconstruirlo con la nueva definicin. Para eliminar un ndice de clave primaria podemos usar la siguiente sintaxis: ALTER TABLE nombreTabla DROP PRIMARY KEY; Para eliminar un ndice ordinario, nico, o de texto completo, necesitamos especificar el nombre del ndice y usar esta sintaxis: ALTER TABLE nombreTabla DROP INDEX nombreIndice; Tambin es vlida esta otra sintaxis: DROP INDEX nombreIndice ON nombreTabla; Si no estamos seguros de cul es el nombre del ndice que deseamos eliminar, podemos hacer uso de la sentencia SHOW KEYS: SHOW KEYS FROM nombreTabla; Este es un ejemplo. CREATE TABLE usuarios ( id INT NOT, nombre VARCHAR(50) NOT NULL, apellidos VARCHAR(70) NOT NULL, PRIMARY KEY (id), INDEX (nombre, apellidos) ); Veamos los ndices que existen en esta tabla:

mysql> SHOW KEYS FROM usuarios;

+----------+------------+----------+--------------+-------------+ | Table | Non_unique | Key_name | Seq_in_index | Column_name | +----------+------------+----------+--------------+-------------+ | usuarios | 0 | PRIMARY | 1 | id | | usuarios | 1 | nombre | 1 | nombre | | usuarios | 1 | nombre | 2 | apellidos | +----------+------------+----------+--------------+-------------+

3 rows in set (0.00 sec) La tercera columna es la que nos proporciona los nombres de los ndices. Podemos observar que al no especificar un nombre al ndice ordinario en (nombre, apellidos), se le ha asignado el nombre de la primera columna que forma el ndice. A continuacin vamos a eliminar los dos ndices que existen en esta tabla: mysql> ALTER TABLE usuarios DROP PRIMARY KEY; Query OK, 0 rows affected (0.01 sec) Records: 0 Duplicates: 0 Warnings: 0 mysql> ALTER TABLE usuarios DROP INDEX nombre; Query OK, 0 rows affected (0.00 sec) Records: 0 Duplicates: 0 Warnings: 0 Por ltimo, podemos verificar que estos ndices ya no existen: mysql> SHOW KEYS FROM usuarios; Empty set (0.00 sec) Usando ndices efectivamente Dado que los ndices hacen que las consultas se ejecuten ms rpido, podemos estar incitados a indexar todas las columnas de nuestras tablas. Sin embargo, lo que tenemos que saber es que el usar ndices tiene un precio. Cada vez que hacemos un INSERT, UPDATE, REPLACE, o DELETE sobre una tabla, MySQL tiene que actualizar cualquier ndice en la tabla para reflejar los cambios en los datos. As que, cmo decidimos usar ndices o no? La respuesta es "depende". De manera simple, depende que tipo de consultas ejecutamos y que tan frecuentemente lo hacemos, aunque realmente depende de muchas otras cosas. La razn para tener un ndice en una columna es para permitirle a MySQL que ejecute las bsquedas tan rpido como sea posible (y evitar los escaneos completos de tablas). Podemos pensar que un ndice contiene una entrada por cada valor nico en la columna. En el ndice, MySQL debe contar cualquier valor duplicado. Estos valores duplicados disminuyen la eficiencia y la utilidad del ndice. As que antes de indexar una columna, debemos considerar que porcentaje de entradas en la tabla son duplicadas. Si el porcentaje es demasiado alto, seguramente no veremos alguna mejora con el uso de un ndice.

Otra cosa a considerar es qu tan frecuentemente los ndices sern usados. MySQL puede usar un ndice para una columna en particular nicamente si dicha columna aparece en la clusula WHERE en una consulta. Si muy rara vez usamos una columna en una clusula WHERE, seguramente no tiene mucha sentido indexar dicha columna. De esta manera, probablemente sea ms eficiente sufrir el escaneo completo de la tabla las raras ocasiones en que se use esta columna en una consulta, que estar actualizando el ndice cada vez que cambien los datos de la tabla. Ante la duda, no tenemos otra alternativa que probar. Siempre podemos ejecutar algunas pruebas sobre los datos de nuestras tablas con y sin ndices para ver como obtenemos los resultados ms rpidamente. Lo nico a considerar es que las pruebas sean lo ms realistas posibles. Procesamiento de consultas Las reglas que usa MySQL para decidir como obtener los datos de una consulta pueden llegar a ser difciles de entender si dichas consultas son algo complejas. Afortunadamente hay unas pocas reglas y un comando que nos permiten tener un mejor entendimiento de qu es lo que est haciendo MySQL. Primero vamos a comentar las reglas: MySQL no usar un ndice si decide que ser mucho ms rpido escanear completamente una tabla. En general, si un ndice le hace saber a MySQL que acceder aproximadamente el 30 por ciento de las filas de una tabla, MySQL abandona el ndice y simplemente ejecuta un escaneo completo de la tabla. Si mltiples ndices pueden ser usados para satisfacer una consulta, MySQL usar el que sea ms restrictivo -- esto es, con el que se obtengan el menor nmero de filas. Si las columnas que estamos seleccionando forman parte de un ndice, MySQL puede leer todos los datos que necesitamos desde el ndice y nunca tocar la tabla en s. Cuando usamos varias tablas en una consulta, MySQL leer primero los datos desde la tabla que regrese el menor nmero de filas. El orden en el que se especifican las tablas puede no ser el mismo que use MySQL. Esto afecta tambin el orden en el que son regresados finalmente los registros, as que debemos asegurarnos de usar una clusula ORDER BY si necesitamos que los registros tengan un orden en particular.

Habiendo dicho esto, es importante tener en cuenta que algunas de las decisiones que toma MySQL estn basadas en suposiciones, y al igual que nosotros los

humanos que hacemos muchas suposiciones, puede que MySQL ocasionalmente haga alguna que sea incorrecta. Si sospechamos que esto ha sucedido, o simplemente queremos entender qu es lo que est haciendo MySQL para procesar una consulta, podemos usar el comando EXPLAIN. La seccin a continuacin explica ms a detalle el uso de EXPLAIN. Analizando como se usan los ndices EXPLAIN muestra (explica) como son procesadas las sentencias SELECT por MySQL, como se usan los ndices, y como se unen las tablas. Utilizar EXPLAIN puede ayudarnos a seleccionar mejores ndices y escribir nuestras consultas ms ptimamente. Lo nico que tenemos que hacer es agregar la palabra EXPLAIN al inicio de la consulta para que MySQL nos diga como la est ejecutando. En vez de ejecutar la consulta, MySQL reportar la lista de ndices que se podran usar en la consulta y lo que conoce acerca de ellos. EXPLAIN SELECT nombre, apellidos FROM usuarios WHERE id = 1; A continuacin se explica que significa cada una de estas columnas. table La tabla a la que se refieren las dems columnas en esta tabla. type El tipo de unin que se est usando. Desde la mejor hasta la peor, los tipos de uniones son system, const, eq_ref, ref, range, index, y ALL. system La tabla tiene slo una fila. const La tabla tiene como mximo una fila que coincide, la cual ser leda en el inicio de la consulta. Ya que hay slo una fila, los valores de la columna en esta fila pueden ser considerados como constantes por el optimizador. Las tablas const son muy rpidas ya que son ledas slo una vez. const es usado cuando se comparan todas las partes de una clave PRIMARY/UNIQUE con constantes.

eq_ref Una fila ser leda de esta tabla por cada combinacin de filas de las tablas previas. Este es usado cuando todas las partes de un ndice son usadas por la consulta y el ndice es UNIQUE o PRIMARY KEY. ref Todas las filas con valores en el ndice que coincidan sern ledas desde esta tabla por cada combinacin de filas de las tablas previas. ref es usado si la consulta usa slo un prefijo ms a la izquierda de la clave, o si la clave no es UNIQUE o PRIMARY KEY. Si la clave que es usada coincide slo con pocas filas, esta unin es buena. range Slo sern recuperadas las filas que estn en un rango dado, usando un ndice para seleccionar las filas. La columna key indica cual ndice es usado, y el valor key_len contiene la parte ms grande de la clave que fue usada. La columna ref ser NULL para este tipo. index Este es el mismo que ALL, excepto que slo el ndice es escaneado. Este es usualmente ms rpido que ALL, ya que el ndice es usualmente de menor tamao que la tabla completa. ALL Un escaneo completo de tabla ser hecho por cada combinacin de filas de las tablas previas. Este es normalmente no bueno si la tabla es la primera no marcada const, y usualmente muy malo en todos los otros casos. possible_keys Los posibles ndices que pueden aplicar a la tabla. Si est vaca esta celda, no hay posibles ndices a utilizar. key El ndice que ha sido seleccionado. Si tiene un valor NULL, entonces ningn ndice ser utilizado.

key_len La longitud del ndice usado. Entre ms pequeo sea este valor, mejor. ref Las columnas del ndice que se est usando, o una constante si esta es posible. rows Nmero de filas que considera MySQL debe analizar para regresar los datos requeridos. extra Informacin extra acerca de como MySQL resolver la consulta. Aqu se muestra una explicacin de los posibles textos que podemos encontrar en esta columna. Distinct Una vez que MySQL ha encontrado una fila que coincida con la combinacin de filas, ste no buscar ms. Not exists MySQL fue capaz de hacer una optimizacin LEFT JOIN sobre la consulta y no examinar ms filas en la tabla para la combinacin de filas previa despus de que encuentre una fila que coincida con el criterio LEFT JOIN. range checked for each record (index map: #) MySQL no encontr un buen ndice que usar, as que para cada combinacin de filas en las tablas precedentes, har un chequeo en cual ndice usar (si hay alguno), y usar este ndice para recuperar las filas desde la tabla. Esto no es lo ms rpido, pero es mejor que hacer un join sin un ndice. Using filesort Cuando veamos esto, la consulta necesita ser optimizada. MySQL necesita hacer un paso extra para encontrar la forma de ordernar las filas que sern regresadas.

Using index La informacin de las columnas es recuperada desde la tabla usando slo informacin en el ndice, sin tener que leer la fila actual. Esto sucede cuando todas las columnas requeridas son parte del mismo ndice. Using temporary Cuando veamos esto, la consulta necesita ser optimizada. Para resolver la consulta MySQL necesita crear una tabla temporal para mantener el resultado. Esto sucede tpicamente cuando se hace un ORDER BY sobre un conjunto de columnas diferente al usado en un GROUP BY. Where used Una clusula WHERE ser usada para restringir cuales filas sern comparadas en contra de la siguiente tabla o enviada al cliente. Si no deseamos regresar todas las filas desde la tabla, y el join es del tipo ALL o index, es muy probable que hayamos escrito algo mal en la consulta. Si deseamos obtener consultas que se ejecuten lo ms rpido posible, debemos ser cuidadosos cuando veamos informacin extra del tipo Using filesort o Using temporary. Podemos obtener una buena indicacin de que tan buena es una consulta al multiplicar todos los valores de la columna rows en la salida de EXPLAIN. Esto nos dice aproximadamente cuntas filas debe examinar MySQL para ejecutar una consulta. De lo que se trata es que podamos ir mejorando una consulta progresivamente usando la informacin proporcionada por EXPLAIN. Cmo evitar escaneos completos de tablas La salida de EXPLAIN mostrar ALL en la columna type cuando MySQL hace un escaneo de tabla para resolver una consulta. Esto sucede usualmente bajo las siguientes condiciones: La tabla es demasiado pequea que es ms rpido hacer el escaneo de la tabla que buscar una ndice. Este es el caso comn para tablas con menos de 10 filas.

No hay restricciones usables en las clusulas ON o WHERE para las columnas indexadas. Se estn comparando columnas indexadas con valores constantes y MySQL ha calculado que las constantes cubren una gran parte de la tabla y que el escaneo completo ser ms rpido. Se est usando una clave con baja cardinalidad (muchas filas que coinciden con el valor clave) en contra de otra columna. En este caso, MySQL asume que el usar el ndice probablemente se harn una gran cantidad de bsquedas adicionales de claves y que un escaneo de la tabla ser ms rpido. Para tablas pequeas, un escaneo de la tabla es frecuentemente apropiado. Para tablas muy grandes, podemos intentar las siguientes tcnicas para evitar que el optimizador de consultas de MySQL escoja incorrectamente un escaneo completo. Usar ANALIZE TABLE para actualizar la distribucin de claves para la tabla escaneada. Usar FORCE INDEX en la tabla escaneada para decirle a MySQL que use el ndice dado. Por ejemplo. SELECT * FROM tabla1, tabla2 FORCE INDEX (indiceParaColumna) WHERE tabla1.nombreColumna=tabla2.nombreColumna;

Actividad: En base a las tablas ya creadas: dept: Tabla donde se almacenan los departamentos de la compaa

dept
Campo Descripcin Tipo integer(4), deptno No del departamento dname loc

Nombre del departamento varchar(14) Localidad donde se encuentra ubicada esa sucursal varchar(20)

 emp: Tabla que almacena la informacin de los empleados de la empresa

emp
Campo empno ename job mgr Descripcin No del empleado Nombre del Empleado Cargo que ocupa Codigo (empno) de su jefe Tipo integer(4) varchar(20) varchar(10) integer(4) date integer(7) integer(7)

hiredate Fecha de ingreso a la compania sal comm deptno Salario del empleado Comisin del empleado si la tuviese.

Referencia a la clave integer(4) primaria del departamento

Actividad 1: Restricciones de clave General

a) Crear una restriccin general para la tabla emp, usar la sintaxis FOREIGN KEY(campo_fk) REFERENCES nombre_tabla (nombre_campo) b) Eliminar restriccin de clave fornea realizada.

Actividad 2: Restricciones de clave en la eliminacin de registros

a) Realice una restriccin sobre las tablas en la clave fornea para eliminar en cascada. Elimine un registro de la tabla departamento (Debe mostrar las dos tablas antes y despus de eliminar el registro). b) Realice una restriccin sobre las tablas en la clave fornea para colocar el valor null en la clave fornea. Elimine un registro de la tabla departamento (Debe mostrar las dos tablas antes y despus de eliminar el registro). c) Elimine las restricciones de la clave fornea.

Actividad 3: Creacin de ndices

a) Cree un ndice para la tabla emp y otro para la tabla dept por el campo deptno

b) Cree un ndice nico (Unique) c) Elimine los ndices creados

Funciones y Stored Procedures La interfaz de MySQL para funciones definidas por el usuario proporciona las siguientes funcionalidades y capacidades:

Las funciones pueden retornar cadenas de caracteres, enteros o valores reales. Puede definir funciones simples que operen en con un nico registro a la vez, o agregar funciones que operen con grupos de registros. Se proporciona informacin a las funciones que permite chequear el tipo y nmero de argumentos que se les pasa. Le puede decir a MySQL que coercione argumentos de un tipo dado antes de pasarlos a la funcin. Puede indicar que una funcin retorne NULL o que ha ocurrido un error.

4.- LLame a la funcin y muestre los resultados select hourly_stock_change('AMD');

Procedimientos Almacenados (Stored Procedures)

Un procedimiento almacenado es un conjunto de comandos SQL que pueden almacenarse en el servidor. Una vez que se hace, los clientes no necesitan reescribir los comandos individuales pero pueden en su lugar referirse al procedimiento almacenado. Algunas situaciones en que los procedimientos almacenados pueden ser particularmente tiles:

Cuando mltiples aplicaciones cliente se escriben en distintos lenguajes o funcionan en distintas plataformas, pero necesitan realizar la misma operacin en la base de datos. Cuando la seguridad es muy importante. Los bancos, por ejemplo, usan procedimientos almacenados para todas las oparaciones comunes. Esto proporciona un entorno seguro y consistente, y los procedimientos pueden asegurar que cada operacin se loguea apropiadamente. En tal entorno, las aplicaciones y los usuarios no obtendran ningn acceso directo a las tablas de la base de datos, slo pueden ejectuar algunos procedimientos almacenados.

Los procedimientos almacenados pueden mejorar el rendimiento ya que se necesita enviar menos informacin entre el servidor y el cliente. El intercambio que hay es que aumenta la carga del servidor de la base de datos ya que la mayora del trabajo se realiza en la parte del servidor y no en el cliente. Considere esto si muchas mquinas cliente (como servidores Web) se sirven a slo uno o pocos servidores de bases de datos. Los procedimientos almacenados le permiten tener bibliotecas o funciones en el servidor de base de datos. Esta caracterstica es compartida por los lenguajes de programacin modernos que permiten este diseo interno, por ejemplo, usando clases. Usando estas caractersticas del lenguaje de programacin cliente es beneficioso para el programador incluso fuera del entorno de la base de datos.

1. Crear la base de datos Stock_app.

Triggers

Un disparador es un objeto con nombre dentro de una base de datos el cual se asocia con una tabla y se activa cuando ocurre en sta un evento en particular.