Planet NoSQL

DZone published  [ Apr-16-2019] Two score and five years ago, two young IBM researchers brought forth databases; a new language conceived in relational and dedicated to the proposition that data can be manipulated declaratively and easily. In the years since Don Chamberlin and Ramond Boyce published  SQL: A Structured English Query Language , relational models and SQL have been extended and adapted to a significant number of technologies: OLTP, OLAP, object databases, object-relational databases, and even NoSQL. SQL has inspired query language design for non-relational databases: SQL for object databases, SQL for object-relational, SQL for XML, SQL for spatial, SQL for search, SQL for JSON, SQL for timeseries, SQL for streams, and so on. Every BI tool interacts with the data using a variety of SQL. In fact, SQL is the most  successful 4th generation language . “SQL is a device whose mystery is only exceeded by its power.” Lukas Eder As Don said recently, SQL was based on ...

  Couchbase N1QL Transaction: An Elastic and Scalable Distributed Transaction MongoDB to Couchbase: An Introduction to Developers and Experts New N1QL Features in Couchbase 7.0 [Video] NoSQL Is Dead, Long Live NoSQL Halloween Problem: Solution In N1QL Arrays in JSON: Modeling, Querying and Indexing Performance Example Architectures for Data-Intensive Applications First Class SQL for Full Text Search First Class SQL for Full-Text Search Create the Right Index, Get the Right Performance, Part 2 Create the Right Index, Get the Right Performance, Part 1 Analyze This: MongoDB and Couchbase Analytics Example Architectures for Data-Intensive Applications On Par With Window Functions The Unreasonable Effectiveness of SQL in NoSQL Databases: A Comparative... Flexible Query and Indexing for Flexible JSON Model Using N1QL With Couchbase Eventing Functions JSON Is Case Sensitive but You Don't Have to Be Simple DataViz With N1QL and Google Sheets Main Uses for Couchbase Primary Index Less Is Mo...

[This article is reposted from my DZone article: https://dzone.com/articles/join-faster-with-couchbase-index-joins] Good features in query language help you to optimize the data model, save space, and increase performance. Normally, you’d have child table pointing to parent. For example, orders have the document key of the customer. So, starting with orders, you join customers to have the fully joined document which can be processed further.   To get the list of orders by zipcode, you write the following query. SELECT c .C_ZIP , COUNT (o .O_ID ) FROM ORDERS AS o LEFT OUTER JOIN CUSTOMER AS c ON KEYS o .O_CUSTOMER_KEY GROUP BY c .C_ZIP ORDER BY COUNT ( 1 ) desc ; This works like a charm. Let's look at the query plan. We use the primary index on ORDERS to do the full scan.   For each document there, try to find the matching CUSTOMER document by using the ORDERS.O_CUSTOMER_KEY as the docum...