Essentially you need to make sure that you Escape Output to protect the next recipient of that output.
If the next recipient is going to be a webpage, then htmlentities and that family of functions is the correct one to use.
If the next recipient is going to be your database then mysql_real_escape_string, or as mentioned, preferably using prepare/bind are the correct methods to use.
So, you might escape (prepare and protect) for your database and insert it, but then you have to remember to escape it correctly when you get it out of your database and display it on a webpage, or as xml, or csv, or pdf and so on.
Until I understood the FIEO concept (Filter Input, Escape Output) I recall that I was always trying to filter out everything upon receipt of data - and sometimes of course you can.
An example of this might be a phone number.
If your phone numbers should only ever be the numbers 0-9, between 8 and 10 numbers long, then, yes, you could quite easily sanitize and cleanse (Filter) that data before putting it in your database.
The problem is that further down the line you may not remember just how zealously you Filtered the text going into a field, so you should always Escape your Output to be on the safe side.
When it comes to a free-text input field you cannot hope to Filter out every bad thing that a malicious person could enter into a textarea box (take a look at the scary xss cheat sheet). Frankly if you have to strip_tags() on that input then something is amiss. If you have told users they cannot enter html tags and they do, then the mere presence of a < may well cause you to abort the operation.
If you have not told users they can enter html tags, then why unexpectedly strip it out?
HTH