Level 80
@onairmarc That sounds awful, inefficient, and a decision that is going to bite you sooner rather than later.
Dec 3, 2023
7
Level 5
Migrations Across Multiple Databases
I'm working on a Laravel App that is exploring using multiple databases for different modules rather than having everything in the same database. From the Laravel Documentation, I see that I can specify the database connection that a particular migration should run on. if my databases are DB_CORE and DB_EXT, I know that migrations run on DB_CORE are stored in DB_CORE.migrations since it's the default connection. However, where are the migrations stored for DB_EXT? DB_CORE.migrations or DB_EXT.migrations?
Level 5
@martinbean From a 10,000-foot view, I'm inclined to agree with you. However, these modules are more like fully featured applications inside of a larger application suite. They're all in the same project/master application since there are common features and functionalities between them. Picture being able to use any of the modules as an independent application, but the other applications in the suite are also present but may not necessarily be in use.
I'd be using the InterNACHI/Modular package to manage this.
I'm open to other alternatives, but I really like what the InterNACHI/Modular package does.
Level 80
these modules are more like fully featured applications inside of a larger application suite
@onairmarc If they truly were independent applications, then they’d be separate applications. But the fact they live in the same codebase suggests they aren’t as decoupled as you think they are. And I can guarantee once you’ve split your database across multiple databases, they’ll be a day where you need to match data in two tables in two databases, and you’re going to be in a whole world of hurt when you do. Users will be the main culprit.
Level 80
When building a framework or an app using a framework, the whole framework is built by keeping it modular where each module is actually a separate app, right or am I wrong?
@wew I fail to see what point you’re trying to make here? Is Laravel “modular”? Yes, it has various components. Do those components each have their own database? No. Those components also aren’t the separate black boxes you’re insinuating they are; there are many instances where some components know and interact with other components.
Level 73
I agree with @martinbean on this one, it truly sounds awful. A single database can handle a shitload of data, so that isn't really a reason to to something like this. There are things that you can do inside the database that makes it faster if you have performance issues, things like indexes, partitions, federated tables, and what not. Splitting it up makes little to no sense to me, at least not until you run into any issues, and the ones you do run into can probably be solved within the existing database, and that is what you should do, before adding multiple ones to your application.
1 like
Please or to participate in this conversation.