Multi-Tenant NoSQL Schema Updates via Dynamic Virtual Tables

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Non-relational database systems face challenges in efficiently managing schema updates without causing downtime, especially in multi-tenant environments where organizations need to add or remove fields and objects dynamically, as existing methods require significant interruptions and updates.

Innovation Solution

Implementing base platform objects (BPOs) defined in scripting languages like XML, which allow for dynamic virtual databases with shared schemas, enabling updates at the application layer without altering the physical database structure, allowing organizations to create custom objects and manage access rights efficiently.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If schema updates are performed in traditional non-relational databases, then data structure changes can be made, but significant downtime and interruptions occur

Engineering Contradiction:
Improveschema flexibilityVSAvoiddowntime
Core Design Contradiction:
Adaptability or versatilityVSLoss of time

Solution Approach 1:

The patent segments the database schema into multiple independent tables, where each table represents a specific data object. This allows individual tables to be updated, added, or removed without affecting the entire database schema, enabling schema changes without system-wide downtime.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The patent implements dynamic schema management where the database structure can be modified at runtime. New fields and objects can be added dynamically through application-layer operations, allowing the schema to adapt to changing requirements without requiring system interruptions or downtime.

Inventive Principle:
Principle #15Dynamics

2Adaptability or versatility

If multi-tenant environments allow dynamic addition of fields and objects, then organizational customization is enabled, but system complexity increases

Engineering Contradiction:
Improveorganizational customizationVSAvoidsystem complexity
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The patent divides the multi-tenant database into separate tables for each organizational unit or tenant. Each tenant can have customized fields and objects within their designated table structure, while the overall system maintains a manageable segmented architecture that prevents complexity from scaling linearly with customization options.

Inventive Principle:
Principle #1Segmentation

3Adaptability or versatility

If physical database structure is altered for schema updates, then data structure changes are achieved, but application interruptions occur

Engineering Contradiction:
Improveschema update capabilityVSAvoidapplication continuity
Core Design Contradiction:
Adaptability or versatilityVSProductivity

Solution Approach 1:

The patent introduces an application-layer intermediary that handles schema updates without requiring physical database structure alterations. The application layer acts as a mediator that can add, remove, or modify fields and objects by updating application logic and metadata, while the underlying physical database structure remains stable and uninterrupted.

Inventive Principle:
Principle #24Intermediary (Mediator)

Data Source

PatentEP3519991B1Multi-tenant non-relational platform objects
Publication Date: 2026.04.01 SALESFORCE INC
  • EP3519991B1 patent drawingFigure 1
  • EP3519991B1 patent drawingFigure 2
  • EP3519991B1 patent drawingFigure 3

AI summary

Disclosed are examples of systems, apparatus, methods and computer program products for updating and managing multi-tenant non-relational database schemas. A database system maintains a multi-tenant non-relational database associated with multiple enterprises. A number of records are stored for each of the enterprises. The system also maintains a dynamic virtual table storing a number of records. A request is received from a user of the database system to define a data object within the database system. The request is processed, and an object script is generated based on the request, the object script defining one or more database columns in the database system that are associated with the data object. The dynamic virtual table is updated such that one or more virtual columns match the database column definitions in the object script. Existing columns of a shared table in the multi-tenant non-relational database are then updated to match the virtual columns in the dynamic virtual table.