Composite Keys for Multi-Tenant Non-Relational Database Objects
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Multi-tenant non-relational database systems lack an efficient method for customers to define and manage composite keys across shared tables, leading to limitations in query capabilities and metadata management, which restricts flexible and scalable data access.
Innovation Solution
The system allows organizations to define composite keys for platform objects within a multi-tenant environment through a script, generating metadata models and writing this information to specific tables, enabling the creation of composite primary and secondary keys that facilitate efficient data retrieval and querying.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If traditional single-tenant database schemas are used, then data security and isolation are maintained, but query flexibility and scalability are limited
Solution Approach 1:
The patent segments the database schema into tenant-specific configurations by allowing each tenant to define custom composite keys on shared tables. This enables query flexibility for individual tenants while maintaining the shared table structure for multi-tenant efficiency.
Solution Approach 2:
The patent introduces dynamic schema configuration where tenants can define and modify composite keys at runtime through scripts. This dynamic approach allows the schema to adapt to different tenant requirements without requiring separate physical tables for each tenant.
2Speed
If separate tables are created for each tenant, then query performance is improved, but system complexity and maintenance burden increase
Solution Approach 1:
The patent merges multiple tenant-specific logical schemas into shared physical tables. By allowing tenants to define composite keys on the same table, the system achieves query performance similar to separate tables while maintaining the benefits of shared infrastructure and reduced complexity.
Solution Approach 2:
The patent creates universal shared tables that serve multiple tenants simultaneously. Each table is designed to handle queries from multiple tenants through composite key definitions, making the table multi-functional and eliminating the need for tenant-specific table copies.
3Adaptability or versatility
If composite keys are not supported, then system simplicity is maintained, but metadata management capabilities are insufficient
Solution Approach 1:
The patent introduces a metadata layer that acts as an intermediary between the application and the underlying database. This metadata layer stores composite key definitions and configurations, enabling sophisticated metadata management while keeping the implementation details abstracted away from users.
Solution Approach 2:
The patent enables tenants to self-define their composite keys through scripts and configuration files. This self-service approach allows tenants to manage their own metadata requirements without requiring complex system-wide changes or administrator intervention for each configuration.
4Productivity
If dynamic schema configuration is enabled, then tenant-specific query optimization is achieved, but provisioning time and setup complexity increase
Solution Approach 1:
The patent allows composite key configurations to be defined in advance through scripts during tenant onboarding. By preparing the schema configuration beforehand, the system can quickly provision new tenants without requiring complex runtime setup, thus reducing provisioning time while maintaining query optimization capabilities.
Data Source
AI summary
Disclosed are examples of systems, apparatus, methods and computer program products for providing a web application builder framework in a database system. A database system maintains a multi-tenant non-relational database associated with a number of enterprises, a number of records, and a number of data objects for each of the enterprises. A dynamic virtual table is maintained as well, associated with the number of records and number of data objects. A user request is received to define a composite key for a data object. A metadata model is generated representing the data object, and a data definition script is generated. The dynamic virtual table is updated to include one or more virtual columns corresponding to the data definition script, and one or more columns of a shared table in the non-relational database are updated to match the virtual columns.