I’m with “old_fart” here. If you think there’s a mismatch between OOP and RDB systems, you’re doing it wrong.
Here’s my approach, honed by 10 years’ experience and my comp sci degree (which was long enough ago that we studied network, hierarchial, and THEN relational databases in that order, since all were still currently in use by corporations – we learned C, then C++ because it was new and cool, and I didn’t pick up Java until I got out in the world).
FIRST, before you do anything else, get an entity-relationship model of your data. Learn how each piece of data relates to the others, so you can actually make a wise decision about what to do with it. The ER model should be an accurate model of reality; don’t pull any optimization stunts here, or you’ll regret it later!
NEXT, build your database. The database ALWAYS comes first, since it’s separate from your application and will exist long after your application has faded from memory. You must plan your database according to the assumption that other applications will use it, and that it will be extended to contain data about things you haven’t even thought of yet. And put your database in 3NF, so future developers’ suffering will be minimized.
Once you have an actual data model, print out your ER diagram and let your developers design their object model. Their object model should be based on your entities and relationships – object models are supposed to be based on reality, and your ER diagram is an expression of that reality. In other words, it should work like this:
Reality --> ER Model --> Object Model --> code
NOT the other way around. If developers recommend changes to the ER model, they should be made to justify them by showing how the ER model doesn’t accurately reflect reality. “coding convenience” isn’t an appropriate justification.
Finally, you build the actual software. You’ll probably use an incremental/iterative development model, and update the schema and object model as you proceed… That’s to be expected.
In the blog post, I’d be firmly in the “manual mapping” (#3) camp.
Note how this all works out. Because you’re basing your ER model, and then your object model, on REALITY, you’ll end up with a self-documenting system that is relatively intuitive to maintain. It’ll last a long time, too, because as long as the real-world entities you’ve modeled the whole system on continue to exist, the system will still be relevant. Changes in technology won’t ruin the system, because you’ve made the database the beating heart of it – you can always export and re-import your database structure to a new DB, and you can reuse your object model with a new language if something new comes along.
The whole idea here is, DO SOME ANALYSIS, and base your systems around an actual design, something that can be ported to new systems and extended over the years.
Of course, I’m an old fart too (38 years old!). And to me, the real problem is that “these damn kids today” don’t want to do any up-front analysis! They think that just because the waterfall model is a train wreck, they have a free pass to skip analysis entirely. Lazy little buggers and their PhP… THEY do cute little websites and they assume ALL development is about cute little websites.
Tsk, tsk, tsk… They just have NO IDEA…
Ah, well, glad to see I’m not the only old fart still around.