IndexedDB - ObjectStores versus multiple databases and indexes?

Question

I was wondering when it would be nice to have one database and one database with multiple object stores. I read most of the manuals online and also looked at the specification for indexedDB, but could not find a good example comparing these different concepts. Does anyone have a specific example (a design model using multiple object stores and / or code) for this kind of thing?

Answer 1

As long as there is no cross-transactional manipulation between object stores, you can split them into several databases. I prefer to use a separate database as much as possible so that schema changes are easier in the database of the storage of smaller objects.

In a rare situation, I even use a separate database, even if a cross-transaction is required. These cases are found between the user settings database and the application database. The inconsistency between the user settings and the application is beautiful, since the truth in the user settings and the temporary inconsistency does not matter.

Please note that there is a high cost associated with opening a database. But as soon as it is open, there will be no memory to connect. The number of databases is not limited.

Multiple databases will have better performance than a single database with multiple object stores, because the Firefox implementation locks the entire database with any write transaction.