While best practice for password storage dictates that they should be stored in a hashed format with a unique salt, the original question actually raises a reasonably good point: if you store the salt in a different location to the hashes, the impact of those hashes being disclosed is lowered.
1) If the passwords were only hashed, and stored in a database, and the site suffered from SQL Injection then an attacker could "crack" the hashes
2) If the passwords were hashed with a salt, and the both hash and salt were in the database, and the site had SQL Injection then an attacker could "crack" the hashes, but would require more computational effort (as there is no performance boost from pre-computed tables)
3) If the passwords were hashes with a salt, and the salt was stored elsewhere, then SQL Injection would afford an attacker little leverage to ascertain the actual password.
Scenario 1 is obviously weakest, but the difference in security between 2 and 3 is less clear-cut, and depends on the relative probabilities of SQL Injection vs server-side code disclosure (and associated classes of vulnerability).
What do you trust more - your ability to protect against SQL Injection, or the ability of Apache/PHP/Whatever to protect your server-side content.
Things are never simple and I actually think the idea in the OP makes more sense than other answers give credit for.
(You could use both, a salt stored in database and a "key" if you like stored in the web app source, when generating passwords).