No it isn't a good way of salting and it isn't the standard way either. There is no reason or benefit to store the salt before it is used. The point of salt is just to prevent parallel and precomputation attacks. Storing it ahead of time means in an undetected compromise the attacker would learn of 'future salts' which undermine the precomputation resistance.
After the salt is generated and used to hash the password it can simply be stored in the database right next to the hashed password. There is no reason to come up with more complicated schemes.
So as an example let's say Bob signs up at your website. He provides a username of 'bob' and a password of 'passw0rd'. Your login/signup code generates a random 64 bit salt of 'ed7d9075fe3d31e7'. You should be using a KDF like PBDKF2 instead of a simple hash to securely hash passwords. For this simple example lets assume it is just a single hash like SHA-256. Instead of hashing just the password you hash the password concatenated with the salt. Let's imagine the resulting hash is '58e901b....'
You would store in the user table of your database a record with
username = bob, hashedpassword = 0x58e901b..., salt = ed7d9075fe3d31e7.
When someone attempts to login with username of 'bob' and password of 'pass' you would lookup the username 'bob' to read the salt and hashed password from the database. You take the password from the attempted login ('pass') and concatenate it with the salt from the database to produce a hash exactly like you did on signup. You don't know what bob's correct password but you do know it should produce the hash stored in the database. In this case the password is wrong so it will produce a different password and can provide an error.