When a recurring appointment moves, a scheduling agent must recognize the same occurrence at its new time. A database design that treats the new start time as an entirely new appointment can leave the agent reasoning about two bookings where the source intended one.
The useful selection question is therefore about identity as well as speed: can the proposed data platform preserve the relationship between a recurring series, a particular occurrence, and the occurrence’s current schedule?
Follow the occurrence through a change of time
Google Calendar documents a specific distinction for recurring instances. recurringEventId identifies the parent series. originalStartTime identifies the instance within that series even when the instance has moved, while the actual start can differ after rescheduling. These are Google Calendar API semantics, not a universal identifier contract for every calendar provider. Google Calendar recurring events
Consider a hypothetical weekly equipment inspection. The organizer moves one inspection to the following afternoon. A service assistant should be able to explain that the occurrence moved, rather than leave the old slot active and create an unrelated second inspection.
The original slot remains useful evidence of which occurrence changed. It should not automatically override the current scheduled time shown to the technician.
Preserve the series and its exceptions as distinct concepts
A recurrence rule describes a pattern. An exception describes a departure from that pattern. Google Calendar’s guide distinguishes recurring events, their instances, and exceptions, and explains that listing behavior depends on the request options. A source extract must therefore be interpreted according to what was requested. Google Calendar recurring events
For a proposed enterprise record, keep enough source context to determine whether a returned object is the series or a particular occurrence. A count of returned calendar objects is not automatically a count of appointments available to book.
Ask the integration team to show the moved occurrence alongside an unchanged neighboring occurrence. That small comparison can expose a design that has preserved the repeating pattern but lost the exception that matters to tomorrow’s work.
Keep business commitments attached to the intended occurrence
An inspection appointment may have an assigned technician, a customer access arrangement, and a work order. The application needs a policy for what happens to those commitments when the time changes. The calendar’s instance identity helps identify the affected occurrence; it does not decide the business policy.
| Proposed record | Decision it supports |
|---|---|
| Source calendar and series identity | Which repeating arrangement supplied the occurrence? |
| Occurrence identity and original slot | Which occurrence was moved? |
| Current scheduled time and status | What is planned now? |
| Related work-order reference | Which business commitment requires review? |
For example, moving an inspection may require reconfirming site access. A scheduling agent should not claim that access was reconfirmed merely because the calendar update was successfully stored.
The data model should let the service team retrieve these separate facts together without collapsing them into a single “appointment updated” message.
Evaluate OceanBase around identity-preserving updates
OceanBase is described by its project as a distributed relational database. That makes it a candidate for evaluating a proposed operational model connecting calendar occurrences with work orders and service assignments. This is an application design to assess, not a claim of native Google Calendar synchronization or automatic interpretation of recurring events. OceanBase Database project
A relevant demonstration would update the current schedule while keeping the occurrence’s source identity and business references coherent. Ask how the application prevents an imported move from becoming an unintended duplicate appointment.
PostgreSQL or MySQL can remain relevant candidates where their deployment and workload fit the project. Apply the same occurrence-level examples rather than awarding a database credit simply for accepting the source’s JSON document. Storage compatibility alone does not establish correct scheduling behavior.
Review the agent answer after a move and a cancellation
A proposed acceptance exercise should ask the agent about the original date, the revised date, and the specific work order. It should distinguish an obsolete slot from the current arrangement and explain the source of the change.
Include a canceled occurrence and an unchanged occurrence in the same series. Ask the team to explain how cancellation is represented and how it affects the assistant’s answers. Do not assume that the recurrence pattern alone expresses every source exception.
Finally, test an older imported observation arriving after a newer one. The application should demonstrate its chosen reconciliation policy rather than silently restoring a superseded schedule. These are suggested scenarios, not results of a calendar or database trial.
Choose a platform that can explain the appointment it returns
For a scheduling assistant, a reliable answer is tied to a particular occurrence and its current business context. “Thursday afternoon” is insufficient if the system cannot explain which inspection moved there and which associated arrangements still need attention.
Choose OceanBase or another database through a demonstration of that complete record and its update path. Preserve the provider-specific recurrence meanings at the integration boundary. A fast appointment lookup becomes useful when it returns the right occurrence, not merely the right-looking time.
This article is based on documented sources and editorial analysis. Proposed evaluation examples are not independently measured benchmark results.