The article was forwarded from the professional Laravel developer community with the original link: https://learnku.com/laravel/t...

Key point 1. Use updateOrCreate() to avoid duplicate filling

Imagine this fill code, and imagine that for some reason this fill will be started multiple times:

public function run()
{
    $items = [
        ['id' => 1, 'title' => 'Administrator'],
        ['id' => 2, 'title' => 'Simple user'],
    ];

    foreach ($items as $item) {
        Role::create($item);
    }
}

The second attempt to perform a population may fail due to an ID conflict.In other cases, if you don't specify an ID, you may then fill the table with a lot of data and be duplicated.To avoid this situation, try the following:

foreach ($items as $item) {
    Role::updateOrCreate(['id' => $item['id']], $item);
}

Key 2. Run only one Seeder class

Earlier, I was surprised how many people didn't know that a fill class could be specified when executing the php artisan db:seed command.

php artisan db:seed

This command starts all the classes listed in the DatabaseSeeder.php file.

But you can restrict startup to an exact fill class:

php artisan db:seed --class=UsersTableSeeder

Key 3. Executing Seeder classes from migration files

Usually you need to create a new table and fill in some data right away.But you can't execute "artisan db:seed" right away during the build process, especially if you have an automated deployment program that only involves the "artisan migrate" command.

A small trick is to start a specific padding file from a migration file.

public function up()
{
    Schema::create('themes', function (Blueprint $table) {
        $table->increments('id');
        $table->text('name');
    });

    Artisan::call('db:seed', [
        '--class' => ThemesTableSeeder::class
    ]);
}

Key 4. Associated Seeder factory classes: Use parent factory classes

If you are building a factory class to populate your data, how do you handle the relationship between the two models?For example, do you need to fill in 10 contacts for 10 companies and 10 contacts for these companies?

Your database/factories/CompanyFactory.php will probably look like this:

$factory->define(App\Contact::class, function (Faker\Generator $faker) {
    return [
        'company_id' => factory('App\Company')->create()->id,
        'first_name' => $faker->firstName(),
        'last_name' => $faker->lastName,
        'phone1' => $faker->phoneNumber,
        'phone2' => $faker->phoneNumber,
        'email' => $faker->email,
        'skype' => $faker->word,
        'address' => $faker->address,
    ];
});

Did you find out how it populates the company_id?Use another factory directly.

Key point 5. DatabaseSeeder responds to local and production environments

Sometimes you just need to fill in some data in your local environment, but not in your production environment.Alternatively, use different padding files to populate different environments.

I'm not sure if this is the most elegant way to handle it, but it's how I used to organize the different fill classes in my local and production environments.

class DatabaseSeeder extends Seeder
{
    /**
     * Seed the application's database.
     *
     * @return void
     */
    public function run()
    {
        if (app()->environment() == 'production') {
            $this->call(ThemesTableSeeder::class);
            $this->call(LanguagesTableSeeder::class);
        } else {
            $this->call(UsersTableSeeder::class);
            $this->call(ModulesTableSeeder::class);
            $this->call(ThemesTableSeeder::class);
            $this->call(LanguagesTableSeeder::class);
        }
    }
}

Key point 6. Generate a Database-based fill class using iSeed

The last point can be said to be a tool I've used a lot of time myself, called iSeed Generator .

After the installation is complete, you can run the following command:

$ php artisan iseed users --force

This will generate the UsersTableSeeder.php file in your seeds directory, --force option is used to force overwriting of any existing fill class.

Key point 7. Run data filling in a production environment

Here's the main point. Finally, let's say a little common sense when building fill classes. In your local/staging local environment, you can run "artisan migrate:fresh--seed" repeatedly without any risk. It won't lose any important data, but in production environment you can only run "artisan db:seed"Once, and then forget about it entirely.If you want to populate the production environment with additional data, put it in the migration file as detailed in point 3.