Ford. vs. Chevy
Coke vs. Pepsi
Edison vs. Tesla
Wisconsin vs. Minnesota
Our world is full of time-honored rivalries that spur endless conversations, Facebook posts, and merchandise sales.
Just a Database?
Your choice of a SQL or NoSQL database for your project probably won't put your Facebook feed in an uproar. Then again, based on some of the blog comments I found while researching this article maybe it will.
So why all the fuss and bother? It's just a database, right?
To people who really care about database technology that's like saying "it's just a game" or "it's just a car".
A good rivalry requires two opponents that are equally worthy but feature different strengths.
This is certainly the case with SQL vs. NoSQL.
Then again, is it?
As the products evolve it may not make sense to talk about them as an either/or for much longer.
Like teams trading players, like Chevy engines getting swapped into Fords, SQL and NoSQL products are blurring the lines of distinction by each offering features from the other camp.
But let's keep the rivalary going for just a bit longer - at least to get a sense of how the two approaches think about data, data storage, and data retrieval.
The main defining point of SQL databases is in the name itself - SQL stands for Structured Query Language.
Rows and columns.
Cells of discreet data.
SQL database designers are highly focused on creating a well-defined, highly-thought-out structure for data to go into. The database structure is often created early on in the project. Changes to it become harder as the database grows in size.
The goal is "normalized" data - so one piece of data is stored in one place and one place only. Updates are more efficient as they are only made in that one place.
Relationships between tables of data are tightly defined. If you are tracking customers and orders, they would be in separate tables with a relationship created between them. A query can retrieve all orders for a specific customer.
The database can even enforce the data model - so no orders can be entered without customers. Or all phone numbers must have 10 numbers. Or every new project has a Project Manager assigned.
SQL databases are great when your data is well structured and that structure is known in advance. SQL databases typically scale well vertically - so you increase performance by adding more power to the server or server cluster the database is hosted on.
But - what if your data isn't that well structured? What if it's structured in different ways?
While that phrase is itself enough to strike fear in the hearts of many SQL database developers, unstructured data does exist in the real world.
- Content from social media sites
- Customer reviews
- Call center conversations
NoSQL databases are nonrelational and document based. One way to think about a NoSQL document is a blog post with tags, categories, photos and video, and user comments. In a SQL database you'd seperate those elements out into their own database tables and use a query to bring them all back together.
In a NoSQL database they would all be stored in a single document. If one blog post (document) needed an additional element (such as a downloadable PDF) you could add one field to that one document. The entire database wouldn't have to be updated.
Does your project have data requirements that are intially unclear?
Do you need extremely high performance in getting results back from queries?
Does your project have the potential need for rapid scaling (like, you just created the next PokeMon Go)?
If you've answered any of these questions "yes" then a NoSQL database may be for you.
Here at Omni we've recently begun specializing in the MarkLogic product. MarkLogic is a highly scalable and certified secure NoSQL database. It also comprises a search engine and application server with audit trails, flexible deployment, and ACID-compliant transactions.
We're pretty tickled with it so far, and would love a chance to talk further about how it might fill your project requirements.
We'll even provide a can of your favorite cola.