Yes, you can store it in a single field, and many databases/applications store the salt+hash in a single field/file etc.
The most famous is Linux (which isn't a DB), that stores the hash in the /etc/shadow file using the format:
"$id$salt$hashed", the printable form of a password hash as produced
by crypt (C), where "$id" is the algorithm used. (On GNU/Linux, "$1$"
stands for MD5, "$2a$" is Blowfish, "$2y$" is Blowfish (correct
handling of 8-bit chars), "$5$" is SHA-256 and "$6$" is SHA-512,
other Unix may have different values, like NetBSD.
The salt is not meant to be secret (or at least not more secret than the hash). Its primary purpose to make brute-forcing attacks much much harder since the attacker has to use a different salt for each individual user.
But your question is more nuanced -- because you're not just asking about salts but parameters as well. Things like the hashing algorithm, iteration count, and salt. In any case, don't store this in code, they still belong in the DB.
Imagine you've got a bunch of users, and you've used SHA1 as your hashing algorithm. So your database field would be something like SHA1:SALT:HASH.
If you wanted to upgrade your Database to BCRYPT, how would you do this?
Typically you'd deploy some code so that when a user logs on, you verify the password, and if valid -- you'd re-hash the password with a newer algorithm. Now the field for the user looks like this: BCRYPT:SALT:HASH.
But then some users would be on SHA1, and others on BCRYPT, and since this is at a user level, you need the parameters that tell your code which users are which to be in the Database.
In short, storing the parameters and hash in a single field is OK, but splitting them out for whatever reason (efficiency, easier code etc) is also OK. What's not OK is storing this in your code :)
Troy Hunt recently published a podcast suggesting that instead of migrating to BCRYPT in the manner above, it's more effective to simply take all the SHA1 hashes currently in the DB, and hash them using BCRYPT.
When a user logs on you'd
BCRYPT(SHA1(clear_password)) == <db_field>
This way, everybody on the platform gets upgraded at once, and you don't have a database with multiple hash formats for passwords. Very clean and very nice.
I think this idea makes perfect sense, but even though everyone migrates at once, it's not instantaneous. Unless you're willing you accept some downtime on the app (while you re-hash all the passwords), there will still be a small gap of time where some users are on BCRYPT and some on SHA1, hence your DB should still store the parameters of the hashing algorithm, and your code would execute based on it.