I have issues with his "Reasons to use NoSQL"<p>* Making the most of cloud computing and storage<p>There are plenty of "cloud" hosting options for SQL databases, enough that a simple google search should make my point for me.<p>* Rapid development<p>This is a really common reason that I have heard for wanting to use NoSQL databases. It is flat out wrong.<p>While NoSQL databases may not force you into a schema for your database, you will pay a toll for this mutability in your application layer.<p>I have worked on several NoSQL backed projects, and nearly without fail development speed drops like a rock once you make changes to the way your data is persisted.<p>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.<p>Data is the foundation of most applications, and if you can't rely on your data then you are building your application on sand.
Why is this even on HN? There's no reason to debate this, it's a content marketing fluff piece for a company that has no technical pedigree, written by a freelance copywriter rather than an engineer.<p>It's also about 50% wrong. Let's just move on.
The article read like it is written by someone who has never understood how to use a SQL database.<p>To quote Mr Torvalds himself:<p>"Bad programmers worry about the code. Good programmers worry about data structures and their relationships."<p>Something that i struggled with before i learned how to use a SQL/relational database was to actualy use the database relations in my code. I first specified the relations in the database then i basicly redid them in the code.<p>The way i tend to program these days is to have basically all my relations restrictions and relational rules in the database.
Whenever i want to change something you just alter stuff in the database GUI.
Most of the application code will just follow along.
Chuckling at:
Your data is structured and unchanging. If your business is not experiencing massive growth that would require more servers and you’re only working with data that’s consistent, then there may be no reason to use a system designed to support a variety of data types and high traffic volume.<p>SQL Databases support a variety of data types and high traffic volume, they just dont allow you to change things without thinking a little more deeply on the problem.<p>This article is just fluff.
Postgres is the last SQL DB thing mentioned?<p>No mention of RethinkDB (<a href="https://rethinkdb.com/" rel="nofollow">https://rethinkdb.com/</a>) ?<p>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?<p>Glad I skimmed this.
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).<p>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, algorithms, etc.)
This talk by Martin Fowler is a fantastic overview into the SQL vs NoSQL discussion : <a href="https://www.youtube.com/watch?v=qI_g07C_Q5I" rel="nofollow">https://www.youtube.com/watch?v=qI_g07C_Q5I</a>
There should be mentions about CAP theorem, and tradeoffs about consistency vs availability. Sometimes you dont care as much about CAP-consistency than availability or scalability.
For me, the most important difference is that a SQL "Database" is actually an incredibly powerful application server, with a built in compiler for a data processing language, and many years of development on access strategies, whereas a NoSQL database is just a level above an http server with an index that scales really well. That's a bit of an exaggeration, but I find it helps new teams understand the big picture. In a microservice environment, I encourage my teams to think of their SQL database server as a microservice, not a persistence store.
Many databases considered NoSQL actually have SQL now. Cassandra for instance. Granted it's not as critical to the execution as SQL is for RDMS but I would much prefer the distinction to be: RDMS / Relational versus KeyValue / Document Stores. But I digress.<p>Some of the other criticisms in this thread are very valid especially in the area of why you should use one versus the other so I won't bother regurgitate them I just felt like a better distinction could have been used between what they were comparing.
> <i>NoSQL data doesn’t need to be prepped ahead of time.</i><p>Unless you're using CouchDB and you need to change some views, and then you have to re-index the whole thing, which can take forever.
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.<p>To paraphrase Paul Graham's unbearably smug comment about Lisp: once you add filter, group by, and join, you can no longer claim to have invented a new query language, just another dialect of SQL. Math has this funny habit of remaining true no matter how many mean things people say about it on their blogs.<p>[0] I mean basic core SQL, not the vendor-specific stuff like PL/SQL.
I'm always saddened when I don't see MultiValue[0] databases in the list, but the reality is that there's almost nothing that's open source in this space.<p>My first real job was doing development on a custom application built entirely in UniVerse[1]. It was a really interesting way to work and mirrors a lot of what the Open Source NoSQL databases do, though it does it differently. Instead of storing the schema with the records (e.g., a JSON document), a record was simply a list of data elements (fields), each field could have multiple values (or not), each value could have multiple subvalues (or not), and there was a lower level that you could go to in order to store multi-line text data.<p>There was a dictionary attached to each file that primarily drove the query tool. You could also build calculated fields (I-descriptors) to do primitive joins, among other things. If you had a file containing invoices, you might have two fields to list the item number and quantity (these would be repeated for as many items as are on the invoice). You could then use an I-descriptor to follow item number over to the items file and pull the description, price, etc.<p>The entirety of the application ran within UniVerse. When users logged in to the unix server, their shell would run a script that would set up the environment and fire up UniVerse. The UniVerse LOGIN paragraph would then show a menu system and allow them to do their thing. Everything was written as either a paragraph, roughly equivalent to a shell script that ran UniVerse commands, or a BASIC program. The dialect of BASIC natively understood dynamic arrays, which were a 1:1 match to the structure of the records on disk.<p>UniVerse also had a built-in way to execute SQL queries against the multivalued data. In the invoice example above, the item number and quantity would be associated in the dictionary. These would then be exposed as another table by the SQL engine. You could go "SELECT A.INVOICENO, B.ITEMID, C.DESCRIPTION, B.QTY FROM INVOICES A, INVOICES_ITEMS B, ITEMS C WHERE A.@ID = B.@ID and B.ITEMID = C.ITEMID" and it would know that INVOICES_ITEMS is really part of the data in INVOICES.<p>It was a really cool system and I wish there was something like it in the Open Source world. Sadly, development on MaVerick[2] seems to have stalled.<p>[0] <a href="https://en.wikipedia.org/wiki/MultiValue" rel="nofollow">https://en.wikipedia.org/wiki/MultiValue</a><p>[1] <a href="http://www.rocketsoftware.com/products/rocket-universe" rel="nofollow">http://www.rocketsoftware.com/products/rocket-universe</a><p>[2] <a href="http://www.maverick-dbms.org/" rel="nofollow">http://www.maverick-dbms.org/</a>