Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

SQL vs. NoSQL Databases: What’s the Difference?

upwork.com

Post reply on HN
Print view View original

41–50 of 60 posts

Re: SQL vs. NoSQL Databases: What’s the Difference?

#41

Post by _0w8t »

ktamura wrote: post #17

I personally think SQL v. NoSQL is less useful of the two dichotomies, the other one being OLTP v. OLAP. In the end, SQL is just an API. You can put SQL-like interface on NoSQL as well (like SlamData for MongoDB or Crate for Elasticsearch). On the other hand, OLTP v. OLAP (transactional v. analytic) is directly tied to use cases and has more profound consequences as far as technical decisions go (data structures, alg…

This is very good point. For example, MongoDB and Oracle are not that different compared with Splunk.

Re: SQL vs. NoSQL Databases: What’s the Difference?

#42

Post by jimbokun »

aristus wrote: post #18

Bah. People keep confusing the syntax with the data model. SQL is simply a notation to express theorems in relational set theory. It's pretty much the only pure-functional, side-effect-free programming language that's actually gone mainstream [0]. If you look carefully at the APIs of the "No SQL" databases, you'll find them introducing relational set theoretic features. To paraphrase Paul Graham's unbearably smug com…

NoSQL DBs became popular because performant distributed joins are hard.

Joins (and aggregate, group by, etc.) were thrown out to make horizontal scale out simpler. Cassandra CQL, for example, shares keywords with SQL, but the key-value(ish) data model couldn't be more different, and is much easier to scale horizontally.

Various systems are trying to solve the distributed join problem while keeping easy horizontal scaling, and if they succeed the NoSQL label won't make sense for those systems any more.

Re: SQL vs. NoSQL Databases: What’s the Difference?

#43

Post by hardwaresofton »

overcast wrote: post #8
hardwaresofton wrote: post #6

Postgres is the last SQL DB thing mentioned? No mention of RethinkDB ( https://rethinkdb.com/ ) ? SQL is good if your data is "unchanging"? Schema migrations happen, SQL can be sharded and scaled to multiple servers, and the fact is, unless you're facebook or google, you probably won't even need it. Didn't reddit run postgres since it began? Glad I skimmed this.

Yeh seriously RethinkDB is the perfect hybrid of "NOSQL" document storage, with SQL like relationships. Been using it for all my projects the past year, and I love it.

Same here, I have no idea why it doesn't get more press, as far as I'm concerned it's the best document store out there.

Mongo has gotten away with some pretty substantial misses, yet still get considered every time NoSQL comes up (maybe first-to-market is really just that powerful), but RethinkDB rarely gets one, despite being so stable and having so many good features.

And when I say mongo has gotten away with substantial misses, I don't mean the documentation miss that lead to documents getting dropped, I mean core issues with their engine that necessitated the wiredtiger contributions/rewrite. Of course, mongo works very well generally, and they've definitely done their part when it comes to documentation and growing the community, and carving the path for what NoSQL document stores (in this day and age) look like.

Re: SQL vs. NoSQL Databases: What’s the Difference?

#44

Post by wvenable »

beachy wrote: post #38
wvenable wrote: post #27

Earlier quoted context omitted.

In my experience, if you have the relational database model fully defined and correct then the rest of the application is pretty much designed. All the screens and elements you need are obvious.

Indeed, but if you are building in microservices, a new level is introduced. If you can get your service boundaries and APIs fully defined and correct, then the relational database models (underpinning each of those services) just fall from the tree for you. And then as you say the screens and elements are obvious.

Honestly I'd still prefer to go other way -- from the relational database models you get your APIs defined and correct and then the screens and elements are obvious.

I find if you start at the database model layer you much less likely to screw up the API design. The database model forces a bit of rigor that you can't get going the other direction.

Re: SQL vs. NoSQL Databases: What’s the Difference?

#45

Post by wvenable »

Scarbutt wrote: post #26
gjolund wrote: post #3

I have issues with his "Reasons to use NoSQL" * Making the most of cloud computing and storage There are plenty of "cloud" hosting options for SQL databases, enough that a simple google search should make my point for me. * Rapid development This is a really common reason that I have heard for wanting to use NoSQL databases. It is flat out wrong. While NoSQL databases may not force you into a schema for your database…

SQL migrations may seem tedious, but the process of planning your data model and having rigid definitions for your data types saves you huge amounts of time in the long run. Your reasoning seems too black and white, most the of the time, you can't know your data model ahead of time, that's why prototypes are so useful, so just using your language data structures or some less rigid datastore lets you get quicker to yo…

This sounds so logical, is repeated often, and is fundamentally incorrect. Just because you are defining a data model doesn't mean you can't change it. There's nothing easier. Undefined schemas are actually worse under change than defined ones.

Re: SQL vs. NoSQL Databases: What’s the Difference?

#46

Post by Scarbutt »

paulmd wrote: post #30
Scarbutt wrote: post #26

Earlier quoted context omitted.

SQL migrations may seem tedious, but the process of planning your data model and having rigid definitions for your data types saves you huge amounts of time in the long run. Your reasoning seems too black and white, most the of the time, you can't know your data model ahead of time, that's why prototypes are so useful, so just using your language data structures or some less rigid datastore lets you get quicker to yo…

Having rigid definitions for data types doesn't necessarily mean the datastore is rigid. It just means that you know what type of data goes in each column. Like it or not, if you change your schema that change has to be handled somewhere - either you update the old data to the new schema (do this), or you handle old versions of the schema in the application (fundamentally non-scalable IMO). It doesn't matter whether…

That is why I mentioned prototypes, they are a quick messy hack that is not meant to scale, its purpose its to validate your ideas and decisions, what is going to become your MVP, which IMO is far more important than getting the perfect stack/tooling from the start.

Re: SQL vs. NoSQL Databases: What’s the Difference?

#47

Post by beachy »

wvenable wrote: post #44
beachy wrote: post #38

Earlier quoted context omitted.

Indeed, but if you are building in microservices, a new level is introduced. If you can get your service boundaries and APIs fully defined and correct, then the relational database models (underpinning each of those services) just fall from the tree for you. And then as you say the screens and elements are obvious.

Honestly I'd still prefer to go other way -- from the relational database models you get your APIs defined and correct and then the screens and elements are obvious. I find if you start at the database model layer you much less likely to screw up the API design. The database model forces a bit of rigor that you can't get going the other direction.

IMO it's dead easy to create APIs from a database schema, where that schema underpins your monolith and you're opening said monolith up to the outside world, and you don't really care too much what goes on out there.

But if you're building a system which is not a monolith, and instead is made of up of, say, 20 services, then putting good boxes around those services and defining the lines that connect them (the APIs) is an essential prereq to designing the databases that sit inside the boxes.

(Though really what's happening, as always, is you're doing it all in parallel, just with more emphasis on the higher level stuff).

Re: SQL vs. NoSQL Databases: What’s the Difference?

#48

Post by gshulegaard »

btilly wrote: post #40
gshulegaard wrote: post #33

Earlier quoted context omitted.

This is interesting, but I admit I am a bit confused. Having read "An Introduction to Database Systems" by C.J. Date ( http://www.amazon.com/Introduction-Database-Systems-8th/dp/0... ), I have a tremendous appreciation for Relational Algebra and Theory which allows for the closed functional nature/syntax of SQL which holds true across the various normal forms (1st-5th). Perhaps due to my own lack of understanding, I…

Syntax and being relational are orthogonal. You can set up non-relational data structures in SQL. You can set up a relational data structure in virtually any programming language. However what the NoSQL people are learning is that smart developers really want relational models. So they are offering the features that can be used to achieve that.

That's where I think where most NoSQL proponents start to miss the value of relational models and the closed Relational Algebra it allows.

As I understood it, SQL was a language for describing the Relational Algebra which was a closed mathematical concept.

You can take the syntax, assign functions to produce output from a non-relational model, but it's no longer SQL...and it's underlying power (the closed Relational Algebra) is no longer present.

So in a sense syntax and being relational are orthogonal, but syntax isn't the defining characteristic of SQL (or why it's so powerful). I think a more insightful statement is: SQL (Relational Algebra) and being relational are codependent and relational and non-relational are orthogonal.

Which, if I am not mistaken (and again I am still trying to understand the finer points which is what motivated my original comment), NoSQL people fundamentally _cannot_ offer a query language similar to SQL based on the closed relational algebra.

They can mimic the syntax to make it more intuitive for new users coming from traditional RDMBS environments, but it's fundamentally _not_ SQL/relational algebra.

But again, I am just a cursory admirer/learner and I am still trying to iron out my own understanding of the underlying theory. So all additional information/clarifications welcome :)

Re: SQL vs. NoSQL Databases: What’s the Difference?

#49

Post by aristus »

mindcrime wrote: post #28
aristus wrote: post #18

Bah. People keep confusing the syntax with the data model. SQL is simply a notation to express theorems in relational set theory. It's pretty much the only pure-functional, side-effect-free programming language that's actually gone mainstream [0]. If you look carefully at the APIs of the "No SQL" databases, you'll find them introducing relational set theoretic features. To paraphrase Paul Graham's unbearably smug com…

Along those same lines, you can - in principle - have a relational database that doesn't use SQL (although there aren't many in practice), and plenty of "NoSQL" databases use SQL (or a VERY SQL-like language). You can layer SQL on top of a lot of different data models, although the mapping will be cleaner in some cases than others.

Absolutely. But at that point we are quibbling over syntax instead of semantics, which is not that interesting. In practice you can do hierarchical models in SQL just fine (cf Oracle's ANCESTOR features, or AsterData's regexps), and bag-of-features stuff using JSON. Graph models are more awkward, but graph models are always awkward.

Re: SQL vs. NoSQL Databases: What’s the Difference?

#50

Post by hiphipjorge »

overcast wrote: post #8
hardwaresofton wrote: post #6

Postgres is the last SQL DB thing mentioned? No mention of RethinkDB ( https://rethinkdb.com/ ) ? SQL is good if your data is "unchanging"? Schema migrations happen, SQL can be sharded and scaled to multiple servers, and the fact is, unless you're facebook or google, you probably won't even need it. Didn't reddit run postgres since it began? Glad I skimmed this.

Yeh seriously RethinkDB is the perfect hybrid of "NOSQL" document storage, with SQL like relationships. Been using it for all my projects the past year, and I love it.

Gotta love the subqueries and the join command! Makes everything nicer!
Post reply on HN