The salt (as in "a set of random bytes") is
appended or prepended mixed into the password and the result is then hashed. Hashing is a one way function. Rainbow tables are hash-realpassword pairs and can be very fast in telling you the password given the hashed-password (as fast as a perl-hashtable=dictionary lookup-by-key, which is, in theory, O(1)). So, if your hashed-password contains a random set of values intermixed with the real password, then the given rainbow does not work anymore! Or at least you will need a different rainbow table for each possible salt (for example, 60^10 for a 60-characters-range, 10-byte-long salts). For these reasons, salts can be stored in your hacked db alongside the password and even in plain text. The cost for the hacker will be enormous. But of course not impossible.
there are a few points that need to be clarified, which I don't know. 1) Should the character set of the salt be the same as the password or what it should be, should it match the statistical distribution of the password? I guess it does not matter, but I am not an expert. 2) Is it really paranoid to store salts in a different db, even in a different host? 3) how about hashing them? I think that would work if salt length is random and character-range in 0-255, so as hacker not to be able to know if unhashing of salt succeeded.
What I am sure about is to never use the built-in RNG for encryption ops! It is looking for trouble big time. Use one of the so-called "cryptographically secure RNG".