PHP-TUT-22 Bases de datos SQL (I)

Facebooktwittergoogle_pluslinkedinmailFacebooktwittergoogle_pluslinkedinmail

Empezamos en este artículo el estudio de la creación y gestión de bases de datos. Las bases de datos, (BBDD) son estructuras donde se almacena información siguiendo unas pautas de disposición y ordenación para el posterior procesado de los datos. Es una definición tan buena como cualquier otra. Seguramente, si lees cincuenta libros al respecto, encuentres otras tantas definiciones distintas, pero todas coincidirán en lo esencial. Como sistema de almacenamiento de datos, las BBDD son mucho más eficientes que los archivos de texto que ya conocemos. Y esto por varias razones pero, principalmente, porque nos permiten un acceso directo al dato que necesitamos sin que sea preciso recorrer todo un fichero para encontrarlo.

Además, los modernos sistemas de gestión de BBDD relacionales admiten el almacenamiento de muchos tipos de datos, no sólo texto plano. Hablamos de BBDD relacionales cuando podemos establecer relaciones entre las distintas informaciones que componen una base de datos. Por ejemplo, si quieres guardar la lista de clientes de una empresa de servicios. Por otro lado, tienes una lista de los servicios que ofrece dicha entidad. Además conservas una relación histórica de los servicios empleados por cada cliente. A partir de ahí, mediante el uso de un Sistema de Gestión de Bases de Datos Relacionales (RDBMS, Relation Data Base Management System) puede sacar estadísticas u otros informes que le ayuden a la planificación u organización de su trabajo diario.

Los motores de BBDD actuales (la parte que se encarga de gestionar la BBDD fuera de la vista del usuario) están basados en el lenguaje SQL (Structured Query Language, Lenguaje Estructurado de Consultas). Éste va a ser el objeto de estudio en este artículo, de una forma genérica, sin entrar a usar ninguna base de datos real. Esto, que puede parecer, en principio, un poco demasiado teórico, nos va a servir como introducción para el uso de RDBMS en este artículo, dónde aprenderemos a manejar bases de datos SQL con PHP.

CÓMO ES UNA BASE DE DATOS

Es imposible hablar del lenguaje SQL sin saber, previamente, cómo son las bases de datos que gestiona. En una BBDD la información se almacena en tablas. Cada tabla está formada por filas, llamadas también registros o tuplas. Cada tupla está divida en campos, que forman columnas. Cada campo contiene un dato y todos los campos de una columna tienen la misma estructura, es decir, que en todos ellos se almacena un dato del mismo tipo, tamaño máximo, etc. Por ejemplo, si uno de los datos de la tabla donde se almacenan los servicios es el nombre de cada servicio, ese dato será de tipo cadena alfanumérica y tendrá un máximo de caracteres. Para que nos hagamos una idea, mira la siguiente tabla:

 

N.º NOMBRE CIUDAD PAÍS
1 Carmen Gómez Madrid España
2 Giancarlo Bennedetti Roma Italia
3 Johanna Krüger Berlín Alemania
4 Mauricio Rodríguez Lima Perú
5 John Foster Londres Reino Unido
6 Alice Coppertone Las Vegas, Nevada Estados Unidos

Esta tabla podría ser la lista de gerentes de una multinacional. Ves que cada fila (registro) almacena los datos de una persona, y que cada columna (campo) almacena un dato determinado de todos los registros. Esta es una de las características de una tabla en una BBDD. Se conoce con el nombre de homogeneidad estructural. En una BBDD pueden coexistir tantas tablas como sean necesarias. Cada una tendrá su propia estructura (disposición de los datos).

Dentro de una tabla es conveniente (aunque no obligatorio) crear un campo clave. Éste es uno de los campos de la tabla que sirve como referencia para la localización de registros. Aunque con los motores de BBDD actuales es posible localizar un registro por cualquiera de sus campos, el hacerlo mediante el campo clave acelera el proceso, sobre todo cuando se gestionan tablas con millones de registros. No obstante, con las tecnologías actuales, localizar un registro, o más de uno, por un campo que no sea clave es perfectamente posible y viable. En el ejemplo de la tabla anterior, el campo clave podría ser el número que identifica a cada registro. Otra razón para el uso de un campo clave es que los motores de BBDD no permiten que éste tenga el mismo contenido en dos registros diferentes. Así pues, volviendo nuestra tabla, podría ser que nuestra multinacional incluyera en su plantilla a una segunda persona llamada John Foster (creo que, en los países anglosajones, es un nombre bastante corriente). Pero sólo uno de ellos podría tener el n.º 5, si es que este dato se ha definido como campo clave en la estructura de la tabla.

