In recent times, NoSQL databases have become a hot topic and have gained a crowd of advocates. Indeed, when NoSQL database started to arise, SQL-to-NoSQL converters arose with them as well. But unfortunately, thanks to the code conversion possibility, SQL supporters gained unquestionable evidence that in many cases the good, old SQL is much easier to use. Especially when it comes to queries.
I performed a quick Google search and found plenty of nice converter tools. Here is one of them:
QUERYMONGO is a tool that converts MySQL queries to MongoDB syntax. In the box where you enter the MySQL query, the tool provides a nice example with group by and some other SQL functions. Even for those who are not familiar with SQL code, the syntax is still obvious and readable.
Since I was curious about what the MongoDB syntax looks like, I willingly pressed the button.
What I saw immediately froze me to the bones. My nice and pleasant SQL was changed into a real monster. The old, simple SQL was replaced by bigger, more complicated, and difficult to read NoSQL statements.
Looking at the SQL, I knew what the query was doing. In Mongo … you really need to read the code carefully. Am I the only one who is uncomfortable with that?
Certainly, some basic queries aren’t very painful to write, but what about a complex query?
Querying with a basic select statement in Mongo takes this much code:
And performing more complex queries, like the one provided earlier, quickly make you feel lost.
The first aim of a query language should be ease of use and readability. With Mongo, having to type all those extra characters quotes, brackets, square brackets, and colons, writing queries becomes tiresome and very annoying. Sometimes you need to type a lot to get any sort of reasonable output, whereas SQL would only require a few simple lines and would look much friendlier.
I want to point out that for sure there are developers who actually prefer Mongo’s query language to SQL because it makes more sense to their brain – “push operand, push values.”
I’ve done my homework and was trying to get familiar with numerous advantages of non relational databases.
MongoDB is a document-oriented database. How does it differ from a table-based technology, such as PostgreSQL?
Many preach impressive advantages to Mongo such as:
- it is schemaless (The documents stored in the database can have various sets of fields, with different types for each field.)
- it has no server-side joins, only client side (doing joins server-side becomes very hard to scale in huge environments) which is one of the most important difference between MongoDB and SQL-based technology.
- MongoDB’s built-in sharding support is one of its most touted features
Returning to query language, MongoDB queries are represented as a JSON-like structure. JSON is a lightweight, data-interchange format. It is easy to parse and generate, which is probably a reason why MongoDB adopted it at the expense of readability. If having readable, easy to understand queries is important, you should pick a SQL database.
Should MongoDB Use SQL as a Query Language?
The MongoDB blog states: “Given the document-oriented nature of the storage, if we were to do SQL, it really world be a variant, not true SQL. There would be no joins, and we would need extensions to handle the nested constructs involved in JSON storage elegantly. The extensions wouldn’t be that much but we would need something like the current MongoDB dot notation to reach into objects.”
So, using JSON as a way of representing queries is a good solution? Why hasn’t Mongo provided a better way to generate queries?
How did QUERYMONGO come into being?
QUERYMONGO may be considered a learning tool.
Using QUERYMONGO to design a relational database and then generate some Mongo queries isn’t a good practise and could lead to much pain and suffering. What’s more, the tool is unable to parse an expression of type subquery and has limited support for complex WHERE clauses including embedded parentheses.
After some research, I can assume that via QUERYMONGO, many developers start to consider MongoDB as a connection between MySQL and NoSQL. The idea of the automated conversion seems to reinforce the idea of MySQL as a MongoDB extension. It’s a totally different database and doesn’t do well with highly-normalized relational-style data!