Seems the database would have two columns. One for Salt and one for HashedPassword. Then, you have your application do the hashing with the RANDOM salt. You store both in the database.

Reverse engineering a HashedPassword is difficult unless you already have several commonly used password that are in a table and you compare it with the HashedPassword column. This will then give you a list of users that contain the same hash values as your precompiled table. This does not mean the user had the same password but does mean your password will hash to the same value and let you sign in. One hashed value can usually be achieved by many different clear-text passwords.

So, to prevent these "dictionary attacks," use a salt value which changes the final hash value for the stored password. Processing these through a dictionary table is useless because all users have a different salt value. You would have to have a pre-compiled dictionary table for each user in the database which gets much more difficult to process. The chances of you getting a match this way is statistically 0% unless you have several years to brute force it. Generally companies require you to change your passwords every 30, 60, or 90 days so a brute force doesn't work in these cases either.

Sending the clear text from the application to the database is dangerous because the trace command can pick that up and be captured by anyone with full access to the database. Having it hashed in the application makes it so only the salt and hashedpassword values are sent to the database and they are no longer clear text at that point. You can look in the table or do whatever trace command you want and you will not be able to see the user's original password anywhere in the database.

The only method for acquiring these passwords is if you use a network sniffer that captures the packets from the client's computer to the web server. And, this is only easy if you're not using an https server and still on a simple unencrypted http server.