Over a million developers have joined DZone.
Platinum Partner

The Relational Belt and Suspenders

· Java Zone

The Java Zone is brought to you in partnership with ZeroTurnaround. Discover how you can skip the build and redeploy process by using JRebel by ZeroTurnaround.

The most common approach to doing Java is with an ORM connecting to a relational database. So who is responsible for data integrity in this scenario? The database has a constraint language. I have almost NEVER seen anyone who used it even slightly, let alone completely. For instance, if you define a column called age in your person table, do you have a check constraint that the value is not negative? No, of course you don‘t. Hibernate and JPA have facilities for validating data. Aren‘t all engineers trained to believe in the singularity of responsibility? My favorite OO author, Bertrand Meyer devotes a considerable amount of ink to this question (in his 1990 book Object Oriented Software Construction and concludes that the idea of enforcing integrity in an application at the database is madness. Mainly, because the prospect of collecting the data, then sending it down through the layers, getting the word on whether it made muster or not, then back propagating the information, is ludicrous.

Of course, I agree with him.

So don‘t we have a case of a belt and suspenders, but even worse: a situation where because we think we have integrity in both places, we aren‘t really using either sufficiently? We still don‘t have serious validators in the Java world. JSF is approaching a decade in age now. Until JSF 2, which only came out a year or so ago, you couldn‘t even perform validation on multiple fields (something as simple as does this password match the confirmation!!). For all the mania about annotations, we don‘t really have a solid set of validation annotations. And frankly, isn‘t it kind of stupid to start putting things like the length of a field in the db into the class file? Shouldn‘t annotations have made it easy to finally add pre and post conditions (and class invariants)? [Read: yes, hence their absence says no one cares.]

And yet..

The SQL guys are clearly starting to get unnerved by the advance of NOSQL. One of the things you hear is that name/value pairs are kiddie park and that‘s all graph dbs do. But in fact, there‘s something kind of refreshing about dealing with this (the first NOSQL extended piece I have been doing is really ideal for this technology). Refreshing because, in addition to avoiding the false security, the glad-handing ‘check the box‘ of typesafe + relational (normalized of course), we also don‘t incur the penalty: because you are having to be pinned down by the typed schema, you can‘t do discovery, you can‘t mix collections that don‘t have the exact same set of attributes (worse, same sizes/types on each attribute). With a graph db, you can just say ‘ok, here I am up in the app and I am going to have to assume responsibility for the integrity of this data then I am going to look to persistence merely as a way to intermediate the domain elements.

Frankly, I have been reading that some people are trying to reach a state of embedded graph integration that effectively yields an OO db. This is where things should go. And the database should stop being another boundary into another world where things are transposed into another language. As the cloud‘s ascent continues, the whole modal approach of loading data, doing some work, then putting it away, is going to change. Most apps will just be running all the time. Clearly, when you look at this as a value stream map (a la Lean), OODBs have huge potential to cut down on the drag that we have all come to accept (while not really getting what we are paying the toll for).


From http://www.jroller.com/robwilliams/entry/the_relational_belt_and_suspenders

The Java Zone is brought to you in partnership with ZeroTurnaround. Discover how you can skip the build and redeploy process by using JRebel by ZeroTurnaround.


{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}