Would start with this reference:

http://en.wikipedia.org/wiki/Schema_migration

In my humble opinion everything that a migration can do the PHPMyAdmin can also do.

Perhaps for now i'll will stick with PHPMyAdmin. Unless needs arise.

thanks again for that link.

Use Laravel Migration to easy structure your tables and Model, if you use Seeders you'll understand that Migration is very helpful.

Another reason, maybe, is when you upload your project on Git, your project mates will just fork the project, config the database and run "php artisan migrate" without uploading any sql files and going to phpMyAdmin.

Simple. Migrations are essentially version control for your database, they keep a record of how your database was created and altered over time, and migrations and seeders make it easier to re-deploy the application, or distribute it to other people.

If you don't use migrations, there is no record of your database structure bundled into your app - unless you keep a copy of the schema dump somewhere. As mentioned above, with migrations you install your app, configure the database connection and then run "php artisan migrate" to instantly set the database up again.

@andrew

Thanks dude for your answer, yup I watch Jeffrey Way video agian. And yes the right answer is "Version Control for Database".

thanks guys.

I agree with all answers in here but..

I think migration is suit for development but not for production.

@iridion9 can you point the link of "Version Control for Database"

I used the migration and it was painful.

For the point that you can version your shema, why can't you version one or more incremental "schema.sql" files, end execute and update it when necessary? Faster, lesser pain and lesser code to manage.

These some of the points:

1. all that you do there require to know and think in SQL-like language, but more verbose and with lesser expression power than native sql. So you need to know 2 programming language and write more code than use a single, more powerful programming language and write in it.

2. It's SLOOOOOOOOOOOOOwer. Try to have a single script of 1MB or a migration of 100K, the first complete faster, because the queries are executed in block and the php engine is not activated to elaborate them row by row.

3. It's a pain to debug, try to get some error, as in point 1 you have to think in sql and then translate your fix in migration statements.

4. Since it's have a longer time execution is lesser stable on remote connections.

5. If you have a trouble and it breaks at half migration, it's a pain. It left an inconsistent DB and you have to manually touch here and there to try to fix. Acually, I found that the faster solution is delete all tables and restart (which become a very SLOOOOOOOOOW iteration process based on very SLOOOOOW attempt steps). In SQL you can use something called "transaction" so you can do all or nothing, on even group your queries in incremental steps so you can go on from the nth transaction, granting that all before this point is working.

6. What if you have to update your DB in production? (you should not, but you know, customers want fix for yesterday online and sometimes it happens) Should you execute migrations in productions? Or what? Risk of unmanaged error hidden behind the migrations, useful php code mixed to sql manual intervention, and other unnecessary problems

7. 1, 2, 3, 4, 5 and 6 mix toghether, generating a development process that makes more a pain that is greater than the sum of the single pains.

So personally, I will avoid migrations in any future project

Migrations are not good. You can't specify column or index length. And there are more flaws. For serious database solutions it is very awkward.

Migrations as a paradigm are important and very useful. If you don't see why then I suggest using them often in multiple projects until you gain more experience.

That said, you don't have to use Laravel's Schema tool etc. You can use SQL with PDO or Laravel's query-builder etc so that you can have more fine grained control.

As a person working on several huge projects with so many different frameworks; I will go and say migrations are the easiest ways for different things.

• I'm working with 70 developers on a product and we should have the latest database structure without changing the data we currently have on our local environments.
• We can always track back our database and use git blame to find out who did what.
• We can insert comments within our migration files so it is understandable for everyone.
• We can deploy our new releases without touching our current database structure and data.
• It is easy to automize deployments.
• It is easy to create temporary databases to run tests.

Saying all these; my choice would be phinx package for migrations.

3. It's a pain to debug, try to get some error, as in point 1 you have to think in sql and then translate your fix in migration statements.

You can put raw SQL into migrations to gain both the benefits of a familiar SQL interface and migration version tracking in all environments. This also enables commands like "php artisan migrate:rollback" to help if you need to undo something after it has migrated and ":refresh" to test rebuilding in a new RDBMS version. (Assuming you write the 'down' methods too.)

4. Since it's have a longer time execution is lesser stable on remote connections.

Even without PHP and Laravel SQL changes can be slow and even block other work on your site/service. Consider executing inside a Screen or Tmux session that won't time-out or stop when unintended disconnections happen.

5. If you have a trouble and it breaks at half migration, it's a pain. It left an inconsistent DB and you have to manually touch here and there to try to fix. Acually, I found that the faster solution is delete all tables and restart...

In a development environment that approach can work. In production deleting everything risks significant downtime to restore the data with the original structure. Tools like Percona Online Schema Change can help somewhat since they won't change the in-use DDL until the new table copies are ready (disclosure: I made a wrapper for it to work with Laravel migrations natively, called laravel-online-migrations.) Postgresql has transactional DDL to help in these scenarios too. You could wrap migration code in a DB transaction if you like.

All that said, whatever solution chosen you and your successors will have to live with. Having created and inherited some unusual arrangements my preference is to stick with idiomatic solutions wherever possible.

Migrations are a type of version control for your database it modify the database schema and stay up to date on the current schema state.

Migration are really helpful like ,

Multiple developers on the same project makes migrations an absolute essential! also sometime you need insert demo data so you insert record through phpmyamdin but through migration and seeder you easily migrate your demo data.