Can you give an example of what you meant? I understand variable length and random characters for each different accounts? (Sorry, I'm not a native English speaker).
Start with the assumption that the "bad guys" will have access to your entire database, and source code. From there, how do you protect the security of your users' passwords?
As computers get faster in every aspect the ability to crack naively implemented hashes grows greatly, to the point where, as we've seen, 14 character random passwords protected by a one way hash can be cracked in very little time.
Using a static salt across all accounts saves you a little, because it means that in order to crack those hashed passwords it will be necessary to re-do all the pre-computed hashes. That takes a lot of time and resources, but once done every vulnerable password (which today means any password less than 14 characters, no matter how secure) can be cracked.
By using a good per-account salt it then requires a brute force attack for every account. Which makes any requirements you've instated on minimum password "strength" all the more effective.
If, however, you use too short of a salt, or a silly "salt" such as phone number or userid or first name or some such then your salt becomes much less worthwhile. As pre-computed rainbow tables grow, as hardware gets faster eventually you get to the point where you can crack passwords along with naive salts quite readily. Phone number + 8 character password is just 18 characters, it's really only a matter of time before rainbow tables are capable of cracking 18 characters directly, and then using phone numbers as a "salt" is meaningless, because attackers can crack the password+salt directly.
What's better is to use a very long and random salt for each and every password (random length doesn't help that much). In this way any pre-computed hashes are worthless, because it's extraordinarily unlikely that any significant subset of all of the possible salt + password combinations have been covered.