El campo clave de una tabla se conoce también con el nombre de clave primaria. Además, podemos definir otros campos como claves secundarias, llamadas también, foráneas o extranjeras. Una clave secundaria es un campo que, normalmente, coincide con la clave primaria de otra tabla, y se emplea para construir relaciones entre ambas. Por ejemplo, podríamos tener otra tabla en la que almacenáramos los nombres de diferentes países, y la lista de ciudades, o provincias, de dichos países en los que la empresa tiene sucursales. El nombre del país sería la clave principal en esta tabla, y clave foránea en la de personal.

Para facilitarle la comprensión de los elementos con los que va a trabajar considere el almacenamiento de información en una base de datos según el esquema que aparece a continuación:

base_de_datos

Como ves, dentro del contenedor de la BBDD se alojan las tablas, que almacenarán la información necesaria. Puede haber tantas como necesitemos. La información que necesitemos manejar para nuestra aplicación la distribuiremos en estas tablas siguiendo criterios de lógica. Por ejemplo, si vas a usar una base de datos para la gestión de una empresa, crearás una tabla para los clientes, otra para los empleados, otra para los productos o servicios que ofrece la empresa, otra para las ventas, otra para las compras, otra para el almacén, etc.

De los índices hablaremos en este mismo artículo. De momento, considéralos como elementos auxiliares para ayudarnos en la gestión de las tablas.

EL LENGUAJE SQL

En los albores de la informática de gestión, allá por los tardíos 70 o primeros 80 del pasado siglo, las aplicaciones comerciales que manejaban ficheros de datos tenían sus propios formatos para almacenar y recuperar la información. Cada nuevo programa que se desarrollaba, normalmente bajo demanda y a medida en aquellos tiempos, grababa y recuperaba los datos en un formato específico, nativo de esa aplicación o del lenguaje en el que había sido escrita. Esto presentaba varios problemas. El usuario de un programa de, digamos, contabilidad que quisiera migrar a otro necesitaba reconvertir todos los datos, en ocasiones, volviendo a grabarlos. Además, en una empresa mediana o grande (las únicas que, en aquellos días, podían permitirse tener sistemas informáticos), los datos de almacén podían no estar grabados en un formato compatible con los de facturación. Esto obligaba a grabar los pedidos en los dos departamentos. Cuando la información se graba por duplicado o triplicado en diferentes sistemas siempre pueden aparecer diferencias. Además, es posible que unos datos se actualicen en un sistema pero no en otro. Y, en muchas ocasiones, cuando había varias versiones de la misma información circulando por distintos departamentos de una misma empresa, no se sabía cuáles eran los datos más actualizados. Esto es lo que se llama inconsistencia de la información. Yo, personalmente, lo llamo un verdadero desastre.

Surgía la necesidad de tratar los archivos de datos de forma que todos presentaran un formato coherente, y que cualquier aplicación pudiera acceder a las mismas fuentes de información. El lenguaje SQL cubría estas necesidades. Por una parte encapsulaba los datos, interponiéndose entre estos y la aplicación, de modo que ésta usaba instrucciones SQL y era él quien manejaba los datos. Así pues, bastaba con que una aplicación implementase SQL para que pudiera acceder a los datos de cualquier otra aplicación. Por otra parte, dado que está orientado a la gestión básica de los datos, SQL tiene, relativamente, pocas instrucciones, y es muy fácil de aprender y manejar con soltura. SQL se integra así con los lenguajes de programación modernos, supeditado a ellos. Por ejemplo, SQL no puede mostrar un registro de una BBDD en una página web. Pero sí puede recuperar el contenido del registro y cedérselo al script PHP, que es el que se encargará de darle el formato adecuado y mostrarlo en un documento HTML. Y PHP sí puede gestionar SQL.

