SQL Zone is brought to you in partnership with:

Rob Williams is a probabilistic Lean coder of Java and Objective-C. Rob is a DZone MVB and is not an employee of DZone and has posted 170 posts at DZone. You can read more from them at their website. View Full User Profile

The Relational Belt and Suspenders

  • submit to reddit

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

Published at DZone with permission of Rob Williams, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Jonathan Fisher replied on Tue, 2012/02/21 - 10:27am

Putting constraints in the data store allow one to manipulate the data with any platform, and their data will stay in a consistent state. If you're a multi-product company with lots of shared data, you quickly realize that having the constraints in one place is a lot easier than having to replicate the constraint info across applications. For a single product compnay or a company with little shared data between products, these problems can be managed manually fairly easily.


The concept of schema-less, sql-less, constraint-less, database has been around since the 1970's (http://en.wikipedia.org/wiki/ADABAS). There are many disctinct reasons why people moved away from this model to the relational model, but it seems the tides are going back out for whatever reason.

Mark Unknown replied on Wed, 2012/02/22 - 9:31pm

Having constraints in one place does not mean they have to be in the database. I dont think Rob is saying they should not be one place. The reality is that they need to be inforced as soon as possible. Doing it at the persistance level, in many cases, is too late.  Modern applications do more than just put stuff in a relational database. They create messages to queues, update fulltext search engines, persist part of the object graph to a graph database send out other messages and also write to the RDBMS, all in one TX. Besides that, systems are putting caches and grids between the "user" interface and the persistance store. They cannot do this if all the rules are only enforced in the database.

 Business rules will be enforced in all layers, and more than likely must be although not all can be. Many can be declaritive and thus can be generated to enforced in the UI or database in addition to the middle layer (Service/Domain). Another way is to use a rules engine or something where code can be generated in the appropriate language , if needed be.

Sharing data at the database is just asking for trouble (aka Tight Coupling). Just like any app, bypassing layers is bad (ie. calling the database directly from the UI).  Having more than one "app" access the some persistant store is no different.  The RDBS Geocentric theory is no longer valid. http://en.wikipedia.org/wiki/Geocentric_model


Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.