I am working with a third client that will be using both a SQL and NoSQL solution (often SQL Server and Mongo). The last two clients I worked with understood a great deal of technical information, so phrases like relational database or document storage made sense to them. I tend to use bank processing as a SQL example and blogging storage as a NoSQL example, which – up to this point – have made sense to my clients. When clients think of examples like transactions and “live feeds” that can be hundreds of thousands of characters, they can sometimes prefer both solutions.
This other client, who’s brilliant in his business, doesn’t have that technical edge (he’s an outstanding charismatic leader, so in no way shape or form am I disparaging him, as we all have our strengths). I’m curious if anyone here has had to explain these database concepts to people unfamiliar with them from a technical angle and what analogies you used to explain how each process works separately and how they would work together?
NoSQL (or schemaless, or document-store, or what-have-you) databases store information like you would recipes in a book. When you want to know how to make a cake, you go to that recipe, and all of the information about how to make that cake (ingredients, preparation, mixing, baking, finishing, etc.) are all on that one page.
SQL is like shopping for the ingredients for the recipe. In order to get all of your ingredients into your cart, you have to go to many different aisles to get each ingredient. When you are done shopping, your grocery cart will be full of all of the ingredients you had to run around and collect.
Wouldn’t it be nicer if there was a store was organized by recipe, so you could go to one place in the store and grab everything you need from that one spot? Granted you’ll find ingredients like eggs in 50 different places, so there’s a bit of overhead when stocking the shelves, but from a consumer standpoint it was much easier/faster to find what they were looking for.