In this short series of articles, we’ll be talking about JSON and its integration with the Oracle database. The first part was an introduction to JSON itself, and was, admittedly, very light on Oracle. But now it’s probably time to bring Oracle more into the story and talk about how the database has adapted to handle this new format.
Or, actually, instead of talking how, maybe we should be talking about why.
Think about it. The beauty – the efficiency – of a relational database such as Oracle is the way it takes an object, breaks it down it its smallest, indivisible elements and stores those elements across a logical landscape of columns and tables. As Oracle developers, we would look at:
and immediately begin to dream of, perhaps, a Person table with first_name and last_name columns; and a different table for Occupations; and then yet another table, maybe called Person_Occupation to link both tables; and then we’ll need a lookup table for the various occupations, and another lookup table for genders. Oh, and we haven’t even mentioned the primary key columns we’ll need to invent, or the triggers we’d have to write to manage them, or the constraints that’ll be needed to knit everything together and ensure data integrity; and –
Enough! Our JSON object is only 9 words long, but we already need 5 tables, 5 triggers and a spider’s web of crisscrossing constraints just to hold it. It’s madness!
Or, at least, so say the proponents of NoSQL databases. NoSQL databases eschew the tabular relational model that we’ve come to know and love with RDBMS like Oracle. With NoSQL you don’t spend hours building a cityscape of tables to hold a piddly bit of data. No sir. A NoSQL database (or, at least, a document-oriented NoSQL database) will store the whole JSON object together as a single entity.
NoSQL databases (or, at least, their forebears) have been around for decades – in fact, they predate relational databases, and RDBMS were invented to resolve the perceived problems with non-relational databases. However, with the growth of web 2.0 data behemoths like Google and Facebook, and with the birth of data formats such as JSON, NoSQL has had a huge resurgence over the last few years. So much so that the web is strewn with thinkpieces predicting the death of relational databases and the dawning of the new age of NoSQL. (Here are a few.)
All of which brings us back to the question: if JSON (along with XML and YAML) is one of the main reasons for the rebirth of non-relational databases, why are we here? Shouldn’t we be reading about this on a site called something like All Things MongoDB? (MongoDB is one of the more popular document-oriented databases; others include CouchDB, RavenDB and many others. Other NoSQL databases include Google’s BigTable, Hadoop, and Facebook’s Cassandra.)
Why on earth would you use Oracle for your JSON?
That’s a good question – even if it’s one that the accountants at Oracle would rather you didn’t ask. NoSQL document-stores are simple, they are built from the start to handle documents and the sort of key-value data that JSON is comprised of, and they are excellent at handling big data (hence Google and Facebook’s interest). So why on earth would you use Oracle for your JSON?
Before I attempt to answer the question, let me quickly restate some of the advantages of a NoSQL solution:
- It is schema-less (or, at least, is very flexible when it comes to schemas).
- It stores the whole document in one place, rather than scattering it across multiple tables like shrapnel.
- It is focussed on the key-value structure.
So, in the face of all of this, why on earth would you use Oracle for your JSON?
Good question, right? Actually, no, it’s not a good question. There are a million articles on the web taking sides in the RDBMS vs NoSQL debate, and, since you’re here, I’m going to assume that you’ve read some of them or, at least, are aware of the debate. But here’s the truth: in many, many cases, it is an irrelevant question.
If you’re an Oracle developer, working with a team of Oracle developers, in an organisation built on an Oracle database with a foundation of years of Oracle experience, then shouldn’t the question be can Oracle meet my needs? The question should be, can Oracle match (or mimic) the attributes of a NoSQL database while retaining the unquestioned benefits of a relational database?
And, after years of denigrating NoSQL databases (here’s Oracle Chairman Larry Ellison in 2012, and here’s Vice-President Andy Mendelsohn), Oracle finally turned their attention to answering that question. Starting with 220.127.116.11 they introduced the Oracle JSON Document Store. It is their way of harnessing the excitement of a NoSQL database, while, hopefully, losing none of the sturdiness of an RDBMS.
In the next article in this series, we’ll delve into that solution and see if they’ve succeeded.