Relational Databases
If you are a software developer then you probably have some sort of experience with a traditional RDBMS (Relational Database Management System). SQL or structured query language is the language that you use to retrieve data from a SQL based database system. SQL based database systems are based on relational algebra. You initiate queries to retrieve sets or intersections of data. These databases are defined by their schema. The schema defines tables, columns, relationships, constraints, and keys. SQL databases have been around for a long time and they aren’t going anywhere anytime soon. There is a time and place to use this type of system. Typical uses include Data warehousing, data reporting, and application data storage.
Complexities of SQL based database systems
With SQL based database systems you often need a database administrator to facilitate maintenance on the server. In a clustered database environment, concurrency can become an issue when you need to combine data from multiple database systems into one central database. Issues of replication or redundancy and back up disaster recovery requires an administrator that fully understands the way that SQL schema’s and programming work.
SQL to objects and objects to SQL
When programming in SQL based databases, there is a fundamental challenge of pulling data from a database using SQL and transforming the set based results into an object’s properties. The same difficulties must be resolved when saving object properties back to the SQL database. For the past 10+ years it has been up to the developer to write custom code to handle these issues. Recently, ORM systems have assisted developers with this issue. The schema still requires the developer to map object properties to database columns. If the schema changes, you have to change database stored procedures, functions, as well as application code that deals with selecting and inserting and updating data. The functions that facilitate relational databases create difficulties that must be solved to use the systems effectively.
Repository pattern
The repository pattern exists to provide a way to retrieve data from a routine that provides a layer of abstraction between the call and the underlying database server. This is usually implemented by some interfaces and specific repository classes. This adds to the amount of infrastructure boiler plate code that must be used in each application to simply retrieve data from an SQL database.
Recently there has been a lot of talk about NoSQL based databases. When I first heard about this concept, I was very skeptical on how this would work. I had been working with SQL for the past 10 years and it’s what I’ve been used to. I decided I would take a look at RavenDB to see what all the fuss was about. RavenDB has changed my views on the issue.
There are times when you have no need to worry about the way that your data is stored. There are some instances in which you have no need to generate reports on data or utilize relationships. Some times you simply need the ability to store an object’s state and retrieve it later for use in your application. This illustrates a perfect time to utilize NoSQL and RavenDB.
Written by Buddy James of refactorthis.net. Read the full article here.
