L'associazione dei dati in un RDBMS SQL è uno sforzo proficuo?

Ho scoperto che un'attività comune per le applicazioni Web che ho creato è quella di reagire a una modifica dello stato del database. Cioè, qualsiasi interazione dell'utente che influenza lo stato persistente può cambiare le viste che dipendono da quei dati, possibilmente viste per altri client. La sfida è aggiornare immediatamente tutte le viste interessate, che spero possano essere risolte legando le viste ai dati del database.

Preferibilmente, queste dipendenze di visualizzazione sarebbero le più specifiche possibili. Cioè, se consideriamo il livello dell'applicazione come una trasformazione senza stato dei dati del database alle viste, il "set di dipendenze" è il dominio di quella trasformazione e vogliamo che questo sia il più vicino possibile al minimo.

Quali tipi di elementi (ad esempio righe, intervalli di righe, singoli oggetti) dovrebbero costituire i set di dipendenze? Possono essere abbastanza specifici senza essere troppo costosi da controllare?

Pensiero corrente, MySQL

Per affrontare la motivazione e alcune preoccupazioni per il progetto, prendiamo MySQL senza i suoi trigger. (Per semplicità, trattiamo anche le cascate di chiavi estranee come trigger.) Sono fiducioso dell'idea su questa piattaforma da alcune ipotesi:

1. Sembra che possiamo suddividere questo set di comandi MySQL ridotto in comandi puramente leggibili ( SELECT , SHOW ) e comandi di pura scrittura ( UPDATE , DELETE , INSERT , REPLACE , ...). Se ciò è vero, la direzione di influenza può essere determinata unicamente dal tipo di comando.
   • Avvertenza: la funzionalità nel livello applicazione che si basa sul numero di righe interessate da comandi altrimenti puramente scritturali interrompe questa ipotesi.
2. Sembra plausibile che il binding a livello di tabella possa essere perfetto e sia necessario solo l'analisi delle query. Cioè, i comandi puramente scritti possono solo modificare e i comandi puramente letti possono dipendere solo da tabelle menzionate nel comando, e questi nomi di tabelle possono essere identificati in modo univoco e affidabile analizzando da soli.

3. Sembra plausibile anche che il binding a livello di tabella non sia il sistema perfetto più specifico. Detto questo, tutti i sistemi più potenti probabilmente considerano ON e WHERE condizioni. Questo è problematico perché, a meno che le condizioni non coinvolgano la stessa colonna, le intersezioni tra le condizioni dipendono dai dati nella tabella. Quindi, potremmo avere due opzioni: intersecare set corrispondenti di ID univoci o regredire al binding a livello di tabella. Immagino che il primo potrebbe essere molto costoso.

   Potrebbe esserci un po 'più di potere di analizzare da solo con alcune regole più sfumate, come sapere che i comandi non aggregati SELECT non possono essere influenzati da INSERT senza ON DUPLICATE KEY UPDATE .