MongoDB

In lieu of traditional database frameworks of the SQL family (SQLite, PostgreSQL, SQL, MySQL, et cetera), MongoDB has been chosen as the database of choice. Being a NoSQL database, all operations within MongoDB are put to effect without the underlying presumption of a schema.

While the prospect of not having a schema to organize and categorize data into appropriate containers may seem daunting to the new, there are quite a few advantages incurred as well:

1. Formation and maintenance of highly complex data structures in the form of JSON objects. At the time of writing, MongoDB supports up to hundred levels of nesting within a single JSON object, with size limits of 16 megabytes per individual record. (Average record sizes usually range about 2 - 10 kilobytes).

(Please note that actually going ahead with 100 levels of JSON nesting is usually an indicative of bad application system design, and that higher order complexities are commonly attributed to projects involving big data operations with Hadoop, but all that is out of the scope of this discussion.)

2. Each tuple in a relation can be fine tuned to a great degree of customization, given that no schema restrictions apply.

3. Superior JSON support, thereby making direct one-to-one correspondence between query results and processing operations a reality.

4. Circumvention of the SQL injection vulnerability: As queries are passed as JSON object arguments to function calls, and not as raw strings, SQL injections are avoided completely.

(Some may argue that the NoSQL family of databases is susceptible to NoSQL injections, but handling for such edge cases is certainly a whole lot simpler than those of sanitizing user input for SQL and the like.)

• More here

• Performance benchmarks here

This table provides a lucid correlation between SQL and NoSQL terminologies.

• Tutorials: http://www.tutorialspoint.com/mongodb/index.htm

• References: https://docs.mongodb.org/manual/