Generally speaking, a database NULL should be thought of as "This Is Unknown". In the case of something like a Date of Birth, or a Height In Centimeters column, it makes perfect sense to store a NULL there if the value is not known.
Getting to the meat of your question: strings. Say you have a Former Name column. This would be used to track a person's pre-marriage surname, for married people who take their partner's surname. Storing a NULL there should still mean "This Is Unknown". What about someone who is not married, or is married but didn't change their surname? Well, that is a KNOWN value, so it's NOT appropriate to use NULL there. That could be a good use of an empty string, but a more correct choice might be to just store their surname in that column as well.
In most relational databases, NULL has many special properties that make it unsuitable for general use. Generally speaking, any expression will return NULL if any of its operands is NULL. 1 + NULL = NULL. 'Some String' + NULL = NULL. NULL = NULL = NULL. One key exception is the IS NULL operator, which returns TRUE if its operand is NULL, FALSE otherwise. This "NULL poisoning" can easily cascade when you write complex expressions using many columns where the values can be NULL. This means that when writing expressions, you MUST be keenly aware of where NULL will pop up and take that into account.
It's best for everyone involved to always treat NULL as "unknown" rather than "empty", particularly for complex data types. When designing a relation, don't make a column nullable without good reason, and when working with a relation, always check each column for nullability and take that into account.
Someone else's response spells out the insanity of Oracle Database, which treats NULL as equivalent to the empty string. Avoid Oracle if at all possible, because that's just one of many insane things Oracle does and will never change.