I have a user table that controls access to a website. We currently have a few hundred users and this might eventually grow to a few 10,000s. We have a requirement to allow in “temporary” users. These temporary users will have a token that times out, never to be used again. These tokens will likely outnumber the general users by a great degree. The question I have is whether these temporary users should be stored in the general table or in their own table.
My inclination is the same table as the userid is used elsewhere as foreign keys and is still useful for a temporary user. The uniqueness across the ids would be important. However, I’m not delighted that the user table will be filled with many records that never again need to be used and will thus slow down the table.
Another option I’ve considered is to create a user record, capture the id, delete the record and then use the id in another table. I therefore retain the uniqueness of the id but reduce the bloating of the table. I don’t mind if the foreign keys reference different tables.
Anyone had a similar issue and have any thoughts?
As long as you index the ID or have it as primary key the size of the table should not impact performance.
I would advise leaving the user record there to retain foreign key constraints if required – adding foreign keys will improve performance when retrieving data too as opposed to “soft” foreign keys.
IF it makes sense, you could separate users from temporary users.