De enige oplossing die door zowel MySQL als HSQLDB wordt ondersteund, is het opvragen van de rijen die u wilt vervangen, en voorwaardelijk INSERT of UPDATE. Dit betekent dat u meer applicatiecode moet schrijven om de verschillen tussen RDBMS-implementaties te compenseren.
- BEGIN TRANSACTIE.
- SELECTEER ... VOOR UPDATE.
- Als de SELECT rijen vindt, dan UPDATE.
- Anders, INSERT.
- COMMIT.
MySQL ondersteunt de ANSI SQL MERGE-instructie niet. Het ondersteunt REPLACE en INSERT...ON DUPLICATE KEY UPDATE. Zie mijn antwoord op " INSERT IGNORE" vs "INSERT ... ON DUPLICATE KEY UPDATE" voor meer hierover.
Re opmerkingen:Ja, een andere benadering is om gewoon de INSERT te proberen en te kijken of het lukt. Doe anders een UPDATE. Als u de INSERT probeert en deze een dubbele sleutel raakt, genereert deze een fout, die in sommige clientinterfaces een uitzondering wordt. Het nadeel van dit te doen in MySQL is dat het een nieuwe auto-increment ID genereert, zelfs als de INSERT mislukt. Je krijgt dus gaten. Ik weet dat hiaten in de automatische ophogingsvolgorde normaal gesproken niet iets zijn om je zorgen over te maken, maar ik heb vorig jaar een klant geholpen die vanwege dit effect een gat van 1000-1500 had tussen succesvolle inserts, en het resultaat was dat ze het bereik van een INT in hun primaire sleutel.
Zoals @baraky zegt, zou men in plaats daarvan eerst de UPDATE kunnen proberen, en als dat nul rijen beïnvloedt, doe dan de INSERT. Mijn opmerking over deze strategie is dat het bijwerken van nul rijen geen uitzondering is -- u zult na de UPDATE moeten controleren op "aantal betrokken rijen" om te weten of het "geslaagd" is of niet.
Maar als u het aantal betrokken rijen opvraagt, keert u terug naar het oorspronkelijke probleem:u moet andere zoekopdrachten gebruiken in MySQL dan in HSQLDB.
HSQLDB:
CALL DIAGNOSTICS(ROW_COUNT);
MySQL:
SELECT ROW_COUNT();