Is having multiple SQL db's a bad idea for a single application?

Question

I'm designing an iOS application and have decided to separate the persistence requirements into three separate SQL databases.

• Static Data - read-only but downloaded from external sources
• Client Request Data - data that the client is queuing to send to an external source
• Application Meta Data - Holds meta information about the state of the other two db's and the application as a whole. This might be but not limited to table/app version information, time the app last communicated with an external source.

The idea behind this separation is that the first DB is effectively replaceable, the second is a transactional source while the meta information should not grow.

Are there any caveats to this approach, of course I understand I can not join across each, though I don't intend to.

Answer 1

I'm not familiar with iOS, but I'd consider it from a space standpoint. What's the minimum size of an SQL DB vs. the size of the data you're going to store in it? If the DB doesn't add a significant amount of overhead, then it should be fine. But if you're going to be storing 1K of data and an empty database is 16K, I'd reconsider.

Answer 2

Before using two databases, I would think about having one or two JSON files. It may be ok for your Static Data, and will probably be enough for metadatas.

Obviously, it depends on the quantity and organization of your datas, and if you do or not crossed CRUD operations.

Answer 3

Certainly not anything inherently "bad" about this approach. In fact, it's often a good idea and in your case sounds like it probably is. You can possibly get performance gains depending on how you create and open the various databases as well.

A couple specific pointers:

• Static Data: Since this database is read-only, open it as read-only
• You can can actually join across databases like: Use the ATTACH DATABASE SQL statement and go from there.