问题
I'm designing a table that stores information about Disciplines - it allows a user to add records but I also need to be able to add records myself (which will appear to the user on an update).
The problem of course is the auto-incrementing ID - if I launch the app with 9 listed and add a 10th discipline in an update, on my side it'll appear with the ID of 10, but they may have already created 20. It's obvious, basic stuff but if I instead split the data into seperate tables with the same schema, I have the problem of a further table (which lists subjects) needing a single list of PKs for it's Discpline FK.
So they can't be two seperate lists of auto-incrementing IDs because the FK can't have duplicate values but they also can't be the same column to avoid duplicate IDs. The only thing i've thought of is keeping the data in one table, removing the auto-increment at the database level and in the app's code, starting a auto-increment (+1 to last number) at a specific number I know I won't come close to for the user's added records. But this seems dirty and inefficient and I know there's an easier method at the database level I'm just not thinking of.
Thanks for any help, Paul
Edit: I can see that i'm not being clear enough, so apologies for any confusion. I currently have two tables, however this will apply to future tables as well.
- tbl_disciplines (disciplines_id, disciplines_name)
- tbl_subjects (subjects_id, subjects_name, subjects_fk_disciplines)
I understand tbl_disciplines can have entries from both myself and a user however I was hoping to have them as two seperate tables due to my understanding of SQLite and the knowledge that I'll be adding more tables, many with dozens of fields and FKs. I don't want to manually write out each new record in onUpgrade when future tables could require 100+ new records to be added on an update. The app that'll be using the database, is designed to make adding to the database a more efficient, simplier process.
If they're seperate tables, I know with onUpgrade, I can simply drop and replace the older table of my records on the user side with a new table of all records i've added using the app since the last update, leaving a second table of user records untouched. From what I understand, if I keep mine and the user's records in the same table, I would need to manually add all of my updates record by record to the same existing table in onUpgrade area so I don't erase their data. Further meaning, I can't use the app as a front-end for adding my own records because I can't just replace their tbl_disciplines with my tbl_disciplines on an update.
Additionally, if I need to edit something about one of the records i've added, I cannot query the record by it's ID as it'll be different for every user.
回答1:
It's not clear to me what you think the problem is.
If you use an auto-increment field defined in the table, no two records will be added with the same ID. They will be guaranteed unique on each INSERT. You do not specify the value in the INSERT statement, you let SQLite decide the value for you and read it back after the INSERT statement executes.
In the example you cited, if users have already added enough records so that the internal "counter" has reached 20, your new record will be assigned 21 for the auto-increment column and the next record added by a user will be 22. As long as you leave it up to the database this is guaranteed. There are no race conditions to worry about.
来源：https://stackoverflow.com/questions/60154659/sqlite-two-pk-one-fk