Блог

Я создал отдельный каталог интеграции / project (назовем его project-Interface) в Laravel, и я создал новую базу данных (назовем ее DB-A) и 3 новые таблицы ( table-a , table-b , table-c ) с помощью artisan migrate command и моделей, связанных с этим, а также в решении.

Теперь в Laravel есть другой проект (назовем его project-Web), и у него есть своя собственная база данных (назовем ее DB-B) и созданы свои собственные таблицы и модели ( table-x , table-y , table-z ).

Мне нужно сделать следующее:

1. Могу ли я использовать DB-B table-x из project-Interface для сохранения в нем некоторых деталей?
2. Могу ли я создавать таблицы table-a table-b и table-c из project-Interface с помощью команды migrate в DB-B?
3. Могу ли я добавить еще несколько столбцов в table-x из project-Interface и использовать его?

Могу ли я использовать существующее подключение DB DB-B из env файла project-Web и использовать его в env файле Project-Interface?

Если да, создаст ли она новую таблицу в DB-B project-Web, если я создал ее из project-Interface? Отразятся ли изменения и там? Кроме того, если я создам новые столбцы в table-x из project-Interface, будет ли этот столбец отражен в project-Web?

Итак, цель здесь в том, чтобы база данных была одинаковой и должна быть общей, в которой она должна содержать все таблицы в ней, и какие бы изменения я ни вносил из project-Interface или project-Web, она должна использовать DB-B.

Некоторые ответы:

1. Кажется, вы спрашиваете, можете ли вы записать в базу данных B в проекте A. Короткий ответ — да, если вы можете подключиться к нему, тогда вы можете писать в него. База данных не знает, что вы подключаетесь из другого проекта Laravel или проекта, находящегося в другом репозитории — она понимает только пользователей базы данных.

2. Вы также можете запускать миграции, принадлежащие другому проекту, но, основываясь на имеющейся информации, я бы не советовал этого делать. Я объясню подробнее ниже.

3. Добавление столбцов в другую базу данных звучит как повторение вопроса 2, и мой ответ будет таким же.

Проблема, с которой вы сталкиваетесь при смешивании миграций, заключается в том, что второй проект (project-Web) не может создать все свои таблицы. Это усложнит:

• создание новой среды разработки (например, при добавлении нового члена команды в проект)
• создание автоматизированных тестов базы данных, которые необходимо удалять и воссоздавать базу данных с нуля при каждом запуске
• создание новой промежуточной / производственной среды

Учитывая, что вам нужна некоторая связь между двумя проектами, интересно, подойдет ли HTTP API? Это будет намного проще в управлении:

• Все ваши таблицы хранятся в одном проекте, и вся ваша логика также хранится здесь. Это значительно упростит миграцию (и, следовательно, создание всех сред, о которых я упоминал ранее).
• Вы можете предложить веб-сервис в одном проекте, чтобы предлагать услуги чтения / записи для другого проекта. Это намного проще протестировать с точки зрения автоматизации: в проекте API вы можете запускать тесты API / HTTP, а в клиентском проекте вы можете использовать mocks.
• Этот подход позволит вам тестировать проекты изолированно чистым способом, а затем выполнять автоматическое тестирование интеграции, если хотите (например, путем развертывания обоих проектов на тестовом сервере с использованием CI / CD, запуска миграций и любых исходных файлов, а затем запуска тестов на том, который заставляет оба проекта работатьвместе разработанным способом).