herodotus_histories_book_chapter_section. The API would route the request into the appropriate query, for maximum speed. Not for this first or second or even perhaps third iteration, but could solve speed issues if mongo won't scale
One of the big reasons that people are interested in JSON support in databases is that they want to use fewer types of databases. The modern technology stack is beginning to introduce significant sprawl as people use different databases in particular areas, taking advantage of their strengths to gain efficiency. However, this polyglot persistence increases the technology surface area enough that it can become quite difficult to monitor, manage, develop, and operate such a diverse set of databases.
One potential answer to this problem is to continue using work horses such as MySQL and Postgres, replacing specialized JSON native databases with the new JSON functionality. For the record, MongoDB is not the only JSON native database. There are many databases, including RethinkDB, that deal with JSON natively.
A big difference between the JSON support in MySQL, Postgres, and MongoDB is that in MongoDB, this is the native transport across the wire as well. JSON is native end to end in this database, whereas in other databases it is typically shoehorned into row and column storage in the client and on the wire, as well as the programming API.
Still, keeping technology diversity down can be a big enough reason to continue using the reliable and trusted databases of yore.```
\nwhen it occurs w/in a chapter (ie, this can happen for a very long chapter that some editor decided to break into two to improve reading.)