Question
Wells Fargo
US
Last activity: 22 Sep 2019 1:59 EDT
Split Schema
Split Schema
1) Rules in Rule Schema.
2) Data related in Data Schema.
Is there any reason why Pega want to keep Application related Data in "Data schema" instead in "Rules schema".
Case related data (Ex : Case Data, Attachments, Case History, Assignments) totally make sense to have it in Data schema.
Trying to find out rationale behind of storing Application related data(DSS, Data Tables etc) also in "Data Schema".
Thanks
Chiranjeevi
***Edited by Moderator Marissa to update platform capability tags****
Decision Consultant Solutions
GB
The split schema provides flexibility and better organization of data and rules in the database level
The split schema is optional and you can have all the data in a single schema also.
The split schema is useful for having very less downtime while upgrading to the latest version of Pega platforms.
Apart from these, you can create third schema 'PegaCustomerData' as well which is optional.
It is always recommended to have split schema.
Pegasystems Inc.
IN
Hi,
To achieve High availability & Minimum/No downtime during Pega upgrades or Updates, storing Application related data(DSS, Data Tables etc) also in "Data Schema".
Pegasystems Inc.
US
“Split schema” refers to the idea of classifying the database tables used by PegaRULES into two categories: rules tables and data tables. The primary goal for this is to decrease the amount of time a system must be unavailable during an upgrade. As such, this epic is a key part of the “high availability” goal.
The principle behind this idea is that rules change significantly from one release to the next, whereas data and work transcend releases. During an upgrade, one would install a completely new set of rules tables, while keeping the data tables (essentially) untouched. The system would be up and running during this time. Once the system administrator is ready to “pull the trigger” and start using the new version he can then update the PegaRULES table mappings to point to the new rules schema. This last step would require some downtime; but not as nearly as much as upgrades do today, when the system needs to be down during the whole upgrade process.