A lot of this does depend on the tech and solution, but I have used several tools that definitely do not think that way.
If you are doing web using something with an event model, some concept of a request/response lifecycle you can very easily do all your logging by hooking the exception event and hooking the response completed event then just maintaining a collection of loggable things through the lifecycle.
If you are doing a desktop app things get a little more varied. There usually are still some common events to hook, but other times you need to probably call out to the logger explicitly because saving everything to the end of the lifecycle would get messy quickly.
In .Net you can solve a lot of this by doing some implementing a custom trace listener, that way you can use the default trace reference, but still get data that doesn't look terrible when reviewing.
As for logging in a separate db or not, it depends on a lot of things like if the log has to be a valid audit source, and who has access to the data, and if you are trying to log issues connecting to databases :-)
If I need to search the log efficiently I do not store the messages as big blobs, but sometimes I do create the messages as a blob and split them up into the final format in a separate process. What you do to get the message in the first place will depend entirely on what you are doing. I have some apps where the overhead of serializing the objects is simply too much for ongoing logging not to have a perf impact, let alone the fact I would run out of storage in a few hours. Most of those I just log id strings. Other apps have objects I would like to log as serialized objects, but the object isn't serializable, for those you can use a custom formatter, or an intermediate. Other times I have the luxury of low throughput and serializable objects so I just use the default serializers.
One bit of advice, if you are really going to make the logging endlessly extensible mace certain you have a way to limit/throttle it