L'unica soluzione supportata sia da MySQL che da HSQLDB consiste nell'interrogare le righe che si intende sostituire e, in modo condizionale, INSERT o UPDATE. Ciò significa che devi scrivere più codice dell'applicazione per compensare le differenze tra le implementazioni RDBMS.
- INIZIA LA TRANSAZIONE.
- SELEZIONA... PER AGGIORNARE.
- Se SELECT trova righe, UPDATE.
- Altrimenti, INSERIRE.
- IMPEGNA.
MySQL non supporta l'istruzione ANSI SQL MERGE. Supporta REPLACE e INSERT...ON DUPLICATE KEY UPDATE. Vedi la mia risposta a " INSERT IGNORE" vs "INSERT... ON DUPLICATE KEY UPDATE" per saperne di più.
Re commenti:Sì, un altro approccio consiste nel provare INSERT e vedere se ha successo. In caso contrario, eseguire un AGGIORNAMENTO. Se si tenta di INSERT e viene visualizzata una chiave duplicata, verrà generato un errore, che si trasforma in un'eccezione in alcune interfacce client. Lo svantaggio di farlo in MySQL è che genera un nuovo ID di incremento automatico anche se INSERT fallisce. Quindi finisci con le lacune. So che le lacune nella sequenza di incremento automatico non sono di solito qualcosa di cui preoccuparsi, ma l'anno scorso ho aiutato un cliente che aveva gap di 1000-1500 tra gli inserti di successo a causa di questo effetto, e il risultato è stato che hanno esaurito la gamma di un INT nella loro chiave primaria.
Come dice @baraky, si potrebbe invece tentare prima l'AGGIORNAMENTO e, se ciò influisce su zero righe, eseguire invece INSERT. Il mio commento su questa strategia è che l'AGGIORNAMENTO di zero righe non è un'eccezione:dovrai controllare il "numero di righe interessate" dopo l'AGGIORNAMENTO per sapere se "è riuscito" o meno.
Ma interrogare il numero di righe interessate riporta al problema originale:devi utilizzare query diverse in MySQL rispetto a HSQLDB.
HSQLDB:
CALL DIAGNOSTICS(ROW_COUNT);
MySQL:
SELECT ROW_COUNT();
