Kind of don’t want to reinvent the wheel here as I’m sure someone has good ideas.
The issue : I have a database that the user will not ever need to update. But when new items appear, then I want to send the user an updated database.
However, I would like the user to be able to “favourite” individual items in the db and when an updated database comes, the favourites should still be favourites.
I’m guessing the best way to do this is to have a separate “favourites” database that uses the primary key from the main database and somehow joins them? But should the main db have a favourites field that is automatically updated by the external favourites db when it is downloaded? Or should it be kept separate?
Maybe the main database should have a “favourites” field and do the automated update when the new db comes in?
The key is that the new database not “erase” the user’s favourites when updating it.
yes two linked databases seems the best solution for me.
one that is fixed to the user, the other you send when there is an update.
Two different databases are really no nice way to do this. All the advantages like foreign keys, trigger, views, joins are not possible in this case.
Normally Updates to Databases are sent as SQL-Statements that are executed on the database while updating. Server-based databases couldn’t do anything else.
If that is not possible (because all data is changed), then you should use both databases while updating, so you can read all lines from the “old” favorites table and write it to the “new” one.
I don’t think his database has any foreign key nor any trigger …
otherwise he could use UUID and remote synchronisation but it’s far more complicated !
Ok, Jean-Yves, may be… But if I would have such a favorites-table I really, really, really would like to use joins 
Ok, ok, I would like to have foreign keys, too. I’m absolutely to lazy to tidy up my databases manually