Should I create a separate database table for temporary users 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?
Why don't you just store it in the main user table (keeping a unique ID will be a nightmare otherwise), and have an ACTIVE bit field that you include in your indexes (you can filter if you like).

It won't really slow down access to the table since your indexes will be able to very quickly sort by active/inactive but you also avoid the headaches caused by trying to "roll your own" identity field.