Skip to main content
2 of 4
edited title
Doc Brown
  • 214.1k
  • 34
  • 394
  • 603

Is it considered as best practice to use migration scripts for one-off large data manipulation over a table?

I have inherited a project via laravel that uses its database migration mechanism coming from the framework. The application has the following table named actions:

action_log_id SERIAL PK
user_id INT 
action_desc VARCHAR
awarded_points INT
date

And I want to add a column that records that awardee hence, I did the following migration script:

use Illuminate\Support\Facades\Schema;
use Illuminate\Database\Schema\Blueprint;
use Illuminate\Database\Migrations\Migration;

class ActionAwardee extends Migration
{
    /**
     * Run the migrations.
     *
     * @return void
     */
    public function up()
    {
        Schema::table('actions', function (Blueprint $table){
            if (!Schema::hasColumn('actions', 'awardee')) {
                $table->string('awardee')->nullable();
            }
        });
    }

    /**
     * Reverse the migrations.
     *
     * @return void
     */
    public function down()
    {
        Schema::table('actions', function (Blueprint $table){
            if (Schema::hasColumn('actions', 'awardee')) {
                $table->dropColumn('awardee')
            }
        });
    }
}

But also I know that under some circumstances the awardee can take some dixed values for example if a record is before 2018 the awardee has value website, hence I can populate the table with some values. The population will be en bulk and it will be one-off field population.

Therefore I want to ask the $ 1.000.000 question (in zibabwe dollars) is it good idea to create yet another migration cript for data manipulation or I should do it manually once my application is deployed?