5

I have an application that uses SQL Server. I wanted to use a NOSQL store and I decided it to be graph since my data is highly connected. Neo4j is an option.

I want optimally to be able to switch the databases without touching the application layer, say, just modifying some xml configuration files. I've taken a look at some examples public on the web, I've seen that ORM and OGM don't configure applications the same way, the config file of each has it's own name and more importantly its own structure. Looking at the code of each revealed that they also differ in the way they initialize the session, which doesn't sound good for what I'm thinking of.

My question is: "is it possible or feasible-without-great-overhead to switch between the two databases without touching the existing application code? I may add things but not touch what exists already". It would be a great idea to establish a pure polyglot persistence between SQL and NOSQL databases, for example, using Hibernate.

I want to hear from you guys before digging deeper. Do we have one of Hibernate men with us here in SO?

Community
  • 1
  • 1
Avise
  • 91
  • 1
  • 7

1 Answers1

3

The goal of Hibernate OGM is to offer an unified abstraction for various NoSQL data stores. The project is still young, as we speak, so I am not sure if you can adopt it right out-of-the-box.

There is also the problem of transactions. If your application was designed to use SQL transactions, then things will radically change when you switch to a NOSQL solution.

Using an abstraction layer is good for portability but doesn't offer all the power of native querying. That's the same problem with JP-QL, which only covers SQL-92, lacking support for window functions or CTE.

Polyglot persistence is a great feature, but try using separate repositories, like Spring Data offers. I find that much more flexible from an architectural point of view.

Vlad Mihalcea
  • 142,745
  • 71
  • 566
  • 911
  • So in your opinion, switching between a JPA relational store and a document oriented database from a single code base is not practical? – Dave Sep 16 '14 at 15:39
  • I wouldn't recommend it. I think it's better to separate those, possibly behind clear service facades. – Vlad Mihalcea Sep 16 '14 at 15:58