Las instrucciones de SQL (llamadas, genéricamente, consultas) se pueden considerar divididas en dos grupos principales. Las estructurales, también llamadas de definición de datos, o DLL y las de datos, también llamadas de manipulación de datos o DML. Las primeras están destinadas a crear, modificar y eliminar las BBDD y las estructuras de las tablas que las conforman así como los índices. Las segundas se ocupan de incorporar nuevos registros a las tablas, buscar determinados registros según los criterios necesarios, modificar los datos grabados o eliminarlos, si procede. Como es lógico, iniciaremos el estudio de SQL con el primer grupo, ya que antes de trabajar con datos tenemos que tener un sitio dónde poder almacenarlos y clasificarlos.

CONSULTAS ESTRUCTURALES

Lo primero que tenemos que hacer para gestionar una base de datos es crearla. Esto lo hacemos con la consulta CREATE DATABASE, cuya sintaxis genérica es la siguiente:

CREATE DATABASE IF NOT EXISTS baseDeDatos;

Como ves, ponemos la consulta (CREATE DATABASE IF NOT EXISTS), seguida del nombre con el que queremos almacenar la base de datos (en nuestro ejemplo, baseDeDatos) y terminamos con punto y coma. Todas las consultas SQL, al igual que las instrucciones de PHP, deben terminar con punto y coma. La cláusula IF NOT EXISTS es opcional, pero si no la incluyes y la base de datos ya existe se produce un error. Como norma general, inclúyela siempre, al menos hasta que adquieras cierta soltura.

Quiero llamar tu atención sobre una cosa. La base de datos recién creada es sólo un contenedor que almacenará las tablas donde se guardarán los datos. Pero sin las tablas, la base de datos, por sí misma, no permite guardar ninguna información. Antes de pensar en crear tablas (o en realizar cualquier operación, cuando ya estén creadas), es necesario especificar la base de datos con la que vamos a trabajar, ya que en el dispositivo de almacenamiento, sea éste local o remoto, podemos tener más de una BBDD.

Para seleccionar una usaremos la consulta USE, así:

USE baseDeDatos;

Puede que usted desee eliminar una base de datos completamente. En ese caso utilice La consulta DROP DATABASE, tal como ve a continuación:

DROP DATABASE IF EXISTS baseDeDatos;

Especifica, tal como aparece, el nombre de la BBDD que deseas eliminar. Pero recuerda. Cuando eliminas una base de datos se borra absolutamente todo lo que contiene. Tablas, índices, datos… No queda nada. Y esta operación es irreversible. Así que, a menos que tengas copia de seguridad, más vale que estés completamente seguro de lo que haces. La cláusula IF EXISTS es opcional, pero si no la incluyes y la BBDD no existe se producirá un error.

Una vez que se ha creado una BBDD con CREATE DATABASE, y seleccionado con USE, llega el momento de crear las tablas. Cuando se crea una tabla se especifican los campos que formarán cada registro de la misma. A modo de ejemplo, vamos a crear una tabla de empleados de una empresa, donde se podrá almacenar el n.º de empleado, el nombre, el salario bruto mensual y la categoría profesional, así como un indicador sobre si el empleado es de sexo masculino (“M”) o femenino (“F”) y el departamento en que trabaja. Para la creación de tablas contamos con la consulta CREATE TABLE, que es muy versátil, según veremos enseguida.

Con esto se habrá creado la estructura de la tabla en la que, posteriormente, se introducirán los datos. Vamos a analizar un poco lo que acabamos de hacer. Fíjate en que hemos usado la consulta CREATE TABLE, seguida del nombre de la tabla que queremos crear. Entre paréntesis aparece la definición de los campos que tendrá la tabla, separando cada uno del siguiente con una coma y un salto de línea. Lo del salto de línea es opcional (se ve más claro).

Las comas, en cambio, son obligatorias. Cada campo se crea anotando su nombre, seguido del tipo de dato que se almacenará y, opcionalmente, algunos atributos para definir su comportamiento. Los tipos de datos que se pueden manejar desde SQL son los que ves en la tabla siguiente:

