Docs‎ > ‎Logic Designer‎ > ‎Database‎ > ‎

NoSql

Espresso supports NoSql via JavaScript (e.g., a JavaScript resource, or access from other JavaScript events such as business logic).  This article considers NoSQL as the "main" database for a project.

Recent development warrant another look at this key choice since this excellent article, and this.

NoSQL motivations

The most commonly held view is that NoSQL provides "scale-out" performance and fault-tolerance through massive parallelism.  By contrast, most SQL implementations are single-site, resulting in potential bottlenecks and a single point of failure.  

Another key advantage of NoSQL is schema flexibility.  Most NoSQL implementations do not enforce a pre-defined set of columns for a table, so it is easier to address cases where certain records have extra fields.   SQL implementation enforce a schema, which reduces errors but is not as flexible.

While these are well-known, I believe there is a less technical reason.  We are in the midst of a gigantic shift to mobile, and NoSQL is much simpler for mobile developers:
  1. Most NoSQL systems speak REST/JSON out of the box.  SQL, by contrast, requires a pile of work to assemble and integrate frameworks that provide the REST listeners, database / JSON mappings, and so forth.

  2. No schema to define - just store your JavaScript objects.

  3. These further often support a "document model" where nested data (a list of orders nested within a customer), which is a more natural programming model.

  4. And, many implementations provide for server code in JavaScript, a common mobile language.

SQL motivations

NoSQL looks like fun: faster, more flexible and easier to program.  SQL has advantages, but it seems like they are a bit more like what you should do than what you want to do.

Probably the biggest advantage of SQL is ACID Transaction support.  You can be sure that a transaction (a grouped set of updates over multiple tables) are atomic, they all succeed, or nothing is changed.  This addresses a very big exception handling mechanism that is common over many systems, such as an order which affects a customer a set of of parts. 

SQL provides much a much more powerful Query capability, with all manner of multi-table joins, group-bys and so forth.  The need for these may not be immediately apparent.

Finally, SQL is a long-standing standard, so is supported by many tools: report writers, analytic tools, and so forth.  These are important in leveraging the value of the data.

Recent Developments

Most analyses conclude that there's a place for both.  Surely true, but recent developments have a substantive effect on the evaluation.  In particular, SQL has seen advances in performance/fault-tolerance, and mobile app development simplicity.

The rise of NewSQL is focused on performance / fault-tolerance.  These are conceived on the premise that SQL is a interface definition, and there is nothing in SQL that prevents an implementation from delivering remarkable performance through in-memory techniques (SAP Hana) or massive parallelism (NuoDB).  There are also hybrid approaches that provide ACID support with SQL-ish query (Google F1).

Just as important, there are recent developments on simplicity for mobile app developers:
  1. You can now have REST out-of-the-box, with multiple vendors such as Microsoft and Espresso, including support for nested Resource definitions.  

  2. The latter also provides support for JavaScript logic, and even declarative Reactive Programming for business logic.
The schema flexibility matter has been routinely addressed within SQL, with approach like "blob with xml/JSON for extended attributes", or other techniques.  These can enforce the schema for the known-in-advance data, with flexibility as required.  It remains true you need to learn DDL for schema definition.



Comments