I found there are lots of time taken procedures in handling database migration rules like adding new columns, changing column name, adding new foreign id etc. I used to develop custom large applications that have more than 50 tables. Well, personally I don't like to follow database migration rules. Because I can easily change tables as per my requirements. I have developed more than 200 Laravel custom applications and don't even follow database migration rules in any one. They don;t have any issue of maintenance. I want to use only the technology that saves my time. Do you guys know any major benefits of following database migration of Laravel?

CodePudding user response：

By strictly following migrations, you are codifying the history of your table and at the same time rely on versioning features of the git flow that you're using.

Some notable benefits:

• Able to identify who made the change
• Able to have a maker-approver flow during the git process
• Ease of knowing what change was made and when
• Ease of including seeders in the migration process to pre-populate tables

Even in the situation where you're developing solo, you'd still be documenting the history for your future self.

CodePudding user response：

Well, imagine your database somehow gets lost right, let's not consider the cause of this since that's out of the scope of the question. (Yes I understand this is a scenario that is very unlikely to happen, but let's roll with it for the purpose of explaining why migrations are a good thing)

You have 200 Laravel applications, WITHOUT database migrations, are you going to remember exactly how the databases are put together for all 200 applications? No, you're not. So now what?

Now imagine for all 200 Laravel applications, you made the migrations. Benefit of that is that they get added to your version control. Regardless of where you are, what system you're on or whatever. You can run these migrations and you have an up to date database.

Imagine you are working on a project in ongoing development. If you only have one database for live and production (which is bad practice in my humble opinion) you would need to change A LIVE database everytime you want to develop something database related on the development environment. Consider you have two databases, you would have to make those changes on dev environment first, test it, then apply same changes in live environment, that's time consuming. Now imagine you made migrations and all you had to do was run the new migrations on live environment and you're set. Way easier right?

Other benefits:

• When in a larger team, you know who made the migration and therefore who is responsible.
• You can already populate tables with data using seeders.
• You know exactly what changes were made to the database and you have a history of all changes available.