DATO USO
DATOS NUMERICOS
TINYINT Un entero de 1 byte; el rango con signo es de -128 a 127, el rango sin signo es de 0 a 255
SMALLINT Un entero de 2 bytes; el rango con signo es de -32768 a 32767, el rango sin signo es de 0 a 65535
MEDIUMINT Un entero de 3 bytes; el rango con signo es de -8388608 a 8388607, el rango sin signo es de 0 a 16777215
INT Un entero de 4 bytes; el rango con signo es de 2147483648 a 2147483647, el rango sin signo es de 0 a 4294967295
BIGINT En entero de 8 bytes; el rango con signo es de -9223372036854775808 a 9223372036854775807, el rango sin signo es de 0 a 18446744073709551615
DECIMAL Un número decimal fijo (M, D) – la mayor cantidad de dígitos (M) es 65 (valor predeterminado de 10), el mayor número posible de decimales (D) es 30 (valor predeterminado de 0)
FLOAT Un número de coma flotante pequeño; los valores posibles son de -3.402823466E+38 a -1.175494351E-38, 0 y de 1.175494351E-38 a 3.402823466E+38
DOUBLE Un número de coma flotante de precisión doble; los valores permitidos son de -1.7976931348623157E+308 a -2.2250738585072014E-308, 0 y de 2.2250738585072014E-308 a 1.7976931348623157E+308
REAL Sinónimo de DOUBLE (excepción: si el modo SQL “REAL_AS_FLOAT” está activo es sinónimo de FLOAT)
BIT Una máscara de bits (M), almacenando M bits por valor (valor predeterminado de 1, máximo de 64)
BOOLEAN Sinónimo de TINYINT, aunque un valor de cero es considerado falso, cualquier valor distinto de cero es considerado verdadero
SERIAL Un sinónimo de BIGINT UNSIGNED NOT NULL AUTO_INCREMENT UNIQUE
DATOS DE FECHA Y HORA
DATE Una fecha, el rango válido es de “1000-01-01” a “9999-12-31”
DATETIME Una combinación de fecha y marca temporal, el rango válido es de “1000-01-01 00:00:00” a “9999-12-31 23:59:59”
TIMESTAMP Una marca temporal; el rango es de “01-Ene-1970 00:00:01” UTC a “09-Ene-2038 03:14:07” UTC almacenados como la cantidad de segundos desde el “epoch” (“01-Ene-1970 00:00:00” UTC)
TIME Una marca temporal, el rango es de “-838:59:59” a “838:59:59”
YEAR Un año en formato de cuatro dígitos (4, el valor predeterminado) o dos dígitos (2); los valores posibles son de 70 (1970) a 69 (2069) ó de 1901 a 2155 y 0000
DATOS DE CADENA
CHAR Una cadena de longitud fija (de 0 a 255, valor predeterminado de 1) que es siempre completada a la derecha con espacios hasta la longitud especificada al ser almacenada
VARCHAR Una cadena de longitud variable (0-65,535), la longitud máxima está asociada al tamaño máximo de un registro
TINYTEXT Una columna de texto con una longitud máxima de 255 (2^8 – 1) caracteres, almacenado con un prefijo de 1 byte que indica la longitud del valor en bytes
TEXT Una columna de texto con una longitud máxima de 65535 (2^16 – 1) caracteres, almacenado con un prefijo de 2 bytes que indica la longitud del valor en bytes
MEDIUMTEXT Una columna de texto con una longitud máxima de 16777215 (2^24 – 1) caracteres, almacenado con un prefijo de 3 bytes que indica la longitud del valor en bytes
LONGTEXT Una columna de texto con una longitud máxima de 4294967295 ó 4Gb (2^32 – 1) caracteres, almacenado con un prefijo de 4 bytes que indica la longitud del valor en bytes
BINARY Similar al tipo CHAR, pero almacena cadenas binarias de bytes en lugar de cadenas de caracteres no binarios
VARBINARY Similar al tipo VARCHAR, pero almacena cadenas binarias de bytes en lugar de cadenas de caracteres no binarios
TINYBLOB Una columna de bloque de texto (“BLOB”) con una longitud máxima de 255 (2^8 – 1) bytes. Cada valor TINYBLOB es almacenado con un prefijo de 1 byte que indica la cantidad de bytes en el valor”
MEDIUMBLOB Una columna de bloque de texto (“BLOB”) con una longitud máxima de 16777215 (2^24 – 1) bytes, almacenado con un prefijo de 3 bytes que indica la longitud del valor
BLOB Una columna de bloque de texto (“BLOB”) con una longitud máxima de 65535 (2^16 – 1) bytes, almacenado con un prefijo de 2 bytes que indica la longitud del valor
LONGBLOB Una columna de bloque de texto (“BLOB”) con una longitud máxima de 4294967295 (2^32 – 1) bytes (4GB), almacenado con un prefijo de 4 bytes que indica la longitud del valor
ENUM Una enumeración, elegida de una lista de hasta 65535 valores
SET Un único valor elegido de un conjunto de hasta 64 elementos
DATOS ESPACIALES
GEOMETRY Un tipo que puede almacenar una geometría de cualquier tipo
POINT Un punto en espacio de dos dimensiones
LINESTRING Una curva con interpolación lineal entre puntos
POLYGON Un polígono
MULTIPOINT Una colección de puntos
MULTILINESTRING Una colección de curvas con interpolación lineal entre puntos
MULTIPOLYGON Una colección de polígonos
GEOMETRYCOLLECTION Una colección de objetos geométricos de cualquier tipo
ATENCIÓN. Se ha referido la lista de tipos de datos de MySQL 5, dado que es el motor de bases de datos SQL más empleado por los programadores de PHP. Si tú analizas otro motor podrías encontrar discrepancias.

 No te dejes abrumar por la gran cantidad de tipos de datos que existen. En la práctica sólo usarás unos cuantos. Además, enseguida te familiarizarás con ellos. En el ejemplo que aparece antes de la tabla vemos algunos de los tipos más habituales. El tipo de dato siempre se escribe con mayúsculas en la declaración de una tabla, por convencionalismo. Algunos motores de BBDD soportan las mayúsculas y las minúsculas, pero acostúmbrate a escribirlos en mayúsculas por claridad y por convencionalismo (casi todos los prrogramadores seguimos este formato, a fin de compartir información).

