Gestione delle modifiche allo stato coerente nel DB tramite API

Una versione semplificata del mio DB:

Appointment
    id INT PK
    datetime DATETIME

AppointmentChangeRequest
    id INT PK
    user_id INT FK
    appointment_id INT FK
    request_datetime DATETIME
    accepted BOOL NULL

Che è essenzialmente appuntamenti con DATETIME e richiede di modificare un appuntamento con un nuovo DATETIME insieme ad alcune chiavi esterne.

Il mio sistema può modificare Appointment s dagli eventi interni. Gli utenti esterni possono creare AppointmentChangeRequest s che verranno quindi elaborati dal mio sistema e accettati o rifiutati, con una modifica successiva a Appointment che aggiorna datetime .

Sia gli eventi interni che quelli esterni passano attraverso un'API. L'elaborazione di un AppointmentChangeRequest al momento fa sia un PUT AppointmentChangeRequest che un PATCH Appointment , il che significa che c'è un intervallo in cui hai una richiesta di modifica approvata, ma un appuntamento non aggiornato.

Ora arriva il problema con il mio progetto iniziale: voglio essere in grado di sapere se un Appointment ha un certo valore datetime come conseguenza diretta di un AppointmentChangeRequest in fase di approvazione o negato.

I miei pensieri finora:

1. Penso di poter eseguire l'elaborazione di AppointmentChangeRequest atomic, che almeno colma il divario in cui l'appuntamento e la richiesta "non sono d'accordo". Rendi le due richieste API in una sola.
2. Sto pensando di aggiungere forse request_id INT FK NULL a Appointment in modo che quando l'appuntamento viene aggiornato attraverso un AppointmentChangeRequest abbia una chiave esterna request_id , e altrimenti è NULL .

La parte che mi sembra un po 'strana è che finirò per avere una colonna FK che spesso finirà per essere NULL , e mi farà anche fare un aggiornamento di Appointment anche quando la richiesta è negato, che in precedenza era solo un PUT , ma non PATCH .

A un certo punto speravo di fare una sorta di "confronto tra i dati", tuttavia se gli eventi interni conducono al datetime che va via, ma poi tornano allo stesso identico punto, sarà impreciso.