What are the challenges, or features that you look for. For instance: Offline sync feature Read/write speed Data types Security
And so on.
I couldn’t find any relevant guide for developers, so I’m researching to write one.
My reasons had to do with document integrity and database complexity. The short of it is I found SQL to be an awful approach to store and manage documents. Instead I used a simple flat file database for each user.
Another important reason I didn't use SQL after reviewing it is that I felt that designing, implementing, and securing a SQL database that could handle the aspects of document creation and management and user management required a dedicated professional who's made that a career choice and I couldn't learn all that was necessary and create the app too. It would take years to become that proficient with SQL alone.
Two years ago I finally moved over to a NoSQL database, specifically CouchDB/PouchDB, because those offer Offline data storage, sync features, Read/write speed, and Security.
CouchDB is designed specifically for Documents and addresses all the issues I found with using SQL databases for document management, and it's built specifically for use with web apps. From the CouchDB docs:
"it embraces the natural idea of evolving, self-contained documents as the very core of its data model" (http://docs.couchdb.org/en/2.1.1/intro/why.html#a-better-fit...)
For your paper, I would start by looking into available database options to see what they say their products are best at doing.
My experience is that SQL users tend to avoid NoSQL because it requires a very different way of doing things that they feel they can do just fine with SQL. They're probably right, but for those just starting to learn about databases NoSQL may be the best choice.
Since I never got in the SQL boat my first look at CouchDB left me feeling like they designed and built exactly what I needed and moving over to it was incredibly easy for me.
I'm a desktop developer. Either the DB comes from one of our supplier (we have Oracle, Sql Server and MySQL) or I'm building an application from scratch and I'll choose Postgres.
I standardized on Postgres more than 10 years ago because it was free and at the time it felt better built than MySQL.
I never encountered a use case where NoSQL would have been a rational choice (take this with a grain of salt since I don't have to scale).