Implementing a NoSQL and RDBMS compatible DAO

Question

What would be the correct way to design a DAO which implementation is first going to be targeting a MS SQL database with a STAR model, but yet, business requirements specify the application must be flexible enough that it would be able to be migrated to a NoSQL database in the future if required. Which type of NoSQL, no idea...

My confusion is that i cannot seem to figure out how could I build independent DAOs for the STAR Dimensions and Facts tables which could then be swapped for a completely different model that might not even be table oriented (riak/mongo/whatever).

Therefore,

Should I create DAOs which rather than abstracting the table, it abstracts the CRUD operations - for example create IDaoInsert which can then be implemented as SQLInsertDaoImpl and MongoInsertDaoImpl, each with a completely different model logic etc.

or

Should I just create the typical DAO design whose interface would be something like IDaoCustomerDimension, and the implementation SqlDaoCustomerDimesionImpl and MongoDaoCustomerDimentionImpl respectively?

Hibernate/Etc are out of the scope of this question for the time being.

• Luiggi Mendoza: IMO using a rdbms or a no-sql engine won't matter to the business. A business entity will be the same regardless of the data source. And that's how you should define your DAO interfaces.
• Carlos: @LuiggiMendoza so if i understand correctly, you suggest the second approach?
• Robert Harvey: There really isn't all that much difference between SQL and NoSQL data stores, from a CRUD perspective. Each one stores tables. Write your DAO accordingly.
• Carlos: @RobertHarvey. Not really. You have document, KeyValue, Table (without joins, etc), graph, and the list goes on.
• Robert Harvey: You need a layer to abstract the differences. But CRUD is CRUD, and there are only four operations you need to implement.

Answer 1

Your architecture should look something like this:

Data source <--> Data source driver <--> CRUD interface <--> Application

You'll need one data source driver implementation for each type of data source. The CRUD interface will be the same regardless of data source.

Note that you can have more than just CRUD methods. You might want to return collections, for example. Just make sure that whatever you do on the Data Source side is translatable to your API on the CRUD side for all possible data sources.

Answer 2

This is really dependant, for instance if you take managed entities in JPA, you will almost never used the update method directly, since updating the model will be automatically transefered to the database on commit.

On the other hand, having JPA while not using managed entities through converting DTO to business model is very inefficient.

Furthermore, there are document NoSQL database, key-value, ....

In my opinion, just design a proper service interface and one implementation that use properly ORM objects and a proper JUnit Suite tests. Then if you have to switch, rewrite the same service with it's own DAO layer for NoSQL when it will be time against the same suite of JUnit test.