Using database migrations vs workbench

Question

I use laravel framework but in fact it doesn't matter. The question is why should I use database migrations and how to properly work with database while developing your app.

For example, I'm building a large web app which will end up with 30+ tables. At the start I don't have database at all, I'm just starting to build it. It doesn't seem to be a good approach to make such migrations as: 1. Add user table 2. Add regdate field to user table 3. Add user rights table 4. Forget to add foreign key contstrains to user and rights table (linking ids) 5. Add photos table...

First, at first step I'll make most of my tables at once in such tool as mysql workbench. Say, 15 tables. Would I call it "database init" migration in laravel?

Then if I need to synchronize my changes I'll do it with workbench as it has such feature so there won't be any human error. If I work with a team I can share workbench model somewhere, keep it remove (not sure if I can load remote model, I'm not a workbench pro, but anyway I can upload changes if I changed something).

The only drawback that I can't rollback, but 1. Not sure if I really need this feature, usually I remember my changes and I can remove them and again synchronize through workbench 2. I can save a lot of workbench files doing the same migration system like in laravel

But what I like is that I can see all database at once with all relations, I can easily manage it (without writing code)

Answer 1

You don't need to create a new migration for every change you make during development. You can use php artisan migrate:refresh and continue to alter the existing migration file.

I personally do this until the site is either:

1. The database "design" is complete
2. Someone else in my team needs a copy of the database

Only when the possibility of forking exists (such as multiple programmers working on the application) do you need to create multiple migrations.

Think of it kind of like version control. During early stages of development, you probably won't create a commit every time something minor changes, but when you reach a point that some of your code needs to be forked during development you will commit/push.