Had a very interesting conversation today with Tim where he recounted a disussion he had with Joe about persistence.

The gist of their discussion as I understood it was:

-Why do we use databases?
-To store data.
-No, why do we really use databases?
-To produce reports.
-Yes.

Its a very attractive idea. Much of the complexity (ie. Object-Relational mismatch) of enterprise applications stems from a need to run reports on the data. But are we as an industry guilty of confusing our need to have durable data with our need to run reports on that data?

Getting Agile for a moment, what if we assumed we don’t need a DB (as opposed to most projects, which pretty much from day 1 assume they do need one). What if we also assumed that persistence was easy, which is essentially what projects like Prevayler have already demonstrated.

Dipping briefly into history, Smalltalk essentially did have free persistence, almost 10 years ago. Smalltalk is image-based, where your classes and objects (and the runtime classes and objects) are all part of the ‘image’, which could be saved and retrieved at will. Products like Gemstone supplied the robustness and high-availability needed by enterprise applications.

Back to the story. Assuming that we had no database, and that our objects were all durable (meaning they outlived instances of the JVM), how would that affect the development of the application? For a start some method of reaching all our objects would be required, so the object graph would need to be navigable from some root starting point. Nothing a map or list couldn’t solve.

Serialization is one obvious means to achieve object durability, and is really all Prevayler does under the hype. This does have the drawback of breaking if you add or remove fields from classes, but there are ways to solve it. Simplest solution is probably to extract the class into an interface, and provide a mechanism for migrating the implementations as they are deserialized. Compared with the effort of changing a database schema once in production you are still winning big time.

Allowing ourselves to wear the Pragmatic hat instead of the Agile one for a moment, we’d probably realise that persistence isn’t totally free, and that some means of ensuring object consistency would be needed, so that things that needed to happen together or not at all could be handled, but that is complexity that can be delegated behind a facade and doesn’t need to clutter the plain old object model. ‘Runnable’ looks like a reasonable starting point template for how to encapsulate a single transaction.

Of course, sooner or later a requirement for reports will be raised. Now we need a database. So we need to migrate all our objects into it and throw away our nice simple persistence in favour of a complex O-R layer right? No! We just put into the database the data needed for the report. Job done.

There are whole areas of thought yet to be considered, such as updates, ad-hoc reporting, distribution, messaging etc. but I really do like the idea of making the database just another facet of the system, rather than the crushing behemoth it seems to turn into on many projects.