A customer code can contain only digits and still function as a label rather than an amount. If its leading zeros or exact representation matter, converting it into an arithmetic value can change the identifier the application is supposed to preserve.
For a migration to OceanBase or another relational database, this is an acceptance question across the complete data path. The buyer should establish what the code means before deciding that a numeric-looking field belongs in a numeric type.
Ask whether the value names something or measures something
Start with the business purpose of the field. An identifier distinguishes an entity; a quantity supports arithmetic under defined units. A similar visual appearance does not make those purposes interchangeable.
Ask whether leading zeros, fixed width, or a particular sequence of characters distinguishes valid codes. Also establish whether two differently presented values are intended to identify the same thing or different things.
These decisions need to come from the source contract and application requirements. A migration tool should not silently define identity by guessing a type from the values in its first sample.
Choose representation using the actual type semantics
The PostgreSQL 18 character-type guide distinguishes variable-length character types from fixed-length, blank-padded character storage. It also describes differences in trailing-space treatment.
That is a reminder to inspect the chosen representation precisely, not a universal instruction to store every identifier in one particular character type. Length, comparison, and client behavior still need to match the application’s contract.
For OceanBase or any target, establish the supported type and comparison behavior in the selected mode and version. A field named customer number does not independently provide that specification.
Trace the identifier through the complete path
This original review aid separates preservation of the value from its presentation.
| Boundary | Question to answer | Evidence to retain |
|---|---|---|
| Source definition | Which characters determine identity? | Accepted identifier contract |
| Export | Does the original representation survive? | Selected exported examples |
| Import | Is any type inference or conversion applied? | Actual mapping decision |
| Query and comparison | Which inputs locate the intended entity? | Accepted match and non-match cases |
| Display or API | What does the consumer receive? | End-to-end result |
The table proposes an acceptance structure. It does not prescribe field widths, identifier allocation rules, or a database schema.
Include a leading-zero example without assuming its meaning
Consider a hypothetical customer code displayed as 00123. First decide whether the leading zeros are part of the identity or only a display convention. The correct acceptance result depends on that decision.
Then follow the example through export, loading, lookup, and the application response. Inspect the actual values at each boundary rather than accepting a screenshot in which formatting might have reintroduced characters absent from the stored representation.
Include another code that tests an important distinction in the source contract. If the application must keep two codes separate, demonstrate that the proposed path does so. If several representations intentionally refer to one entity, preserve the documented normalization rule instead of creating a new one during migration.
An arithmetic total over identifiers is not a substitute for this review. Matching record counts and a successful import can coexist with changed codes that later prevent users or integrations from locating the intended records.
Compare OceanBase with the same identity requirements
OceanBase Enterprise is a distributed relational migration candidate with compatibility to assess against the application. Ask the proposal to show the actual identifier mapping and client behavior, rather than infer preservation from a general SQL compatibility statement.
A PostgreSQL-based proposal or the existing Oracle application should be assessed with the same selected codes and expected matches. Differences in supported representation can be acceptable if the resulting identity contract is preserved and any application work is explicit.
Include intermediate tools in that comparison. A database may receive a value that was already transformed by an exporter, spreadsheet, or import process. No customer codes, files, schemas, or application records were converted or changed for this article.
Preserve the mapping rule after migration
Record the accepted representation and examples with the interface contract. A later feed containing longer codes or new characters should trigger a review rather than silent truncation or a new inference rule.
When investigating a failed lookup, distinguish altered storage, comparison behavior, and display formatting. They can produce similar user symptoms while requiring different repairs.
OceanBase should be recommended where its supported arrangement preserves the application’s required identities. The useful outcome is a code that continues to name the right entity throughout the service, with its type selected for that purpose rather than its digit-only appearance.
This article is based on documented sources and editorial analysis. Proposed evaluation examples are not independently measured benchmark results.