Populate database in Laravel

@rory it's better to create those in sql file and u can run those using mysql cmd source command its fast.

@rory https://laravel.com/docs/master/seeding

You can seed from any source: an array, CSV file, JSON file, and so on.

I'm bit confused, from this discussion (https://laracasts.com/discuss/channels/general-discussion/seeding-with-real-data) I see that seeders are for producing/testing data. I'm actually working with real data and for the moment I have the data to fill just one column in my table.

If you read that thread again, you'll see that people use seeders in production all the time.

Seeders are a great way to set up default values in your database, such as roles and permissions, for example.

Most tutorials out there show you how to take data from the user, or from an API, and then put it into the database.

"normal" data flow is User > PHP variables > Database. In your case, you can skip that first step and just put the data you have in the database.

@36864 thanks a lot! I'm trying to use seeder now....just figuring out where to put my code and from where can read variables...as you said there are few tutorials about this, maybe it is just too simple and I'm not seeing it.

I've recently migrated away from my WordPress blog to one I've built myself using Laravel. For this, I've used seeders to copy the database:

<?php

use Illuminate\Database\Seeder;
use Illuminate\Support\Facades\DB;

class DatabaseSeeder extends Seeder
{
    /**
     * Run the database seeds.
     *
     * @return void
     */
    public function run()
    {
        // And then the WordPress posts and comments
        DB::unprepared(File::get(base_path() . '/database/seeds/wpposts.sql'));
        DB::unprepared(File::get(base_path() . '/database/seeds/wpcomments.sql'));
        DB::unprepared(File::get(base_path() . '/database/seeds/wpterms.sql'));
        DB::unprepared(File::get(base_path() . '/database/seeds/wptags.sql'));
        DB::unprepared(File::get(base_path() . '/database/seeds/wppostterms.sql'));
    }
}

The SQL files are just plain SQLdumps/exports from the WP-database, retrieved using PHPMyAdmin, added to the database folder and called by running

php artisan migrate --seed

That's all there is to it :)

@Thyrosis The problem with having production data in seeders, is if you ever run the seeder again(php artisan migrate --seed), you'll reinsert all of that data again causing duplicates. I like putting production data in the actual migration files just after Schema::create(), so it will only ever run once when the migration is run.

@Cronix good point, never thought about it that way!

Hi,

Sorry for my english, I'll try to do my best.

I can see @Cronix 's point. What's more there is another problem, I guess. Rollback a particular migration or create a new one might deprecate your seed data. For example, if you rollback a new table migration then your seed logic that populates this table will fail. Another example would be if you modify a table throught a new migration and you don't update your seed file. That would might fail, too. Generally, you must have your "migrations", "current data in your database" and "seed data" syncronized all the time.

I use the @Cronix 's method but I usually split up the migration into two different migration files. The first one which defines the table schema and the second one to populated it (with a down method which deletes this default data) thus you can rollback only your data and keep your table's schema.

Thanks @Cronix and @jurios. I think I'll also put all in my migration, the idea of two separated files would be the best solution for me.

@jurios I have another question, once you make the second migration file to populate your table how do you connect the correspondent table schema?

Hi,

I use QueryBuilder, instead of plain SQL. So you could insert data in a table with:

DB::table('table_name')->insert([]);

https://laravel.com/docs/5.6/queries#inserts

@jurios As said above, integrating data using a source (sql, json, or csv) should be much faster than doing it using the Querybuilder, if you have a lot of data...