Home/ Questions/Q 7552981
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-30T10:55:29+00:00

I’m designing an iOS application and have decided to separate the persistence requirements into

  • 0

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.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    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.
    • 0