GOTO Conferences
6 HN recommenders · recommended in 8 months, 2015–2021
54:52 · 1M views · Feb 19, 2013
Martin Fowler's GOTO 2012 introduction to NoSQL databases: where they came from, their data models, how consistency thinking differs, and when to use them. He argues they won't make relational databases obsolete and introduces polyglot persistence.
HN repeatedly recommends it as a balanced, beginner-friendly overview of SQL versus NoSQL, and some teachers assign it to students.
10 comments from Hacker News
First, the "Mother of all Demos" by Doug Engelbart: [LINK] This was in 1968, at a time when most people thought about computers as being machines for solving computation problems, like processing payrolls or calculating rocket trajectories. Engelbart and his students had the radical idea that computers could be used for human "knowledge worker" productivity. In one 90 minute presentation, he introduces everything from the idea of a GUI, to the mouse, to word processing, hypertext, computer graphics, and (simulated) videoconferencing. You have to be able to put yourself in the shoes of the audience that has never seen this stuff before, and it'll blow you away. Something more recent: Martin Fowler's great introduction to NoSQL: this video Not so technical, this is a great overview of the reasons why (and when) NoSQL is valuable. He crams a lot into a short speech, so it's one of the rare videos I've required students in my database classes to watch. Now, really getting away from the technical, I have to recommend watching the IDEO shopping cart video: [LINK] This is the classic introduction of Design Thinking to the world, in 1999. If you're using the Lean Startup or an Agile method, but have never heard of IDEO's shopping cart, you may be able to get along fine at work, but you should be kind of embarrassed like a physicist who's never read Newton.
As a starting point, if you have little background in NoSQL, I strongly recommend this 1 hour talk by Martin Fowler: this video It's slightly dated, but it still gives a strong overview of the different paradigms. The truth is what you want to learn probably differs greatly depending on the paradigm that fits your application. NoSQL databases can broadly be categorized into document-oriented, key-value store, columnar, and graph. This video will help you understand what (at least three) of those are. Then you can focus in on books/articles about the paradigm that makes the most sense for you.
Exactly, but it goes further than that. The mentality never made sense since the term NoSQL never made sense to start. It's amazing how many people use a term that just originated from a meeting to talk about alternative databases. How we keep using it, although it's practically impossible to say what NoSQL is. Depending on whom you ask that term means different things. This is a very good introduction to the term: this video Graph databases are considered 'NoSQL' yet they have relations and transactions. Schemaless is often also one of the properties give to NoSQL, but it's also a bit strange to consider that a NoSQL attribute. Some traditional databases offer schemaless options and databases like Cassandra has schema yet is considered NoSQL. I work at Fauna which has relations, stronger consistency than many traditional databases. It is schemaless at this point but that might change in the future. Since it doesn't offer SQL it's thrown into the NoSQL bucket with the assumptions that come along with it. None of these one-liners in computer science make sense IMHO and we listen way too often to colleagues who use them. Similarly "Use SQL for enforced schema" might be accurate in many cases but in essence it depends on your situation, and we need to do research about what we use instead of following one-liners ;)
The idea is that you won't need database-wide transactions if your data is structured into "natural aggregates" such as orders, articles, profiles, etc. In a relational database, something as simple as an "order" has components in lots of different tables -- customer, product, order, line_item, shipping_method, etc -- so you have to lock all of those tables when doing an INSERT or UPDATE. In the ideal MongoDB implementation, an "order" would be a document of its own, and all the other parts would be attributes or nested structures. So you only really need a transaction for the document itself. Other documents could be inserted/updated at the same time without creating a conflict. That's the theory, at least. Martin Fowler has a good Youtube on "Introduction to NoSQL" that I sometimes show to my students: this video The other thing about NoSQL is that it's often used for write-once, then read-only applications. Twitter, Facebook, or Instagram would be good examples. When 1% of your queries are INSERTs and 99% are SELECTS (with UPDATE and DELETE almost never occurring), you really don't run as much risk of anomalies. I would not recommend NoSQL for something like a banking application where you're doing lots of updates and need to guarantee consistency.
"There is as yet no absolute challenger to the relational model. When people think database, they still think SQL. But if there is a true challenger, it is in the graph model." This article is quite biased towards graph databases with regards to the SQL versus NoSQL tension. This video presents a much more balanced view of SQL versus NoSQL, in my opinion. this video