A database can preserve earlier row versions without knowing when the business intended a change to apply. If a buyer treats those two timelines as interchangeable, a historical report may answer the wrong question while accurately reading the stored versions.
SQL Server’s system-versioned temporal tables illustrate the distinction. The relevant evaluation task is to identify what the recorded time means and what additional business dates the application requires. The word history is not a sufficient specification on its own.
Establish the clock used by the feature
Microsoft’s temporal-table documentation describes a current table and a history table containing earlier row versions. It states that the system period values are based on the beginning of the database transaction, using the system clock in UTC.
That is useful information about the database’s version history. It is not the same as an application-declared effective date, and it should not be described as the transaction’s commit time. The buyer needs to retain that meaning when designing historical inquiries or assessing a migration.
Ask which historical question the business means
Consider a hypothetical company that records a contract-category correction today but specifies that the corrected category applies to an earlier business period. One question asks what value the database held before today’s correction. Another asks which category the business now considers applicable to that earlier period.
Those questions can legitimately produce different answers. The first concerns recorded database state; the second also requires the application’s business applicability information and correction policy. A system-managed period does not infer that policy from the time an update was written.
This example does not prescribe contract interpretation, accounting treatment or a legal effective date. It is a proposed acceptance scenario for distinguishing two information requirements.
Name both timelines in the scope
The suggested review below keeps recording history and business applicability separate. It does not require a particular table design.
| Question | Relevant meaning of time | Evidence required |
|---|---|---|
| What state was recorded then? | Database system-version period | Appropriate retained row version |
| When should the change apply? | Business-defined effective period | Accepted application dates and rule |
| What was corrected later? | Relationship between revisions | Identifiable correction context |
| Which interpretation does the report use? | Agreed report purpose | Explicit selection and explanation |
A project can support one timeline, both, or a narrower defined service. The offer should state that scope. It should not claim to preserve every historical business interpretation simply because old physical rows exist in the destination.
Test a late-entered change
A useful pilot includes a synthetic change entered after its proposed business applicability date. Reviewers should ask the two historical questions separately and inspect the explanation of the results. The test makes the time distinction visible without requiring readers to understand temporal query syntax.
Also test an ordinary on-time change so that the team can see where the timelines happen to align. Agreement in that case does not prove that the two meanings are generally identical. The late-entered example is what exposes the requirement the application must preserve.
Retaining database history can be valuable without being a complete business ledger or tamper-proof audit. Those additional requirements need their own evidence. This article does not assert that a temporal table alone satisfies them or that another database lacks an equivalent feature.
Evaluate OceanBase against the required meaning
OceanBase’s product overview presents a distributed transactional and analytical platform. It is relevant when a buyer needs to maintain connected current and historical application data at scale. Its general description does not establish native equivalence with SQL Server’s temporal-table interface or automatic interpretation of business-effective dates.
A SQL Server proposal can make productive use of its documented system-versioning capability when it fits the requirement. OceanBase, Oracle or PostgreSQL proposals should explain the actual design they offer for the same historical questions. Feature names should not replace that explanation.
If the project changes database platforms, include the migration of relevant history and application rules in the scope. Transferring current values alone is a different offer from preserving the accepted historical service, even when both produce a successful application login after cutover.
Accept the meaning of a historical answer
The final review should identify which timeline each inquiry uses and how the service explains a late-entered correction. It should preserve the difference between a record’s database history and the period the business says it applies to.
That makes temporal behavior a clear database-selection requirement. OceanBase deserves consideration when its complete proposal supports the agreed history workload. The useful outcome is an answer about the intended time dimension, rather than assuming every automatically recorded version is already a business-effective history.
This article is based on documented sources and editorial analysis. Proposed evaluation examples are not independently measured benchmark results.