An attacker is "allowed" to know the salt - your security must be designed in a way that even with the knowledge of the salt it is still secure.
What does the salt do ?
Salt aids in defending against brute-force attacks using pre-computed "rainbow-tables".
Salt makes brute-force much more expensive (in time/memory terms) for the attacker.
Calculating such a table is expensive and usually only done when it can be used for more than one attack/password.
IF you use the same salt for all password an attacker could pre-compute such a table and then brute-force your passwords into cleartext...
As long as you generate a new (best cryptogrpahically strong) random salt for every password you want to store the hash of there is no problem.
Depending on how you use MD5 it is a weakness since MD5 is no longer seen as "cryptogtaphically secure"
IF you want to strengthen the security further
You could calculate the hash several times over (hash the hash etc.) - this doesn't cost you much but it makes a brute-force attack / calculating "rainbow-tables" even more expensive... please don't invent yourself - there are proven standard methods to do so, see for example http://en.wikipedia.org/wiki/PBKDF2 and http://www.itnewb.com/tutorial/Encrypting-Passwords-with-PHP-for-Storage-Using-the-RSA-PBKDF2-Standard and http://msdn.microsoft.com/en-us/library/system.security.cryptography.rfc2898derivebytes.aspx
Using such a mechanism is these days mandatory since "CPU/GPU time" (usable for attacks like rainbow tables/brute force etc.) is getting more and more widely available (see for example the fact that Amazon's Cloud service is among the top 50 of fastest supercomuters worldwide and can be used by anyone for a comparatively small amount)!
Splitting the salt into 2 pieces, one hardcoded/constant and one unique part is NOT recommended!
Depending on the algorithm used this can be a weakness helping an attacker to break your security. I would highly recommend NOT doing this unless you can prove mathematically that it does not weaken your security (which is very hard to do IMHO).
There is NO problem at all for an attacker to know your complete salt if you implement the security correctly...
UPDATE (as per comment):
RFC 2898 is an important reference on PBKDF2. In section 4.1 it talks about adding a part to the salt
the salt should contain data that explicitly distinguishes between
different operations and different key lengths
This has IMHO no relation to what the OP is asking. The RFC talks about information on key lengths etc. being incorporated as an additional part along with the random salt. This is very similar to having a file format containing a header section describing specific aspects of the data it contains. This does not weaken security and is possibly very usefel in a scenario where interoperability between different systems is needed.
In contrast what the OP is asking is basically storing only a part of the salt in the DB while keeping the other (smaller) part hardcoded in the application which means that the salt in the DB is not complete... doing this means losing entropy of the salt (i.e. a 64-bit salt with 8 bits being constant is actually only as secure as a 56-bit salt) which in turn leads to weakening the security the salt provides (at least for any algorithm I can think off right now)... this contradicts what the OP intends (increasing security).
UPDATE 2 (as per discussion with owlstead):
You can add some "secret" (which can be hardcoded in your application) to the plaintext BEFORE hashing with PBKDF2 using a unique and random salt which is completely stored in the DB... that could help a bit although it accounts for security by obscurity IMO.
