No problem at all. The "salt" function is to avoid collisions of equal passwords or hashes that are the same. Your job is not to establish a secret, it's just to avoid discovering a password by coincidence.
As shown in the linked question and others on the subject it is important that it be random and sufficient to avoid duplicity of interpretation.
The strength of the hash should be sufficient for the case of compromising the password database, do not give this responsibility to salt .
Strength is something general, it is the difficulty of breaking it. For example, there is a new one that is safer than existing ones when that question was answered: link . If there is an attack, salt does not influence anything, so you do not need to protect it, it is used to combat other types of attacks, not to prevent an attacked server from stealing passwords, in this case the hash should be the best possible, that's what's in the answer.
If you do not put it there, it will put you where? In another table? It does not matter for safety. In another database? It does not change anything. On another server? It helps only a little, but it creates a complication for the software.