Why the document model?

Data structure of structures is here to avoid transaction
========================================

Applications good fit for document data structure : With the advent of powerful mobile computing, more data needed to be exchanged between server and client. 
As more data flows between client server, more data structures needed to be designed to solve the problem. Solving this type of problem using relational 
databases was almost impossible. Due to the design principle of relational databases it was very tough to manage application designed for mobile platforms. 
 Keeping the data in plain text format was not efficient when you need the data to be presented as it is. Think of converting data type in a mobile application, 
 it is like a night mare. So document data structure solved all these problems. Nowadys it is very rare to find a mobile application with relational database. 
 Even though the last database could be relational for an existing project, mobile application never interacts with them. As document databases are making effort
 to make the interaction as smooth as possible, I can see all sorts of applications can shift to document based databases very soon. I don’t find any reason to 
tell that you need to use relational databases for your application.

Ex: My present application is based on MongoDB. Which is used by mobile applications to read/write data. One write example using Java code,

MongoCollection<Document> orderCollRef = ConnectionUtil.getInstance().createMongoClientInstance().getCollection(“XXXXXXXXXXXXX”);
orderCollRef.replaceOne(new Document(“_id”, orderDetDoc.get(“_id”)), orderBean.createOrder());

This example replaces one existing document with a new one. It is just one line of code to finish.

Now let’s look at the data structure :

{
 “shippedThrough” : “www”,
 “deviceType” : “”,
 “accountId” : “sssssss”,
 “subscriptionId” : [],
 “paymentGateway” : “Zuora”,
 “orderDate” : “Mar 29 2016, 16:55:40.517”,
 “firstName” : “test”,
 “lastName” : “03290950”,
 “workEmail” : “test+test@gmail.com”,
 “monthlySubscription” : “Y”,
 “trackingNumber” : “abababa123naana”,
 “invoiceNumber” : “INV00016945”,
 “shipmentStatus” : “Y”,
 “shippingCarrier” : “USPS”,
 “shippmentDate” : “Dec 05 2016, 10:52:23.074”,
 “productRatePlanId”:””,
 “productRatePlanChargeId”:[“”],
 “invoiceItems” : [ 
 {
 “chargeAmount” : 199.0,
 “serialNumber” : “dddddddddddddddddd”,
 “editQuantity” : “N”,
 “shippedThrough” : “dddddd”,
 “chargeDescription” : “Null”,
 “productName” : “dddddd”,
 “chargeName” : “dddddd”,
 “quantity” : “1”,
 “serviceStartDate” : null,
 “serviceEndDate” : null,
 “taxAmount” : 17.4200000762939
 }
 ],
 “serialNumbers” : [ 
 “ffffffffffff”
 ]
}

The above one line Java code is enough to write. In case of a SQL write operation we need to use minimum 2 tables to save the data. Which is avoided by document 
based database.

Document as a choice of data structure for development : Document is very similar to a Java/Python/Scala/C#/C++ objetcs in many ways. Converting Object data
 type to relational form was a night mare for all application developers. There are many helpers like hibernate/JPA frameworks available in market due to the
 above problem. Even though they were not perfect to solve the above problem they helped a lot. But solution was not up to the standard of object-oriented
 programmers. A database of the same data structure as application is a dream comes true for many developers like me. Creating an array of objects or embed an
 array of ints inside an object is amazing with document based data structure. No need to think how to convert this whole thing while saving or retrieving from
 database. No need to take help of any frameworks to manage the conversion. Omitting an extra layer of coding which reduces lot of code error.

Ex: Let’s look at one read operation in MongoDB. Again this one is also used by mobile applications.

Collection<UserAccessToken> result = new ArrayList<>(); 
MongoCursor<Document> cursor = ConnectionUtil.getInstance().createMongoClientInstance().getCollection(“XXXXXXXX”).find(new Document(“zuoraId”, zuoraId))
 .iterator();
 
From the above 2 lines once you get the cursor, you can convert to any type of your wish. Let’s convert to string and then to UserAccessToken and add to the
 list(result). 
 
while (cursor.hasNext()) {
 result.add(new UserAccessToken((String) cursor.next().get(“cortexId”)));
 }

From the above code it is evident that an application is simple and robust to create in document based database(MongoDB). Overall no need to think of 
 transaction, even though embedded objects are very common. Finally time has come to think in terms of OOPs concept everything we can develop.