在 Laravel 中使用一个项目的数据库的现有表到另一个项目

Question

I created a separate integration directory/project (let's call it as project-Interface) in Laravel and I created new DB (let's call it as DB-A) and 3 new tables ( table-a , table-b , table-c ) through artisan migrate command and models related to that as well in the solution.

Now there is a different project (let's call it as project-Web) in Laravel and it has its own database (let's call it as DB-B) and has its own tables and models created ( table-x , table-y , table-z ).

I need to do the following:

1. Can I use DB-B of table-x from project-Interface to save some details in it?
2. Can I create the tables table-a , table-b and table-c from project-Interface through migrate command in DB-B?
3. Can I add some more columns in table-x from project-Interface and use it?

Can I use the existing DB connection of DB-B from the env file of project-Web and use it in env file of Project-Interface?

If yes, will it create a new table in DB-B of project-Web, if I created it from project-Interface? Will the changes reflect there also? Also, if I created new columns in table-x from project-Interface, will that column be reflected in project-Web?

So the purpose here is that the DB should be the same and it should be common wherein it should contain all the tables in it and whatever changes I am making from project-Interface or project-Web it should use the DB-B.

Answer 1

Some answers:

1. It seems that you are asking if you can write to database B in project A. The short answer is yes, if you can connect to it then you can write to it. The database does not know that you are connecting from a different Laravel project or a project sitting in a different repo - it only understands database users.

2. You can also run migrations belonging to another project, but based on the information so far, I would advise against this. I will explain more below.

3. Adding columns to a different database sounds like a restatement of question 2, and my answer would be the same.

The problem you have with mixing migrations is that the second project (project-Web) is not able to create all its tables. This will add complexity to:

• creating a new development environment (eg when adding a new team member to the project)
• creating automated database tests that need to tear down and recreate the database from scratch for every run
• creating a new staging/production environment

Given that you want some communication between the two projects, I wonder if an HTTP API would be in order? This will be much easier to manage:

• All your tables are stored in one project, and all your logic is stored here too. This will simplify migrations enormously (and thus the creation of all environments I mentioned earlier).
• You can offer a web service in one project to offer read/write services to the other project. This is much easier to test from an automation standpoint: in the API project you can run API/HTTP tests, and in the client project, you can use mocks.
• This approach will allow you to test the projects in isolation in a clean manner, and then do automated integration testing if you wish (eg by deploying both projects to a test server using CI/CD, running the migrations and any seed files, and then running tests on one that causes both projects to work together in the designed fashion).