A public-service application can respond quickly and still leave a person unable to finish the task. Information may need to arrive from another institution, an application may require a decision, or a staff member may need to resolve an exception. Database performance supports the journey without completing every part of it.
The historical Shenzhen housing provident fund case is useful for this reason. OceanBase’s supplied Chinese case collection connects a database modernization project with changes to online services and information sharing. It offers a starting point for evaluating the whole citizen journey, rather than treating the database as the entire service.
Read the historical case beyond its infrastructure claims
The case collection’s Shenzhen chapter describes an upgraded online service platform using OceanBase. It also describes information sharing with entrusted banks to support online applications and additional self-service channels. These are historical supplier-reported developments, not current instructions for obtaining a housing benefit or loan.
The distinction matters for another agency. A platform can provide a stronger data foundation while service completion still depends on institutional agreements, application rules, and staff work. A database purchase does not automatically establish those arrangements.
Use the case to identify which parts of the service improved together. Avoid attributing every change in channel usage or citizen convenience to the database alone, particularly when the project also changed the surrounding service design.
Define the task from the applicant’s starting point
Begin with a concrete task that a person wants to complete. Describe the information they provide, the result they expect, and the point at which the agency considers its responsibility fulfilled. The definition should be recognizable without knowledge of the database architecture.
For an illustrative online application, distinguish successful submission from acceptance for review and from a final decision. These stages may all be necessary, but they are different outcomes. A page that confirms receipt should not imply that the requested service has already been granted.
This is a service-design example, not a statement of Shenzhen’s current procedures or eligibility rules. The agency’s own authorized process must determine the actual stages, required evidence, and decision rights.
Trace the handoff to other institutions
Information sharing introduces responsibilities beyond storing a record locally. Identify which institution supplies each item, what the receiving service is allowed to conclude from it, and how uncertainty is shown when information is unavailable or inconsistent.
A simple example is a response that has arrived but does not cover the period required for the application. The system should not treat the mere presence of data as completion of the information requirement. Staff need a way to understand what is still missing.
Discuss these situations with the institutional partners before treating an integration as finished. A faster local query cannot resolve a disagreement about what an external response means. The relevant acceptance evidence is a coherent explanation across the service boundary.
Evaluate the database within the service map
OceanBase’s Enterprise product description makes its distributed relational platform relevant to an agency assessing an operational database foundation. The selected deployment still needs to be evaluated against the application’s actual workload and operating requirements.
Place that review inside a wider map.
| Service stage | What needs to be established | Database review contribution |
|---|---|---|
| Submission | The request is recorded with its intended meaning | Examine the application’s persistence behavior |
| External information | Required information is available and suitable | Examine storage and retrieval of the received context |
| Review | Authorized staff can interpret the application | Examine access to the relevant current state |
| Outcome communication | The applicant receives an accurate status | Examine how the application obtains that status |
The table proposes questions for a buyer. It does not certify OceanBase, reproduce Shenzhen’s process, or assign statutory decision powers.
Include the people who handle exceptions
An online service needs a workable path for cases that do not follow the ordinary sequence. Invite the people who investigate these applications into the evaluation. Ask what information they need and what they should tell an applicant while the issue remains unresolved.
Use realistic examples without assuming every exception should be automated. A well-defined staff handoff may be more appropriate than a rule that forces an uncertain case into a completed status. The database should support the agreed process rather than determine the process by accident.
Compare alternative platform arrangements with the same service map. Keeping an existing Oracle or SQL Server system, adopting OceanBase, or considering another relational platform should not change what counts as a completed public service merely to make a technical demonstration pass.
Accept infrastructure and service outcomes separately
The infrastructure team may have evidence that the database meets its agreed requirement while the agency still needs to complete an external-information arrangement. Record both conclusions. Recognizing the remaining dependency is more useful than describing the whole service as finished.
The Shenzhen case shows why database modernization belongs in a broader service conversation. OceanBase can be evaluated as an enabling foundation, while the buyer retains responsibility for partner coordination, application decisions, and the applicant’s understanding of the outcome. That produces a clearer project than treating a faster response as proof of a completed journey.
This article is based on documented sources and editorial analysis. Proposed evaluation examples are not independently measured benchmark results.