domingo, 18 de mayo de 2014

Temas desarrollados en AXES & MY SQL

           




  
* MYSQL, REFERENCIA DE USO DELCOMANDO 'ALTER TABLE'




En SQL, 'Alter' es un comando de la categoría DDL (Data Definition Language) y como su nombre lo indica sirve para alterar objetos ya creados en un base de datos, su uso principal es la modificación de tablas. Como en otros artículos de LinuxTotal.com.mx enseñaré su sintaxis a través de varios ejemplos de uso. Se asume que ya tienes creada la base de datos y que sabes como usar el monitor (interface de línea de comandos de MySQL), asi que esta guía es como un referencia rápida (cheat sheet) para cuando la requieras.


REFERENCIA DE USO DE 'ALTER TABLE' EN MYSQL
SOBRE LA TABLA
ALTER TABLE ejemplo ENGINE = InnoDB
Cambiar el tipo de motor (engine) de la tabla 'ejemplo'
ALTER TABLE personas RENAME usuarios
Cambia el nomnbre de la tabla 'personas' a 'usuarios'
ALTER TABLE ejemplo AUTO_INCREMENT=1000
En la tabla 'ejemplo' cualquiera que sea la columna que tenga 'AUTO_INCREMENT' en sus propiedades (solo puede haber una), los nuevos registros comenzarán a partir de '1000' o cualquier número indicado, no es posible utilizar un valor ya existente.
ALTER TABLE ejemplo CONVERT TO CHARACTER SET latin1
La tabla 'ejemplo' ahora almacenará sus valores en base al juego de caracteres 'latin1' (iso-8859-1).
OPERACIONES CON DROP
ALTER TABLE ejemplo DROP COLUMN nombre
Elimina la columna 'nombre' de la tabla 'ejemplo'.
ALTER TABLE ejemplo DROP COLUMN nombre, DROP COLUMN paterno
Elimina más de una columna.
ALTER TABLE ejemplo DROP COLUMN nombre, DROP COLUMN paterno
Elimina más de una columna.
ALTER TABLE ejemplo DROP INDEX usuario
Elimina el índice 'usuario'.
ALTER TABLE ejemplo DROP PRIMARY KEY
Elimina la llave primaria de la tabla 'ejemplo'
ALTER TABLE ejemplo DROP FOREIGN KEY id_usuario
Elimina de la tabala 'ejemplo' la llave foranea 'id_usuario'.



  *SQL >SQL Avanzado >PRIMARY KEY
La clave primaria, PRIMARY KEY, identifica de manera única cada fila de una tabla.
La columna definida como clave primaria (PRIMARY KEY) debe ser UNIQUE (valor único) y NOT NULL (no puede contener valores nulos).
Cada tabla sólo puede tener una clave primaria (PRIMARY KEY).
Ejemplo PRIMARY KEY , clave primaria en MySQL
CREATE TABLE personas { identificador int NOT NULL, nombre varchar(255) NOT NULL, apellido1 varchar(255) NOT NULL, PRIMARY KEY (identificador) }
Ejemplo PRIMARY KEY , clave primaria en ORACLE, SQLSERVER, ACCESS
CREATE TABLE personas { identificador int NOT NULL PRIMARY KEY, nombre varchar(255) NOT NULL, apellido1 varchar(255) NOT NULL, }
La clave primaria (PRIMARY KEY) puede estar compuesta por varias columnas, por ejemplo por las columnas 'identificador' y 'nombre', entonces se define así:
CREATE TABLE personas { identificador int NOT NULL, nombre varchar(255) NOT NULL, apellido1 varchar(255) NOT NULL, CONSTRAINT pers PRIMARY KEY (identificador, nombre) }
La clave primaria también se puede definir después de haber creado la tabla, para eso utilizaremos el comando ALTER TABLE



              * 1.7.5.5. Claves foráneas (foreign keys)
                       En MySQL Server 3.23.44
y posteriores, el motor InnoDB soporta chequeo para restricciones de claves foráneas, incluyendo CASCADE, ON DELETE, y ON UPDATE. Consulte Sección 15.6.4, “Restricciones (constraints) FOREIGN KEY.
Para otros motores diferentes a InnoDB, MySQL Server parsea la sintaxis de FOREIGN KEY en comandos CREATE TABLE, pero no lo usa ni almacena. En el futuro, la implemantación se extenderá para almacenar esta información en el fichero de especificaciones de las tablas de forma que puedan obtenerla mysqldump y ODBC. En una etapa posterior, restricciones de claves foráneas se implementarán para tablas MyISAM.
Restricciones de claves foráneas ofrecen distintos beneficios a los diseñadores de bases de datos:
  • Suponiendo un diseño adecuado de las relaciones, las restricciones de claves foráneas hacen más difícil que un programador introduzca inconsistencias en la base de datos.
  • Chequeo centralizado de restricciones por el servidor de base de datos hace que sea innecesario realizar esos chequeos en la parte de la aplicación, eliminando la posibilidad que distintas aplicaciones puedan no chequear todas las restricciones de la misma forma.
  • Usando actualizaciones y borrados en cascada puede simplificarse el código de aplicación.
  • Reglas diseñadas correctamente para claves foráneas pueden ayudar a documentar las relaciones entre tablas.
