I'd actually argue the best approach is to develop both sides fully: I agree that an OO data model is the best fit for non-trivial application logic, but I also believe relational databases make the best data stores. The two can coexist just fine, it's just a matter of selecting the proper design patterns and supporting libraries -- which is why I mentioned SQLAlchemy. In its developer's words:
"SQL databases behave less like object collections the more size and performance start to matter; object collections behave less like tables and rows the more abstraction starts to matter."
This false dichotomy that's always presented is distracting, and leads to people naively taking religious positions about what should in fact be a non-issue.
"SQL databases behave less like object collections the more size and performance start to matter; object collections behave less like tables and rows the more abstraction starts to matter."
This false dichotomy that's always presented is distracting, and leads to people naively taking religious positions about what should in fact be a non-issue.