|
3:29:58 PM |
|
Jon Tirsen hits the nail right on the head here!
Persistence is only complicated because we make it complicated. Somewhere back in time, it was drilled into our heads that we must use relational databases for persistence. For many applications this makes a lot of sense, but the complications it adds to every day development is just sometimes not worth the effort. Huge advances have been made in the Java world in O/R persistence tools such as JDO and Hibernate (.NET still has some catching up to do here) but using a relational database is just a major headache sometimes.
When designing an application using a bottom-up approach, the database schema seems like the starting point. What is my data-model? What tables will I need?
However, taking a top-down approach (such as that encouraged in many agile processes and test-driven development) often reveals something very different. I need my app to do something - what's my test? What's the implementation? Is the test passing yet? Now I need this to be persisted - what's my test? What's the simplest thing to do persist this object? Serialization? Test passes.
Taking this approach to persistence leads to applications that are no more complicated than if the whole app runs in memory. Once again, we can focus on what the requirements are, how we can test these and plain ol' objects (poos). Focus on what the app needs to do, not what the data model looks like.
I'm often caught raving about the needs for a superly spanking O/R persistence layer (I'm even involved in building one). If a rdbms must be used, then this is essential. However actually using an rdbms is something I'd only use when absolutely necessary (or when someone else has made the decision).
I'm not ruling out the need for relational databases - I'm just noting that there are many cases when they cause more harm than do good. Of all the applications I've been involved with I'd say less than 10% that used rdbms have really needed them.
|