Zen slapped!

It wasn't a moment of clarity or anything else, it was a moment when what made sense no longer did. I have the same problem with words - for a couple of years, "will" just didn't look right to me; I had this nagging feeling that I'd spelled it wrong when I hadn't.
And in a roundabout way, having read a meta-post on what Steve Yegge has to say today about objects or something (my attention span's too short to find out), suddenly the canon of "objects for your business logic, databases for your data" seems to have been proffered by a madman.
At first I was trying to figure out exactly what encapsulation is being broken - as long as objects are responsible for their own persistence (when asked nicely) and retrieval (when supplied a morsel of information), where is the disjoint, right?
But wait a second. What's the "real" object here? We've got business objects and they can be composites of other business objects. But we don't have much to do with our business objects without instantiating them and without eventually persisting them somewhere... at which point, we've got another instance of an object, only now in relational form.
That relational "object" can itself be a composite of sundry other "objects" (tables), unless you're the sort that just tacks another varchar(8000) column on your God Table and calls it a day (and I promise to make fangless threats to beat you to death with Codd's corpse if I ever have to support such a mythical beast).
And tying these two disparate, equally valid (depending on who you ask and when), objects together is what amounts to a domain-specific language (SQL) so that you can get these two different domain objects talking to one another.
This feels unnatural to me and I'm not left wondering why things don't work but rather in awe of the fact that they work in spite of being tied together with duct tape and zip ties.
Thankfully, Giles Bowkett came along and dropped a pithy

oodbs ftw

in the mix and I was slapped back into... coherence?
I've never bought into object-oriented databases because I've never taken the time to wrap my head around them (chicken and egg, that). I understand relational databases - I've long since internalized normal forms and I understand how they help me to enforce data integrity and are generally pretty performant (disk size, memory, speed) ways to persist data.
Even if you take size/memory/speed out of the equation, there's a little matter of people making mistakes - I've yet to come up with an object design that worked out of the gate. When I bone it (and I just about always do), it means tacking on more columns, more tables. The stored procedure interface then (probably) changes and the upstream object (and their calling objects) which is all kind of ungainly, but all the "legacy" data is still there for the taking. When you refactor an OODB, what happens? I mean, it was persisting an old version of your object, right? Is this something you have to take into account manually somehow (I imagine so)? I'm scared.
Model/view/controller, I'm sorry I doubted you honey. But you have to admit, you are kind of freakish when you take a step back and think about it.