Why I want use GORM standalone in Griffon.
After nearly a week of researching OODBS (Object Oriented Databases) vs RDBMS (Relational Databases) I am coming to the conclusion that this quote excerpt sums up the problem.
Robert C. Martin:
The problem actually has very little to do with OO and RDB. The problem has to do with OO and DB. That is, the problem exists with any kind of database, including OO databases.
The reason is that applications are dynamic, and databases are static. There is a paradigm boundary that must be crossed when communicating between these two domains.
Consider. A database, any type of database, is a repository of information. An application, on the other hand, is a manipulator of information. One is static and the other is dynamic. The database is a representation of information, and the application is a representation of behavior. Two different paradigms.
In the case of the applications, our goal is to encapsulate the data and expose the behavior. In the case of the database, our goal is to expose the data and remove the behavior altogether. This is the boundary that is difficult to cross.
Now you might think that in an OO database, the object in the database possess complex behavior and so the database can encapsulate data and expose behavior just like an application. However there are forces that prevent this from being an effective strategy. [Read the rest …]
So following our don’t solve the wrong problem line of thought, does simply using pure OODBS solve the above problem? No.
It’s all about the tools and solutions that are provided to cross that paradigm boundary . While Db4o does provide some solutions that help with DB re-factoring, no mapping and returns objects to the application that is essentially what GORM does too.
In both we can write Groovy domain classes that describe the data that we want to persist and they both map this to a disk store for us. They both require code to be written to manage live DB migrations and I believe SQL will win in the case of larger datasets.
GORM stores the data in what is effectively an open format while Db4o stores the data in what is effectively a binary blob, application code needs to be written for any interaction with this data. Worse still that data’s structure is stored in the domain classes so I can see the need for creating domain.jar and passing that around to anyone that needs to access the data. All these things do have solutions (GenericObject etc) but they must be developed and implemented in OODBS when they already exist in RDBMS and for what real life benefit?
So my initial attraction to the purist concept of OODBS and no database setup or management quickly evaporates in any real world situation. Even just a standalone desktop application will required code to manage live databases and GORM provides more solutions than Db4o currently does.
Where I can certainly see Db4o and Perst being an improvement over GORM and Sqlite is in handheld devices which are overhead critical. But even here in an enterprise environment I can see these portable databases being synced to a stationary OODBS and then (or directly) to a RDBMS.
But just maybe I’m looking at this all wrong and the real beauty of OODBS architecture is the ability to make very rich domain objects and self contained applications with rich import/export and REST functionality. So I guess I will have to try building a small but real application to fully decide.
“Even just a standalone desktop application will required code to manage live databases and GORM provides more solutions than Db4o currently does”
Can you elaborate? Where do you see more options on the GORM side compared to db4o?
Best!
Well one of the small things I found was that if an existing db4o.db is opened with the wrong version of the library bad things happen to it. So one must develop a strategy to guard against this. There are a few of these things that add up and are simply due to maturity, as time passes no doubt these things will be solved.
Do note though that GORM standalone turned out to not really be a viable option at this point either. I think primarily due to the large memory footprint of Spring and not much work going into it.
In the end I don’t know what I would choose for a production desktop app (dropped the one I was considering in favour of more web-apps with Grails). I do feel I would stick with SQL and maybe something like SQLAlchemy. Also perhaps still Qt over Griffon at this point unless the data requirements are light.