What DB you need?

moshe roth
Aug 28, 2017 · 3 min read

A short intro to SQL and noSQL. There are lots of pieces of information but I think we are looking at something that still evolves.

SQL — the structure is always tabular (rows and columns), you can join the table but this is it. If you planned it well — its normalized (meaning, no duplicate information is stored)

noSQL — whole bunch of different data structures you can create: Documents, Column-family, Graph and Key-value.

https://www.youtube.com/watch?v=qI_g07C_Q5I

SQL is ACID compliant

When taking a db into production where there are actual users, one will encounter consistency issues where parallel processes will use the database in a way that contradicts basic assumptions about the system — and the data in the db may become corrupt. There are many examples our there. Nothing replaces a good engineering of the backend but SQL servers come with builtin compliance to ACID (production considerations of DBs — Atomicity, Consistency, Isolation and Durability) which makes it easier to deal with those kind of problems. So what is ACID? Another way of saying that the DB is able to apply restrictions on transactions and data structure. BUT you need a DBA for that or to understand how to use the ACID tools (for example, foreign keys).

noSQL is BASE compliant

Easy to code, easy to scale, flexible data structures.

“BASE” is acronyms that says that eventually — that data is valid but there is no guarantee. It’s up to the coder is responsible to different scenarios of dealing with the “ACID”-ity of your DB.

According to Martin Fowler:

https://youtu.be/qI_g07C_Q5I?t=46m26s

noSQL is also a first go-to when there is no impedance mismatch

The mismatch I refer to is a result of the differences in structure between a normalized relational database and a typical object oriented class hierarchy. One might say Databases are from Mars and Objects are from Venus. Databases do not map naturally to object models.

You don’t need to normalize the data because you don’t care about the content of the “value” that you store.

What about scaling?

I think that this quora talk clearly shows that SQL dbs are not so good at scaling- how to scale SQL db is a hard task and not suggested to approach without the appropriate skillset.

https://softwareengineering.stackexchange.com/questions/194340/why-are-nosql-databases-more-scalable-than-sql

You can read in this comment

If you need that stuff, you need to do it yourself, but if you DON’T need it (and there are a lot of applications that don’t), then boy howdy are you in luck.

I think that this is a major consideration. Letting the coder decide how to handle consistency, availability etc issues instead of the DBA.

There are obviously a lot of topics to learn and understand as a coder of noSQL for production. The business logic takes a big part of the approach. The thing with SQL db is you don’t have an option many times and you need the scalability noSQL databases provide in order to apply different business logics in different scenarios.

A consideration when choosing a DB should be “what are the strengths/compromises you take when scaling”.

Summary

The differentiation of the SQL/noSQL is arbitrary and in my opinion, will disappear from our jargon eventually. Also, backend engineers should understand how to scale DB and know the pitfalls of working with their DB.

)

moshe roth

Written by

I love technology and people. I’m extremely fond of products that disrupt markets and use data to do so

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade