My answer is going to differ than everyone else. Tom Leek, and Xander provided good insight, so here goes my response to your initial question, expanding from this comment of yours:
"I don't want to store the salt in a database that could be
compromised - that defeats the purpose of salting, doesn't it?"
Yes, and no. If someone compromised your database, you have bigger things to worry about. The mere fact they got that far opens up the potential for sniffing on the wire, where if encryption is not used, data is visible before being encrypted and shoved into a database.
Salts protect because they add a layer to counter cracking. A cracker needs to hash a password AND a salt in order to produce something to compare to a known hash to find the right password. Most salting changes, otherwise if this occurred, salting would be useless:
User1 (password) [ kitten + your_static_salt = thundercat ]
User2 (password) [ kitten + your_static_salt = thundercat ]
In the above theatrics, two users have chosen the word "kitten" as their password which is salted to produce the outcome of "thundercat." If this held true, the salting portion is sort of useless. If you're using password_hash from PHP the salt is randomly generated for you, the outcome would be the following (of course minimized for clarity):
User1 (password) [ kitten + password_hash = thundercat ]
User2 (password) [ kitten + password_hash = uppercut ]
In the above, we see same password, PHP's password_hash changes the salt every time. No need to reinvent any wheels here as you'd need to do some deep dives into crypt() to understand it. If you're really that concerned with salting, and password security, have a look at Solar Designer's phpass, however when you state you're worried about someone compromising the db itself, this changes the scope of what an attacker could do without even needing to crack passwords to begin with.