Los tipos CHAR y VARCHAR se usan para almacenar cadenas alfanuméricas y van seguidos de un número entre paréntesis. En el caso de un dato CHAR, este número indica la cantidad de caracteres que se reservan para la cadena. Si el dato introducido tiene menos caracteres, no importa. El campo seguirá ocupando lo mismo en el disco. Cuando se emplea el tipo VARCHAR, y el dato introducido tiene menos caracteres de los que se reservaron, ese campo, en ese registro concreto, ocupa menos: tantos bytes como caracteres tenga la cadena grabada. Por lo tanto, en muchos casos, es más interesante usar VARCHAR, que CHAR, sobre todo en campos cuyos datos puedan variar mucho.

Los datos de tipo FLOAT, DOUBLE y DECIMAL reciben dos parámetros entre paréntesis, separados por una coma. El primero es el número máximo total de dígitos que podrá tener el valor almacenado. Esto incluye los dígitos de la parte entera y fraccionaria, pero no el punto decimal ni el signo. Por ejemplo si defines un dato como FLOAT (6,2) te cabrá el valor 9.384,23 y también -9.384,23.

Los campos de tipo ENUM se usan para almacenar un valor de una serie de posibles valores discretos. Por ejemplo, se emplean mucho para almacenar datos de tipo verdadero, falso o similar. Lo que hacemos es incluir entre paréntesis, una lista con cada uno de los posibles valores. El motor de la BBDD se encargará de generar un error si se intenta introducir un valor que no esté en la lista. Los valores se separan con comas y se acotan con comillas simples. Ni éstas ni aquéllas formarán parte del valor. Por ejemplo, si definimos un campo como ENUM (‘S', ‘N') quiere decir que puede recibir una S o una N, pero ningún otro valor. Estos campos se emplean mucho en aplicaciones que den al usuario opción a elegir uno de varios valores posibles.

ATENCIÓN. Mi experiencia me demuestra que estos campos pueden, en ocasiones, quedar “vacíos” al insertar un nuevo registro, es decir, sin ninguno de los valores preprogramados. Esto puede suceder, incluso, si establecemos un valor por defecto con la cláusula DEFAULT. Por esta razón, cuando programes con PHP consultas de inserción de nuevos registros, deberás indicar, expresamente, un valor para este tipo de campos.

Cuando se crea una tabla, al declarar los campos que la constituirán, además del tipo de cada dato, se le pueden asignar algunos atributos, destinados a modificar su comportamiento, o acotarlo.

