Understanding Documents

    The following table compares terminology used by document databases (MongoDB) with terminology used by SQL databases.

    All documents in a document database are self-describing. This documentation uses JSON-like formatted documents, although you can use other means of encoding.

    A simple document has one or more fields that are all at the same level within the document. In the following example, the fields , LName, FName, DOB, Street, City, State-Province, PostalCode, and Country are all siblings within the document.

    A complex document organizes its data by creating embedded documents within the document. Embedded documents help manage data in groupings and as individual data items, whichever is more efficient in a given case. Using the preceding example, you could embed an Address document in the main document. Doing this results in the following document structure:

    1. {
    2.    "SSN": "123-45-6789",
    3.    "LName": "Rivera",
    4.    "FName": "Martha",
    5.    "DOB": "1992-11-16",
    6.    "Address": 
    7.    {
    8.        "Street": "125 Main St.",
    9.        "City": "Anytown",
    10.        "State-Province": "WA",
    11.        "PostalCode": "98117",
    13.    }
    14. }

    You can now access the data in the document as individual fields ( "SSN": ), as an embedded document ( "Address": ), or as a member of an embedded document ( "Address":{"Street":} ).

    As stated earlier, because each document in a document database is self-describing, the structure of documents within a document database can be different from one another. The following two documents, one for a book and another for a periodical, are different structurally. Yet both of them can be in the same document database.

    The following is a sample book document:

    The following is a sample periodical document with two articles:

    1. {
    2.     "_id" : "0123456789012",
    3.     "Issue": 
    4.     {
    5.         "Volume": "14",
    6.         "Number": "09"
    7.     },
    8.     "Articles" : [ 
    9.         {
    10.             "Title": "Is a Document Database Your Best Solution?",
    11.             "Author": 
    12.             {
    13.                 "LName": "Major",
    14.                 "FName": "Mary" 
    15.             }
    16.         },
    17.         {
    18.             "Title": "Databases for Online Solutions",
    19.             "Author": 
    21.                 "LName": "Stiles",
    22.                 "FName": "John" 
    23.             }
    24.     ],
    25.     "Type": "periodical"
    26. }

    Compare the structure of these two documents. With a relational database, you need either separate “periodical” and “books” tables, or a single table with unused fields, such as “Publication,” “Issue,” “Articles,” and “MI,” as null values. Because document databases are semistructured, with each document defining its own structure, these two documents can coexist in the same document database with no null fields. Document databases are good at dealing with sparse data.

    Developing against a document database enables quick, iterative development. This is because you can change the data structure of a document dynamically, without having to change the schema for the entire collection. Document databases are well suited for agile development and dynamically changing environments.

    Document databases are not normalized; data found in one document can be repeated in another document. Further, some data discrepancies can exist between documents. For example, consider the scenario in which you make a purchase at an online store and all the details of your purchases are stored in a single document. The document might look something like the following JSON document:

    All this information is stored as a document in a transaction collection. Later, you realize that you forgot to purchase one item. So you again log on to the same store and make another purchase, which is also stored as another document in the transaction collection.

    1. {
    2.     "DateTime": "2018-08-15T14:49:00Z",
    3.     "LName" : "Santos",
    4.     "FName" : "Paul",
    5.     "Cart" : [ 
    6.         {
    7.             "ItemId" : "2109876543210",
    8.             "Description" : "Document Databases for Fun and Profit",
    9.             "Price" : "45.95"
    10.         } 
    11.     ],
    12.     "PaymentMethod" : 
    13.     {
    14.         "Issuer" : "Visa",
    15.         "Number" : "0987-6543-2109-8765" 
    16.     },
    18. }

    There is also an apparent discrepancy between the two documents—your credit card information. This is only an apparent discrepancy because it is likely that you used a different credit card for each purchase. Each document is accurate for the transaction that it documents.