Question

In my database I have tables that will grow at different speeds:

• fairly static ones that I dont expect to grow much at all,
• medium-grade ones that will grow somewhat linearly with number of users and their activity
• fast-growing ones that will grow rapidly as they hold logged data points

I have been fretting a little bit about maintaining this database as it is growing. It is a balancing scenario:

• A single database is easier to work with but it may have higher maintenance costs in the future
• Multiple databases can be easier to maintain once the application is deployed, but will require more R&D time

Can you recommend one or the other solution based on your past experience?

Thanks,

Answer 1

I think that how fast the data grows is irrelevant. I think that it makes more sense to have databases split up based on something mapped to a real-world reason.

For example, Typically, we have one database per app that we write. We have a database for a Nutrition and Ingredients database, another one for Job Listings, etc. We do this because it’s easier for us to keep track of which database affects which apps. (To avoid confusion in other words.)

But we do have one Common database that holds information that’s used in multiple applications. (Such as corporate info, locations, etc) so that we can avoid data de-duplication. (Why maintain a list of locations in each database).

I’m not saying this is how you should structure your data, but I listed this as an example of a good reason to have data split across multiple databases.

Other than having different maintenance plans for databases with varying growth, I can’t see any reason to split based on database activity.

Splitting them behind a load balancer is the same either way.. Maintianing them once they’re deployed should be done in a controlled, pre-tested manner regardless of how fast the tables grow…

Unless I’m missing something, I don’t see a good reason for it, but I don’t see a good reason not to do it, either. If it makes sense for you, and simplifues your business process without adding confusion or other problems, then it makes sense in your situation, and I see no harm in it at all.