La lista de posibles atributos para los campos es la que aparece recogida en la tabla siguiente:

 

ATRIBUTOS DE DATOS SQL
ATRIBUTO DESCRIPCIÓN
NULL Indica que el campo podrá quedar sin ningún contenido cuando se cree un registro, o cuando se modifique uno ya existente.
NOT NULL Indica que este campo debe tener asignado un contenido obligatoriamente en cada registro. Si se intenta dejar sin contenido se producirá un error.
DEFAULT valor Indica el valor que el campo asumirá por defecto. Cuando se cree un nuevo registro de la tabla en el campo se almacenará, de forma automática, el valor establecido por defecto, aunque, por supuesto, si se especifica otro valor, se grabará el especificado. Si el campo es numérico, se escribirá el valor, sin más. Si el campo es alfanumérico se acotará con comillas simples.
ZEROFILL Este atributo se aplica a campos numéricos cuando queremos que se rellenen con ceros los dígitos de más. Por ejemplo, si se reserva en un campo FLOAT sitio para cuatro dígitos y se almacena el valor 867, quedará como 0867.
UNIQUE Se utiliza cuando queremos que no se pueda repetir el valor de un campo en otro registro. Por ejemplo, si creamos una tabla de personal y uno de los campos es el DNI de cada persona, es lógico que no pueda haber dos personas con el mismo número de documento. Si se intenta asignar un valor a ese campo, que ya exista en otro registro, se producirá un error.
UNSIGNED Este atributo, aplicado a campos numéricos, hace que el motor de la base de datos genere un error si se intenta introducir un valor con signo, lo que, en la práctica, impide el uso de valores negativos.
AUTO_INCREMENT Este atributo se asigna a un campo numérico cuando deseamos que se incremente de forma automática. Es decir, cada nuevo registro que se cree almacenará, en dicho campo, un valor que sea una unidad más que el anterior. Si elimina un registro, el valor que tenía en ese campo no se le volverá a asignar a ningún otro.
PRIMARY KEY Este atributo define un campo como clave primaria. Eso hace que en dicho campo no pueda haber valores repetidos.

Fíjate que, al final de la definición de la estructura de la tabla empleados que hemos visto aparecen dos cláusulas. En primer lugar tenemos:

PRIMARY KEY (numero)

Para establecer un campo como clave primaria podemos poner el atributo PRIMARY KEY en la misma línea que definimos el campo o, como hemos hecho aquí, al final de la lista de campos, como una cláusula. ¿Cuál es la diferencia? En la práctica, ninguna. Es una cuestión de criterio. Yo, personalmente, encuentro más legible la definición de la tabla poniendo esta cláusula al final, pero si tú lo prefieres de otro modo, podrías haber escrito, al definir el campo, lo siguiente (el resultado es el mismo):

numero INT NOT NULL PRIMARY KEY,

El lenguaje SQL te permite el uso de claves foráneas, tal como mencioné en el apartado anterior. Estas claves, normalmente, se asignan a campos que coinciden con otros que, a su vez, son clave primaria en otra tabla, y se usan para relacionar tablas entre sí. Supongamos el ejemplo de la tabla de empleados que hemos creado, con una ligera modificación:

La cláusula REFERENCES indica en qué tabla es clave principal la que aquí es foránea, siempre trabajando en la misma BBDD.

La cláusula ON UPDATE indica lo que debe hacer el motor de BBDD si se modifica el valor del campo en la tabla departamentos.

La cláusula ON DELETE indica lo que debe hacer el motor de BBDD si se elimina el valor del campo en la tabla departamentos. Las posibilidades para estas dos últimas cláusulas son:

CASCADE. Actualiza (ON UPDATE) o elimina (ON DELETE) los registros de la tabla de empleados según los de la tabla de departamentos.

SET NULL. Establece el valor NULL en el campo departamento de la tabla de empleados, si el registro asociado es eliminado.

RESTRICT. Impide la modificación o eliminación del campo departamento en la tabla de departamentos.

Y, ahora, veamos la creación de la tabla de departamentos de la empresa:

Otra cláusula a la que le tenemos que prestar atención es la siguiente:

TYPE=InnoDB

