See how Hrorm handles relationships between entities.
Let’s be friends:
Comment (0)
Join the DZone community and get the full member experience.
Prior articles about Hrorm gave an introduction and a first lesson. You may wish to take a look at those if you haven’t before diving into this article, which will explain how Hrorm (a concise, declarative ORM library for Java) handles relationships between entities.
SQL RDBMS platforms remain somewhat unfashionable. Some people seem to believe in a myth that they are not scalable enough. This may be true for some very large data sets and applications, but unless you work for a company with a name like Google or Amazon, your data is probably easily manageable by most popular databases.
There is also a tendency to imagine that a storage solution with an explicit schema will slow down development efforts. Many people have pointed out that you always have a schema (possibly more than one) even if you have not used tools that make it explicit. In my experience, knowing more about the systems I work on does not slow me down.
But neither of those two things is a critical issue to me. The flaw with no-SQL document stores is in how they manage relations. If you have data describing actors and movies, a document just will not suffice. If you choose to make the movies your top level structure, you will have to repeat the data about actors, since actors can appear in more than one movie. If you choose to make actors your top level, you have to repeat the data about movies, since movies have more than one actor. Normalization is (in part) the process of figuring out what your entities are, and how they relate to each other.
I know that document stores have references from one document to another, but RDBMS’s have been managing data according to a well-thought out mathematical theory for decades. To ignore them feels like a step backwards to me.
It’s the job of ORM tools like Hrorm to make the annoyances of using an RDBMS less. And the experience of using them (almost) as easy as using text files. Developers should get power and security, and they should not have to pay with inconvenience and aggravation. Whether or not Hrorm succeeds is up to you to judge.
One of the simplest relations two entities can have is when one always accompanies another. In the United States, every city is in a state. In Java, we might model cities and states like this. (The examples omit getters, setters, equals, and other Java essentials.)
The corresponding tables that would back this model would look almost identical.
The biggest difference is that in the object model, we include a reference to the state itself, in the database, the CITY only directly refers to the STATE’s primary key. Hrorm works by defining the relationship between the RDBMS SQL world and the Java world by creating DaoBuilder objects. The Hrorm code to describe these entities looks like this.
Most of that is identical to the features of Hrorm described in the previous articles.