Tenga en cuenta que estos beneficios tienen el coste de un trabajo adicional para el servidor de base de datos para poder realizar todas las comprobaciones necesarias. Chequeos adicionales por parte del servidor afectan al rendimiento, lo que puede ser lo suficientemente malo para algunas aplicaciones como para evitarlo todo lo posible. (Algunas grandes aplicaciones comerciales han codificado la lógica de claves foráneas en el nivel de aplicación por esta razón.)
MySQL proporciona a diseñadores de bases de datos la posibilidad de elegir qué paradigma elegir. Si no necesita claves foráneas y quiere evitar la sobrecarga asociada con la integridad referencial, puede usar otro tipo de tabla como MyISAM. (Por ejemplo, el motor MyISAM ofrece muy buen rendimiento para aplicaciones que sólo realizan operaciones INSERT y SELECT, ya que las inserciones de pueden utilizar de forma concurrente con consultas. Consulte Sección 7.3.2, “Cuestiones relacionadas con el bloqueo (locking) de tablas”.)
Si elige no utilizar integridad referencial, tenga en cuenta las siguientes consideraciones:
  • Sin un chequeo por parte del servidor de integridad referencial, la aplicación debe realizar este trabajo. Por ejemplo, debe tener cuidado de insertar registros en tablas en el orden apropiado, y evitar crear registros con hijos huérfanos. También debe ser capaz de recuperarse de errores que ocurran durante inserciones múltiples.
  • Si ON DELETE es la única integridad referencial que necesita la aplicación, desde la versión 4.0 de MySQL Server puede usar comandos DELETE para borrar registros de distintas tablas con un único comando. Consulte Sección 13.2.1, “Sintaxis de DELETE.

                                Relaciones entre tablas

Vamos a ver lo sencillo que puede llegar a ser crear relaciones entre tablas en mysql correctamente y saber obtener los datos de cada una de forma sencilla. En los tutoriales sobre ORMS con laravel y codeigniter pudimos ver todos los tipos de relaciones.

Saber manejar correctamente las relaciones de una base de datos es algo fundamental para un programador, si este trabajo no es llevado a cabo de forma correcta, seguramente cuando la aplicación crezca lo pagaremos con creces, así que no es mala idea invertir un tiempo en aprender todo lo que podamos al respecto.

Entendiendo las relaciones en mysql


Qué mejor que ver todos los casos posibles de relaciones que se nos pueden dar para terminar de entenderlos de forma sencilla.

Relaciones de uno a uno


Estas relaciones existen por ejemplo en el caso de una persona y su dni, una persona sólo puede tener un dni, y un dni sólo puede pertenecer a una persona.

Para llevar a cabo esta relación en nuestra base de datos simplemente debemos crear nuestra tabla usuarios y nuestra tabla dnis, para hacer referencia al dni de cada usuario nos basta con crear un campo en la tabla dnis el cuál actuará como clave foránea haciendo referencia al usuario a través de su id.

Relaciones de uno a muchos


El ejemplo perfecto para estas relaciones es entre usuarios y posts de un blog, un usuario puede tener muchos posts, pero un post sólo puede pertenecer a un usuario, sirve lo mismo que en la relación de uno a uno. La única diferencia entre estas dos relaciones en este aspecto, es que la clave foránea entre usuarios y dnis puede estar tanto en la tabla usuarios con un campo id_dni como en la tabla dnis con un campo id_usuario.

En cambio, en una relación de uno a muchos la clave foránea siempre debe estar en la tabla que hace la relación de muchos, en este caso sería la tabla posts.

Relaciones de muchos a muchos


Este tipo de relaciones vienen a ser las más complicadas, aunque realmente no lo son, para el ejemplo podemos decir que la relación entre usuarios y peliculas(alquileres de un videoclub), un usuario puede alquilar muchas películas, y una película puede ser alquilada por muchos usuarios.

Estas relaciones no pueden ser llevadas a cabo con simples claves foráneas ya que necesitaríamos una por cada registro, cosa completamente inviable. Para este tipo de relaciones debemos crear una tercera tabla, conocida como tabla pívote, que por convención su nombre suele ser usuarios_peliculas para nuestro caso, es decir, los nombres de las dos tablas separados por guiones.

Estas tablas deben contener como mínimo dos campos, usuario_id y pelicula_id que harán referencia a las claves primarias de sus respectivas tablas.

La función de esta tabla es la de poder enlazar a los usuarios y las películas a través de sus claves primarias, es decir, si tenemos un usuario con id 1 y una película con id 120 en sus respectivas tablas, para poder unirlos, deberíamos crear un nuevo registro en la tabla usuarios_peliculas con esos datos.

Para tenerlo más claro, veamos un sencillo diagrama sobre las relaciones de las que hemos hablado y como debemos interpretarlas en nuestra base de datos.

1x1.trans
Para ver correctamente el diagrama pulsa sobre la imagen.

Normalización


