You're basically writing a compiler, which translates from SQL to whatever your datastore understands. In the end, you'll probably have the following parts:
- a Parser which takes SQL and produces an Abstract Syntax Tree
- a bunch of Visitors which do semantic analysis and/or rewriting on the AST
- an Interpreter which finally executes the (processed) query against the datastore
- a REPL which reads input and formats output
But before you even start implementation, you should consider that SQL is defined on relations (tables), which are fundamentally unlike document collections. First, each row in a table has the same columns as all other rows in that table, and nothing else. Second, each row is a flat tuple, while a document is a tree.
If I were you, I'd first solve this mapping problem by taking something like PostgreSQL, defining the tables you expect to have, and then solving how to map your data into said tables (by actually doing it). You can use the result as a prototype for whomever wishes to have SQL, it will give you some ideas on how to implement the compiler, because semantics will be known, and you will have a solid reference for testing/verification purposes.
You may also end up deciding that copying data to an actual RDBMS is good enough; SQL queries are a fairly complex thing to implement efficiently, with joins, subqueries, aggregation, projections and whatnot.. It is even more difficult if you have to do it "from outside" of data store..
