Migration strategy for shared database between multiple apps?

I think the elegant solution would be to not share the database. The ideal solution would be to have one back-end application that handles all the storage and business logic. The back-end app can then offer the data to the other apps through web services.

At the moment you are struggling with the migrations, but when the app grows bigger you might experience other problems. What if you want to create a task that cleans old records from your database. What app are you going to use for that?

Or what if you are going to change the structure of the table. You would have to update all your apps. But if you have only 1 app that interacts directly with the database you only have to change that app and run the migration on that app. All other apps can just keep using the webservice (API) the back-end is providing.

I understand this might not be the most helpfull answer if you have to share the database because of legacy reasons...

I have to share the database because the clients share content. This is required for the business. Trying to sync an item across 20+ databases would be an even bigger nightmare. Currently I'm sharing the database and using a client field to signify tenant ownership in the tables. Each app has their own database as well, but I have a 2nd connection setup to get the info from the central database.

I'd love to separate each app entirely but the business rules seem to dictate otherwise. There are other benefits from the shared database setup too -- such as admin user portability across all the apps (the users table is stored in this central db too).

Seems like my situation is fairly unique? I certainly don't want to keep the migrations for this central db in each client app, but the database needs to be there for the client apps to work... so housing the migrations elsewhere would make it much less portable from a developer's perspective.

@austenc: You say "Currently I'm sharing the database and using a client field to signify tenant ownership in the tables. Each app has their own database as well". I am hitting my head with the problem of having common tables across multiple database and migrating to them. maybe you have already done this

i.e. two servers on forge. server 1 has db with table A and table B. server 2 has table A and table C. how do you migrate table C with artisan so that table C is only added to the second servers database. If you have run into this please advise thx.

By the way maybe bit naive can't you use single single app with multiple flavors instead of multiple apps

I think there's a little misunderstanding. Creating 20 databases and distributing the content is a bad idea. You are totally right about that.

However, distributing all your business logic is also a bad idea. If your table "foo" and its class "Foo" is shared between 20 apps. Are you going to put a "Foo" class in every app? That will give you a hard time maintaining all the apps.

What I ment was that you could extract all stuff that is shared between the apps into a single back-end app. That way you won't have to maintenance the domain logic between 20 apps.

All apps that need to use the shared logic can just make an API call to the back-end app and the data is in a single database and thus easy to maintain.

@vm I posted a link in your other thread that might help you. Unfortunately, a single app with multiple flavors doesn't work, as client business logic is often so different that I need to change model functions, views AND controllers to support what they need.

@TimVanDijck -- I think that seems the most sensible solution. Currently I'm 'abusing' the notion of a composer package to help with the replication issue. Each client app can install this (private) package to use as a foundation for the differences / specifics for each client. I've gotten all this setup, but now feel like it was worthless to do it this way since I'm still going to run into problems like this one. Thanks for your replies.