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

Question

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 fixed 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 script for data manipulation or I should do it manually once my application is deployed?

Answer 1

There is nothing wrong in providing default values for certain or all records immediately when new columns are added to a database table. In fact, this could be mandatory to bring the system to a working state again after addding some column, for example, when the new column shall get a NOT NULL constraint.

On Stackoverflow, you can find examples like this one showing how this can be done in Laravel directly inside the up method of a migration.

The only reason I can think of why one may not want to implement it there directly is when altering the DB schema must be decoupled for some reason from altering /adding the data. Imagine a bundle of schema changes which must run now to bring the system back online, but the default initialization for a new column requires several hours and could block the whole process. In my experience, those cases are rare, but YMMV.

And please, do yourself a favor and stop thinking in terms of braindead "best practices". You don't make a decision about or against picking such an approach because "everyone else does it that way", but because it is a solution which suits your needs, without being more complex than necessary - or not.