Migration de la base de données de l’Onironaute

Il est sans doute possible, au prix d’un certain effort, de pouvoir utiliser la base de données actuelle de l’Onironaute telle quelle, mais dans un souci de propreté, j’ai préféré repartir sur une base propre. C’est pourquoi, plutôt que de triturer mes modèles pour qu’ils s’adaptent aux spécificités de l’ancienne base, qui ne respecte aucune convention, j’ai jugé préférable de migrer toute l’ancienne base vers un nouveau schéma, mieux organisé, et surtout nativement compatible avec Laravel.

Les anciennes tables

  • actions : Historique des actions impactant la BDD (insert, update, delete). Je ne m’en suis au final jamais servi
  • commentaires : Liste de tous les commentaires, avec un user_id (possibilité qu’il soit vide pour les commentaires anonymes), un timestamp et un soft delete
  • droits : une simple liste des noms des différents statuts (User, modérateur, admin, etc), avec une valeur correspondant au droit qui leur étaient associé
  • favoris : une liaison n-n entre les utiliateurs et leurs rêves favoris. Sous-exploité en V1
  • figurants : une liste de tous les figurants (Ou « personnages de rêve »), avec le nom véritable, le pseudo, une description, et l’id du membre associé
  • ip_bannies : une liste d’IPs interdites de commentaires
  • prenoms : la base de données de prénoms, servant à la suggestion de pseudo pour les figurants
  • presence : relation n-n figurants - rêves
  • reves : les contenus des rêves de chaque utilisateur
  • urls : association d’un type/id de contenu à une url unique
  • urls_courtes : raccourcisseur d’urls interne, peu utilisé
  • users : les membres du site

Correction de bugs mineurs

Comme j’avais omis de créer une unicité sur les emails des membres (Et que je veux en créer une sur la nouvelle base), il va falloir fusionner deux éventuels comptes possédant des emails identiques.

Les schémas des nouvelles tables

Je ne vais pas lister ici tous mes schémas de migration, seulement celui des figurants, qui me semble ici le plus complet de tous (Liaisons externes entre plusieurs tables).

Par souci de conformité, j’ai préféré (Même s’il s’agit d’un site exclusivement francophone), d’utiliser l’anglais comme convention de nommage de mes tables, classes etc.
Les figurants deviennent donc ici des « characters ».

<?php
use Illuminate\Database\Migrations\Migration;
use Illuminate\Database\Schema\Blueprint;
class CharactersTableCreate extends Migration
{
    /**
     * Run the migrations.
     *
     * @return void
     */

    public function up()
    {
        Schema::create('characters', function (Blueprint $table) {
            $table->increments('id');
            $table->integer('user_id')->unsigned()->index();
            $table->string('name');
            $table->string('real_name');
            $table->text('description');
            $table->longtext('text');
            $table->softDeletes();
            $table->timestamps();
            $table->foreign('user_id')->references('id')->on('users');
        });
        Schema::create('character_dream', function (Blueprint $table) {
            $table->integer('character_id')->unsigned()->index();
            $table->integer('dream_id')->unsigned()->index();
            $table->timestamps();
            $table->foreign('character_id')->references('id')->on('characters')->onDelete('cascade');
            $table->foreign('dream_id')->references('id')->on('dreams')->onDelete('cascade');
        });
    }
    /**
     * Reverse the migrations.
     *
     * @return void
     */

    public function down()
    {
        Schema::drop('character_dream');
        Schema::drop('characters');
    }
}

On y voit ici la création des tables « characters » et « character_dream », qui remplaceront les anciennes tables « figurants » et « presence ».

J’utilise ici des clés étrangères sur les champs user_id, dream_id et character_id, ainsi qu’une cascade sur la suppression dans la table « character_dream ». Ainsi, si un utilisateur ou un rêve est supprimé, la ou les lignes correspondantes de la table character_dream seront également supprimées, conservant ainsi la cohérence de la base de données.

On y voit aussi la méthode « drop », qui supprime les tables en cas de « revert »

Le « seeding » des nouvelles tables

Laissez votre commentaire