Por lo general, cuando se trata de claves foráneas en lo que a mi respecta, me parece mas sencillo, hacerlo de este modo.
- Creo la Migración que crea la tabla inicial
- Creo la Migración que crea la tabla segundaria
- Creo la migración que agrega un campo relacionado en la tabla secundaria y creo la clave foránea que hace referencia a la primera
Supongamos un ejemplo sencillo de un diario en línea donde tengo noticias y cada entrada del diario puede tener fotos relacionadas.
Esto significa que por cada publicación del diario podemos tener asociadas ninguna, una o varias fotos.
Aquí empiezo a detallar las migraciones
Primero creo la tabla primaria del diario
<?php
use Illuminate\Database\Migrations\Migration;
use Illuminate\Database\Schema\Blueprint;
use Illuminate\Support\Facades\Schema;
class CreateDiarioTable extends Migration
{
/**
* Run the migrations.
*
* @return void
*/
public function up()
{
Schema::create('diario', function (Blueprint $table) {
$table->id();
$table->date("fecha");
$table->text("entrada");
$table->timestamps();
});
}
/**
* Reverse the migrations.
*
* @return void
*/
public function down()
{
Schema::dropIfExists('diario');
}
}
Segundo creo la tabla de las fotos
<?php
use Illuminate\Database\Migrations\Migration;
use Illuminate\Database\Schema\Blueprint;
use Illuminate\Support\Facades\Schema;
class CreateFotosTable extends Migration
{
/**
* Run the migrations.
*
* @return void
*/
public function up()
{
Schema::create('fotos', function (Blueprint $table) {
$table->id();
$table->string('foto');
$table->timestamps();
});
}
/**
* Reverse the migrations.
*
* @return void
*/
public function down()
{
Schema::dropIfExists('fotos');
}
}
Tercero agrego el campo que relaciona el diario con las fotos y le especifico que es una clave foranea
<?php
use Illuminate\Database\Migrations\Migration;
use Illuminate\Database\Schema\Blueprint;
use Illuminate\Support\Facades\Schema;
class AlterFotosForeignkey extends Migration
{
/**
* Run the migrations.
*
* @return void
*/
public function up()
{
Schema::table('fotos', function (Blueprint $table) {
$table->unsignedBigInteger('diario_id')->nullable(false);
$table->foreign('diario_id')->references("id")->on("diario");
});
}
/**
* Reverse the migrations.
*
* @return void
*/
public function down()
{
Schema::table('fotos', function (Blueprint $table) {
$table->dropForeign('fotos_diario_id_foreign');
$table->dropColumn('diario_id');
});
}
}
Lo importante a tener en cuenta, es que el campo diario_id de la tabla segundaria, debe ser el mismo tipo de la tabla primaria, ademas si es unsigned también hay que poner ese valor.
En la tercera migración se destaca que el campo que va a relacionar ambas tablas debe ser unsignedBigInternet y no puede ser null.
$table->unsignedBigInteger('diario_id')->nullable(false);
Ademas de todo que explicamos con un ejemplo de la vida real, podemos hacer que las elimnaciones y actualizaciones sean en cascada.
$table->unsignedBigInteger('diario_id')->nullable(false)->onUpdate('cascade');
$table->unsignedBigInteger('diario_id')->nullable(false)->onDelete('cascade');
Dependiendo del tipo de comportamiento , si elijo onDelete por ejemplo, significa que si borro un registro del diario, me va a eliminar simultáneamente también las fotos relacionadas.
Si elijo onUpdate por ejemplo, significa que si actualizo un registro, me va a actualizar automáticamente las fotos relacionadas pero sería un caso totalmente hipotetico.
Comentarios
Publicar un comentario
Formulario: