Database Joins for NoSQL

Normalized data models are great

Why don’t NoSQL databases natively support normalized models?

What really matters to a business application:

1. Net Operation Time (N.O.T.): The total time it takes to do a complete application operation (retrieve data from all documents, perform any calculations and write all mutations). From the application’s and user’s perspective, N.O.T. is the latency of the whole operation, not just a single database interaction in an overall business operation.
2. Data integrity/consistency/reliability: The data service is always there. Any data mutations are accurate. Reads are globally consistent. Bonus points for platforms that offer native multi-line transactions and server side functions.
3. Cost: TCO of the full impact of the database. When all of the features, cost multipliers, data copies, table rebuilds and developer-forced complexities are accounted for.
4. Model optionality: This affects time-to-delivery (how long it takes to start up, how long it takes to make changes, etc), effort (time to create models that work both for the application and the database) as well as risk (removing inconsistencies, rebuilding collections to apply new requirements, etc).
5. Security: Role and attribute based permissions are more targeted and provide more comprehensive access control by normalizing (isolating) data and using joins to dynamically retrieve only the required elements, not whole documents,.

Database joins are amazing!

1. Net Operation Time (N.O.T.) can be dramatically reduced by grabbing all data needed in a single interaction. This requires either joins or server-side functions. While Fauna has both, joins are the dynamic, simple and flexible means for gathering data from more than one document/collection.
2. Net data sizes of reads are reduced leading to faster and cheaper operations. Bring back only the data needed, in one query.
3. Application code can be simplified.
4. Queries can be dynamic and flexible.
5. Allow for index optimization. Index just entry points and connecting keys to reduce the size, complexity and costs of accelerating access patterns.

Fauna brings back database joins

1. Optimized document storage. By separating the compute layers of the engine from the data storage layer as well as making every storage call extremely fast, Fauna’s engine traverses multiple documents in one query with blazing speed. Like a relational database, push down a single query and skip the network latency of multiple interactions.
2. Native reference traversing. Fauna’s engine will take the data elements requested in the query and auto-traverse from document to document resolving reference IDs. Like a relational database, use a single query interaction to simplify data access.

Order.byId(83024) {
  total,
  customer {
    name
  },
  details {
    qty,
    price,
    product {
      name
      shippingWeight
    }
  }
  billingAddress
}

Common patterns for joins

1. Volatility: How often data will change. Either an element of an object or an item in an array, how they change can affect whether they’re better stored in isolation (normalized) or embedded. Embedding is great for items that rarely change or lists that do not grow that large. But for large and growing lists (like order history) or frequently changing items (like order shipping status), normalizing allows for both write and read optimization.
2. Access patterns: Who, when, and how data will be accessed can also significantly influence the optimal models for data storage. Multiple services may need the same data (like customers and shipping companies needing access to order details) but require different return sets for optimization of interactions and security/permissions. Normalizing the data model and joins allow for fine grained access control, efficient data transfer, optimized indexes, and flexible access patterns.

Summary