Simple analysis of database and database migration in Laravel framework

Laravel Framework's development method is agile and iterative, and you don't expect to get all the correct code the first time. Instead, we write code, test, and interact with our end users and refine our understanding.

For work, we need a supporting set of practices. We use version control tools like subversion, GIT or Mercurial to store the application's source code files, allowing us to undo errors and track changes during development.

But when the application changes, there are areas that we cannot effectively manage using version control alone. As our development progressed, the database schema of the Laravel application continued to evolve: we added a table here, renamed columns there, dropped indexes, and so on. Database changes are made in lockstep with application code.

You need a sophisticated way to track your database schema changes, and there are usually several approaches:

• When you work within a development team, everyone Need to know about any schema changes.

• When you deploy on a production server, you need to have a robust way to upgrade your database schema.

• If you are working on multiple machines, you need to keep all database schemas in sync.

Keeping the database schema in sync with the application code has historically been a very cumbersome task without strict conventions and disciplines for application developers to follow. The developer (or database administrator) makes the required schema changes. However, if the application code is rolled back to a previous version, it is difficult to undo the database schema changes, causing the database version information to be inconsistent with the application code version information.

Migration is Laravel's way of helping you evolve your application's data architecture without requiring you to delete or rebuild the database every time you make a change. No delete and rebuild means you don't lose data every time you make a change. The only change when you perform a migration is to move the database schema from one version to another, whether moving forward or backward.

Laravel migration provides you with a means to modify the database schema in an iterative manner. It does not require you to use SQL operations, but allows you to use PHP code. The Laravel schema generator allows us to quickly create database tables and insert columns or indexes. It uses a clean and expressive syntax to manipulate databases. You might think that Laravel migration is version control of your database.

By defining a higher-level interface for creating and maintaining database schemas, you can define it in a database-independent way. By using PHP to create tables, define columns and indexes, write the schema once and apply it to any supported database backend. As an added benefit, Laravel keeps track of which migrations have been applied and which ones still need to be applied.

Migration Basics

A Laravel migration is just the PHP source file in your application's app/database/migrations directory. Each file contains a set of changes to the underlying database. Changes to the database are made in PHP code rather than database specific SQL. Your PHP migration code is ultimately converted into DDL that matches your current database, making switching database platforms very easy. Since the migration code is stored in its own directory, it must be included in version control like other project code. Laravel migrations are run explicitly from the command line using Artisan tools.

Migration file naming convention

In older versions of Laravel, migrated files have simpler names, such as 001_create_employees_table.php. Laravel 3 (Laravel 4.1 and the same) brought a new naming convention where the first part of the name changed from a sequence number to something longer, like 2014_03_11_032903_create_employees_table.php. The file name is of the form YYYY_MM_DD_HHMMSS_some_meaningful_name.php, meaning a UTC timestamp identified followed by a migration name.

The new wider names help avoid name conflicts, and if you are a developer working on a team, you can check your own migrations.

Additionally, Laravel migrates the timestamps of files so that they can be executed sequentially. Timestamp numbers are key to migrations because they define which migration is applied in the order in which individual migration version numbers are applied.

Like SQL scripts, migrations are executed from the top, which requires these files to be executed. Sequential execution removes the possibility of trying to insert columns when the table does not exist.

Although you can create migration files manually, it is easier (and less error-prone) to use Artisan tools to generate migration scripts. You can edit these files later if needed.

Run migrations Forward and Backward

Use Artisan tools to migrate to the database. Laravel provides a set of artisan tasks that boil down to running a specific set of migrations.

[Note]You can run artisan list to view the list of tasks supported by artisan. Most data migration related tasks are prefixed with migrate:.

Just a few common tasks you need to know:

• migrate:install
  The first migration-related artisan task you use may be migrate:install. Internally, Laravel uses special tables to track which migrations have been run. To create this table, just use the artisan command line tool:
  $php artisan migrate:install

• migrate
  You will run the migrate task to frequently update your Database to support the latest tables and columns you add to your application. In its most basic form, it only runs the up() method on all migrations that have not yet been run. If there is no such migration, it will exit. It will run these migrations based on the date they were migrated.

• migrate:rollback
  Occasionally, mistakes are made when writing migrations. If you've already run the migration, you can't just edit the migration and run the migration again: Laravel assumes it has already run the migration, so when you run artisan again migrate, won't do anything. you have to use artisan migrate:rollback rolls back the migration, then edits the migration, and then runs artisan migrate to run the correct version.

In general, editing an existing migration is not a good idea: it will require extra work for you and your colleagues, and it will be a headache - if Migration of existing versions has been run on production machines. Instead, you need to write a new migration to perform the required changes.

[Note]artisan migrate:rollback will delete the last migration application. Laravel goes back to the entire migration "operation". Therefore, if the last migration command ran 15 migrations, all 15 migrations will be rolled back. Please note that when you delete a column or table, data will be lost.

migrate:reset
Roll back all migrations (all tables and data will be deleted)

migrate:refresh
artisan migrate:refresh task will delete the database and recreate it and will load the current schema. This is a convenient shortcut to run a reset and subsequently rerun all migrations.

migrate:make
artisan migrate:make command tells Laravel to generate a migration file skeleton (which is actually a PHP file) and store it in the app/database/migrations folder. You can then edit this file to flesh out your table/index definitions. Then, artisan When the migrate command is run, artisan will query this file to generate Actual code for SQL DDL.

Related recommendations:

How to connect laravel5 to sqlserver through freetds (code)

The above is the detailed content of Simple analysis of database and database migration in Laravel framework. For more information, please follow other related articles on the PHP Chinese website!