One of the ideas of the salt is that you would then get different hashes for two different records, even if they had the same password. Otherwise, if userA and userB both pick "password" as their password (yes, I know this isn't a realistic example: in a real production environment you'd expect many more than 2 users to have picked that particular password :suicide:) then userA somehow gets access to the password table, he could easily see that userB had the same password as it had the same hash.
The other idea of the salt is that it prevents dictionary attacks. If someone gets access to your hashed passwords, they probably will very easily be able to get a list of comonly used passwords hashed with md5, sha-1, etc. However, with a salt you need to have a dictionary generated for that site's salt. And then if you use a different salt per user, you need a dictionary per user on the site. It quickly becomes time-consuming* to brute force a password in this way.
The salt doesn't need to be kept secret, however. There's no security advantage to doing so, so it should be stored alongside the hashed passwords in the database.
* think will-take-longer-than-the-heat-death-of-the-universe style time consuming
