Assume that TBC, the fictional soft drink company upon which the Sample.Basic database is based, started out with a centralized database. As the eastern region grew, however, this solution was no longer feasible. The networks to the eastern region could not handle the large data flow. Users were constantly waiting for data that they needed in order to make decisions. One day, the network went down, and users at the eastern region could not access the data.
Everyone agreed that the eastern region needed to access its own data directly, without going through the company database. In addition, TBC decided to change where budgeting information was stored. The corporate budget stays at company headquarters, but the eastern region budget moves to the eastern region’s database.
So, assume that TBC decided to ask you to partition their large centralized database into two smaller databases—Company and East.
This example is based on the Samppart sample application (which contains the Company database) and the Sampeast sample application (which contains the East database).
Figure 58, Data Flow from Data Source to Data Target shows a subset of the partitioned databases. The arrows indicate flow from the data source to the data target. The Company database is the data source for the Corp_Budget member and the data target for the East and the East Actual members. The East database is the data source for its East and Actual members and the data target for the Corp_Budget member.
To create a partition based on this example:
After the corporate database is partitioned, users and DBAs see the following benefits:
Faster response times, because they are competing with fewer users for the data and they are accessing the data locally
Easier maintenance, because DBAs can control the downtime of their local databases
Access to more data, because users can connect to both the eastern and corporate budgets
Higher-quality data, because the corporate budget and eastern budget are now synchronized—they use the same data.