MongoDB vs SQL

[Gaurav Singh Tomar]

I am starting this post to start a discussion on whether a relational database like SQL or a non-relational database like MongoDB will be an ideal choice for DiscourseDB. 

To make this choice, first question which needs to be answered is whether our data is completely relational or not. As data will be coming from several online learning environments, we cannot assume all the data having same fields/attributes/properties. That’s where NoSQL comes into picture, in particular MongoDB. When your data is not relational there can be major benefits to using NoSQL databases like performance and scalability.

Second question which needs to be answered is whether we want want writing data to be easier or reading data to be easier. MongoDB makes reading data really easy and fast (complicated SQL query that joins and aggregates a bunch of data on the fly vs. fetching a single json document from mongo database), but can make writing data quite complicated.

In MongoDB, your data is the schema and there is symmetry between the way data goes into the database and the way it comes out. With traditional technologies, the differences between what it means to put data in and take data out increase as applications get more complex. Below is an example showing how a complicated sql schema can be represented into a simple mongodb json.

[oliver....@gmail.com]

I can see the advantages of nosql in terms of an easier mapping between structure and data. However, I think that at least the macro discourse structure represented in DiscourseDB is inherently relational, so I am not sure if a representation in nosql would be the ideal choice. As far as I know this is also the reason why MOOC providers employ a combination of nosql and sql in their backend, because they still need a relational representation in parts of their data storage. 

MOOCdb, an effort related to DiscourseDB that focuses more on the non-textual interaction and clickstreams data, actually translates this mixed format back (e.g. from edX) into a uniform SQL representation.

I could see a non-relational representation on the side of the micro structure while keeping the macro structure relational. But then we would still need to bring both sides together in the end to allow queries over DiscourseDB as a whole (macro and micro).

In another thread, there was also a suggestion to employ RDF for the micro structure.