Esto se refiere al motor de almacenamiento. En MySQL los dos motores más empleados son MyISAM e InnoDB. Este último tiene varias ventajas, entre las que se cuentan las siguientes:

  • Menor ocupación de disco. Mientras que MyISAM emplea tres archivos por tabla, InnoDB sólo emplea uno.
  • Permite el uso de claves foráneas. Todo lo que hemos comentado sobre claves foráneas y relaciones entre tablas queda sin efecto con MyISAM.
  • Permite las transacciones. Es un concepto nuevo, del que hablaremos en su momento, pero de una gran utilidad en muchos escenarios.

Por estas y otras razones, emplearemos bases de datos y tablas con el motor InnoDB.

Como es lógico, también puede, si lo desea, eliminar una tabla de la BBDD con la que está trabajando. Para ello emplearemos la consulta DROP TABLE, según la siguiente sintaxis genérica:

DROP TABLE IF EXISTS nombreDeLaTabla;

Pero ten cuidado. Al igual que ocurre con las BBDD, la eliminación de una tabla es irreversible. Se pierde todo: estructura y datos.

El lenguaje SQL permite la creación de índices que el motor de BBDD usará para agilizar la búsqueda de registros, mediante la consulta CREATE INDEX. Por ejemplo, supongamos que, en la tabla de empleados que hemos creado, prevemos que vamos a necesitar hacer búsquedas por el nombre del empleado. El campo se llama nombre. Podemos crear un índice adecuado con la consulta.

CREATE INDEX indicePorNombre ON empleados (nombre);

Como norma general, la sintaxis para la creación de un índice es la que aparece a continuación:

CREATE INDEX índice ON tabla (campo);

El índice no es gestionado por ninguna consulta SQL específica, sino que es el propio motor de BBDD el que, de forma transparente, lo mantiene actualizado cuando se crean, modifican o eliminan registros y el que lo usa para la localización de los mismos. La adición, edición y eliminación de datos se tratará en la siguiente sección.

Para eliminar un índice usaremos la consulta DROP INDEX, tal como aparece a continuación:

DROP INDEX índice;

Esto no presenta mayor problema, ya que, mientras conservemos las tablas, el índice puede volver a crearse cuando sea necesario.

Y una cuestión importante. En ocasiones es necesario modificar la estructura de una tabla, conservando la información que ya contiene. Esto ocurre más a menudo de lo que parece, ya que las necesidades de los usuarios de la aplicación evolucionan y hay que incorporar nuevos datos o eliminar o modificar algunos de los que ya existen. Antes de la aparición de SQL, esta tarea podía llegar a ser realmente engorrosa. La estructura de una tabla puede ser modificada si es necesario mediante la consulta ALTER TABLE, cuya sintaxis genérica es la siguiente:

ALTER TABLE tabla
ADD campo definicionDelCampo,
CHANGE campoAntiguo campoNuevo definicionDelCampo,
DROP campo;

Lo primero que tenemos que especificar es, por supuesto, el nombre de la tabla sobre la que vamos a efectuar las modificaciones que necesitemos. Por supuesto, dicha tabla deberá existir en la BBDD en uso.

A continuación, podemos añadirle campos nuevos a la tabla, mediante la cláusula ADD, cambiar el nombre y la definición de campos ya existentes mediante la cláusula CHANGE, o eliminar campos mediante la cláusula DROP.

Por supuesto, no es necesario que en una consulta de este tipo aparezcan las tres cláusulas, sino sólo aquellas que necesitemos usar. Además, cada cláusula que incluyamos puede aparecer varias veces en la consulta. Por ejemplo, puedes tener que añadir dos, tres o más campos a tu tabla. Para cada uno de los campos nuevos usarás una línea con la cláusula ADD. Si necesitas llevar a cabo varios cambios o eliminaciones, podrás usar todas las cláusulas CHANGE o DROP que requieras.

CONSULTAS DE DATOS

En el próximo artículo desarrollaremos las consultas de datos, para no hacer este tema demasiado pesado. Por ahora lo dejamos aquí.

     

2 comentarios:

  1. Pingback: PHP-TUT-23 Bases de datos SQL (II) » eldesvandejose.com

  2. Thanks a ton for being our tutor on this niche.
    My spouse and i enjoyed the article greatly and most of all enjoyed how you handled the areas I considered to be controversial.
    You happen to be always very kind towards readers like me
    and help me in my lifestyle. Thank you.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *