I responded to a question on Stack Exchange
The purpose of a per record salt is to make the task of reversing the hashes much harder. So if a password database is exposed he effort required to break the passwords is increased. So assuming that the attacker knows exactly how you perform the hash, rather than constructing a single rainbow table for the entire database they need to do this for every entry in the database.
There is a separate issue with a database wide salt. This is a sort of key, and protects against the attacker using existing rainbow tables to crack the passwords. The database wide salt should be stored separately so that if the database is compromised then it is unlikely that the attacker will get this value as well.
The last area where many fail, is that there must be a way to change these salt values. If a security incident occurs we want to be able to change the salt values easily. So the database should have a salt version and the code will use the version to identify which salts to use and in what combination. When this is changed then a background task can update the database without taking the system off-line.