There are a lot of questions about salts and best practices, however most of them simply answer very specific questions about them. I have several questions which feed into
Regarding #1, you can probably assume that if the users
table is compromised, they probably will also compromise the salt
table, even if you protected it better somehow. It would only slow them down a bit, like a speed bump would do.
Regarding #2, a hard coded salt value is often easily reverse-engineer-able via decompilation or runtime memory inspection, even with moderate amounts of code obfuscation. This would only help increase security in the case where your application is strictly hosted and nobody is able to get hold of your compiled application.
Regarding #3: What is the optimal length for a password hash? (SO link) - 16 is good!
Regarding #4, it isn't much more work to implement "more truly" random numbers, depending on the platform you're working with. For example, if you can tradeoff some performance to generate your seed/random number, you can probably breathe easier over how truly random your salt is.