Planet NoSQL

You've seen  why and how to model data in JSON . Once you have the data in JSON, you can store and retrieve the JSON documents in any simple key-value databases. If your application only has to set and get the documents based on the key, use any key-value store. you're all set. That's seldom the case. You don't use a database just to store and retrieve JSON. You're trying to solve a real business problem. You're developing a business application. For a business application, the questions, operations, and reports don't change just because your database doesn't support query. Business applications have to do many things requiring multi-object operation: Process Order Checkout. Search stores data for the shoe customer is looking for. How many new customers did we get last month? Generate the outstanding list of shipments due for today. Retrieve the customer order using case insensitive customer name. Load the new inventory data. Merge customer lists. For do...

JSON (JavaScript Object Notation) is a lightweight data-interchange format. It is easy for humans to read and write. It is easy for software to parse and generate. Here’s a JSON representation of a customer data in JSON. This has served well for interchange and integration. So far, so good. As long as JSON was used for data interchange between multiple layers of application, everything was good. The moment people started using JSON as the database storage format, all hell broke loose. When I first saw JSON as the data format in database, I was surprised databases would pay the cost of keeping both key names and values for every document and process them for every query. I've heard numerous questions in my talks and articles . Here are the common objections: JSON is text. It’s inefficient. JSON has no enforceable structure. Data quality is gone. Key-value pairs for every document (row)? You’re nuts. 1. JSON is TEXT. It’s inefficient Online transactions provided by RDBMS w...