Multi-tenant Master Data Persistence via Shared Tables
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
In multi-tenant software delivery architectures, maintaining organization-specific master data in a centralized database structure becomes cumbersome and costly due to the need for customized field identifiers and database maintenance, especially during lifecycle events like updates and tenant migrations.
Innovation Solution
Implementing a system where organization-specific master data is stored in tenant-nonspecific database tables with predefined generic fields, allowing for efficient management and automation of lifecycle tasks, reducing the need for manual reconfiguration and minimizing errors during system changes.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If organization-specific master data is stored in customized database tables with unique field identifiers for each tenant, then data customization and tenant isolation are improved, but device complexity and maintenance difficulty increase
Solution Approach 1:
The patent applies universality by creating a single shared master data table structure that serves all tenants through common field identifiers. Instead of maintaining separate customized tables for each tenant, the system uses one universal table design that can accommodate organization-specific data through tenant identification fields, thereby reducing overall system complexity while preserving customization capabilities.
Solution Approach 2:
The patent segments the data storage approach by separating tenant identification information from the master data structure itself. Tenant-specific identification is handled through dedicated fields (such as tenant_id or organization_id) within the shared table, while the actual master data fields remain standardized and reusable across all tenants, achieving both customization and simplicity.
2Manufacturing precision
If manual reconfiguration is performed for each tenant during system updates, then tenant-specific configuration accuracy is improved, but loss of time and operational efficiency decrease
Solution Approach 1:
The patent implements self-service by designing the shared master data table structure to automatically accommodate tenant-specific requirements through standardized fields. The system self-adapts to different tenants without requiring manual reconfiguration, as the universal structure inherently supports multiple organizations through tenant identification mechanisms, thereby reducing time consumption while maintaining accuracy.
Solution Approach 2:
The patent applies preliminary action by pre-designing the master data table with standardized fields that can accommodate any tenant's specific requirements from the outset. This preliminary structuring eliminates the need for manual reconfiguration during updates, as the table structure is already prepared to handle diverse tenant data through consistent field identifiers and tenant identification fields.
3Device complexity
If a centralized shared master data table is used for all tenants, then device complexity and maintenance cost are reduced, but data integrity and tenant isolation challenges increase
Solution Approach 1:
The patent introduces an intermediary approach by incorporating tenant identification fields as mediators within the shared master data table. These fields (such as tenant_id, organization_id, or customer_code) act as separators that logically isolate data for different tenants while maintaining physical storage in a single table, thereby preserving data integrity and tenant isolation without increasing structural complexity.
Solution Approach 2:
The patent applies local quality by allowing different portions of the same table to have different effective meanings based on tenant context. While the table structure remains uniform, the interpretation and usage of data fields vary by tenant, with each tenant's data subset maintaining its specific quality and characteristics while being stored in the shared structure.
4Adaptability or versatility
If customized field identifiers are created for each tenant, then tenant-specific data requirements are met, but ease of operation and automation capability decrease
Solution Approach 1:
The patent applies universality by creating a single shared master data table structure that serves all tenants through common field identifiers. Instead of maintaining separate customized tables for each tenant, the system uses one universal table design that can accommodate organization-specific data through tenant identification fields, thereby reducing overall system complexity while preserving customization capabilities.
Data Source
AI summary
A first tenant-nonspecific database table on a repository accessible to an application server of a multi-tenant software delivery architecture can maintain a first record designating a first predefined generic field of a plurality of predefined generic fields. The first record can include an organization-specific master data field definition of the first predefined generic field maintained in a first tenant-specific definition field assigned to a first customer tenant of a plurality of customer tenants that are accessible via the application server. Each customer tenant of the plurality of customer tenants can provide a discrete organization-specific business configuration of a core software platform. A second tenant-nonspecific database table maintained on the repository can maintain a second record that can include a key value designating the first tenant, a record designator, and an organization-specific master data value corresponding to the first predefined generic field. A calculation or determination based on master data can be performed that is relevant to the discrete organization-specific business configuration provided by the first customer tenant using the organization-specific master data value.