The philosophy of the teacher :: Part 2

En el post anterior lo último fue crear el modelo de datos según los requerimientos, para crear las tablas en la base de datos el paso siguiente fue crear las migraciones.

Para la creación de tablas el framework Laravel utiliza las migraciones que son un control de versiones para tu base de datos, más información pueden consultar en este enlace.

Lo primero que se debe realizar en el directorio del proyecto es ejecutar este comando para crear la migración, este proceso se realiza por cada tabla del modelo diseñado.

php artisan make:migration create_table_rubricas –create=rubricas

Como resultado se obtiene un archivo en el directorio database/migrations

El archivo generado Laravel lo crea con el siguiente nombre de archivo:

2017_04_20_164846_create_table_rubricas.php

Aqui una imagen del aspecto del directorio migrations:

Ahora revisaremos el contenido de la migración rubricas :

Laravel crea una clase con dos métodos up y down, para el método up de forma automática agrega dos campos para la nueva tabla  id y timestamps.

El campo id lo genera como primary key y para timestamps creara dos campos en la tabla que se identifican con el nombre created_at y updated_at.

En mis desarrollos era muy común que para todas las tablas tanto en sistemas de escritorio o web utilizará el primer campo de la tabla con un id numérico, por defecto autoincremento y no nulo para la primary key y funciona bastante bien… hasta que el mal uso de ello resulto critico en uno de mis proyectos,   desde entonces cuando creo una tabla sigo la siguiente regla: Si un registro (compuesto por un conjunto de campos) tiene un identificador natural este debe ser la clave primaria, de lo contrario y ante la falta de una clave natural se optara por asignar un id para la identificación del registro, creanme cuando uses claves naturales el DBA te lo va a agradecer.

Veamos un ejemplo práctico para la tabla países:

La imagen anterior muestra la tabla para los países y se opto usar id para la primar key, el error fue no considerar (en el análisis) que los códigos de los países estan normados en la ISO 3166-1 como puedes revisar en este enlace.

Según lo anterior puedo optar por tres tipos de códigos, mi opción fue elegir el Código alfa-2 otorgando mayor sentido al registro de un país y mayor aún a los registros relacionados.

Por ejemplo al no usar una clave natural, si necesito obtener todos los estudiantes de Chile usando id, el SQL podría ser de la siguiente forma (sin conocer el id de Chile):

SELECT usr.paterno, usr.materno, use.nombres, pais.nombre FROM usuarios as usr, pais as pais where usr.pais_id = pais.id and pais.descripcion = ‘Chile’;

¿Buen query?

Existe un gasto de tiempo/recursos estar averiguando el id de Chile para luego consultar por usr.pais_id=1, ¿y si “Chile” esta escrito “CHILE”? suma sigue.

Ahora si defino mi clave primaria según la norma ISO la tabla se vería de la siguiente forma.

El campo code a simple vista resulta naturalmente mucho más claro e identifica el registro por si solo, ¿ahora como seria el query anterior?.

SELECT paterno, materno, nombres, pais_code FROM usuarios where pais_code = ‘CL’;

Ahora consultando la tabla USUARIOS como se vería con la clave natural de país (countries_code) y siguiendo el estándar ISO.

Como se podrán dar cuenta usar claves naturales tiene más ventajas que desventajas y hacer nuestros modelos utilizando estándares de normalizaciones nos ayudara enormemente a representar fielmente el mundo real en nuestras bases de datos.

Hasta el próximo post.

Agregar un comentario

Su dirección de correo no se hará público. Los campos requeridos están marcados *