Un proceso interesante en lo que refiere a la normalización viene a ser el evitar la duplicidad de datos en la misma tabla, si por ejemplo tenemos teléfonos fijos en nuestra tabla usuarios, puede ser que éstos sean repetidos por los mismos miembros de un misma familia, para evitarlo, es recomendable crear otra tabla por ejemplo llamada telefonos_fijos que contenga un campo id autoincremental y que sea clave primaria y un campo teléfono que sea UNIQUE.

De esta forma, al registrar nuevos usuarios, en vez de guardar su teléfono en la tabla usuarios, lo que haremos será comprobar si el teléfono existe en la tabla telefonos_fijos, y si no es así, crearemos el registro en esta tabla.

Para relacionar el teléfono al usuario, deberemos crear una clave foránea en la tabla usuarios que haga referencia a su teléfono, así de sencillo.



         Consultas mysql para obtener registros

En bases de datos, una consulta es el método para acceder a los datos en las bases de datos. Con las consultas se puede modificar, borrar, mostrar y agregar datos en una base de datos. Para esto se utiliza un lenguaje de consultas. El lenguaje de consultas a base de datos más utilizado es el SQL.

Técnicamente hablando, las consultas a la base de datos se realizan a través de un lenguaje de manipulación de datos (DML – Data Manipulation Language). SQL es un lenguaje DML, pero además posee otras características de otros lenguajes. Por ejemplo, permite también crear bases de datos.
La consulta básica en SQL es llamada select-from-where.
Obtener registros de uno a uno, datos y dni de un usuario.

1
2
3
4
5
SELECT u.nombre,u.direccion,p.titulo,p.contenido
FROM usuarios u
INNER JOIN posts p
ON u.id = p.id_usuario
WHERE u.id = 1

Crear un formulario en blanco

  1. Para crear un formulario sin controles ni elementos con formato previo: en la pestaña Crear, haga clic en Formulario en blanco. Access abre un formulario en blanco en la vista Presentación y muestra el panel Lista de campos.
  2. En este Lista de campos panel, haga clic en el signo más (+) situado junto a la tabla o las tablas que contienen los campos que quiera ver en el formulario.
  3. Para agregar un campo al formulario, haga doble clic en él o arrástrelo hasta el formulario. Para agregar varios campos a la vez, mantenga presionada la tecla CTRL y haga clic en varios campos. Después, arrástrelos todos juntos hasta el formulario.
 Nota    El orden de las tablas en el panel Lista de campos puede cambiar según qué parte del formulario esté seleccionada en ese momento. Si no puede agregar un campo al formulario, pruebe a seleccionar otra parte distinta e intente agregar el campo de nuevo.
  1. Use las herramientas del grupo Controles en la pestaña Herramientas de presentación de formulario para incluir en el formulario un logotipo, un título, números de página o la fecha y la hora.
  2. Si desea agregar una mayor variedad de controles al formulario, haga clic en Diseño y use las herramientas del grupo Controles.


        Comando DROP
TABLE borra una o más tablas. Debe tener el permiso DROP para cada tabla. Todos los datos de la definición de tabla son borrados, así que tenga cuidado con este comando!
Use IF EXISTS para evitar un error para tablas que no existan. Un NOTE se genera para cada tabla no existente cuando se usa IF EXISTS. Consulte Sección 13.5.4.22, “Sintaxis de SHOW WARNINGS.
RESTRICT y CASCADE se permiten para hacer la portabilidad más fácil. De momento, no hacen nada.
Nota: DROP TABLE hace un commit automáticamente con la transacción activa,a no ser que use la palabra TEMPORARY.
La palabra TEMPORARY tiene el siguiente efecto:
  • El comando sólo borra tablas TEMPORARY.
  • El comando no acaba una transacción en marcha.
  • No se chequean derechos de acceso. (Una tabla TEMPORARY es visible sólo para el cliente que la ha creado, así que no es necesario.)
Usar TEMPORARY es una buena forma de asegurar que no borra accidentalmente una tabla no TEMPORARY.
Para eliminar los registros de una tabla usamos el comando "delete":
 delete from usuarios;
Muestra un mensaje indicando la cantidad de registros que ha eliminado.
Si no queremos eliminar todos los registros, sino solamente algunos, debemos indicar cuál o cuáles, para ello utilizamos el comando "delete" junto con la clausula "where" con la cual establecemos la condición que deben cumplir los registros a borrar.
Por ejemplo, queremos eliminar aquel registro cuyo nombre de usuario es "Marcelo":
 delete from usuarios
 where nombre='Marcelo';
Si solicitamos el borrado de un registro que no existe, es decir, ningún registro cumple con la condición especificada, ningún registro será eliminado.
Tenga en cuenta que si no colocamos una condición, se eliminan todos los registros de la tabla
 nombrada.
ejemplo
      
          DELETE [LOW_PRIORITY] [QUICK] [IGNORE] FROM tbl_name
         [WHERE where_definition]
         [ORDER BY ...]
         [LIMIT row_count]
      
 editado por Silvia Flores
                    Conalep 408 INFORMATICA

                    
 

No hay comentarios:

Publicar un comentario