Jedynym rozwiązaniem, które jest obsługiwane zarówno przez MySQL, jak i HSQLDB, jest zapytanie o wiersze, które zamierzasz zastąpić, i warunkowo INSERT lub UPDATE. Oznacza to, że musisz napisać więcej kodu aplikacji, aby zrekompensować różnice między implementacjami RDBMS.
- ROZPOCZNIJ TRANSAKCJĘ.
- WYBIERZ... DO AKTUALIZACJI.
- Jeśli SELECT znajdzie wiersze, AKTUALIZUJ.
- W przeciwnym razie WSTAW.
- POTWIERDZENIE.
MySQL nie obsługuje instrukcji ANSI SQL MERGE. Obsługuje REPLACE i INSERT...ON DUPLICATE KEY UPDATE. Zobacz moją odpowiedź na " WSTAWIĆ I IGNOROWAĆ” a „WSTAWIĆ... PRZY AKTUALIZACJI ZDUPLIKOWANEGO KLUCZY” więcej na ten temat.
Re komentarze:Tak, innym podejściem jest po prostu wypróbowanie INSERT i sprawdzenie, czy się powiedzie. W przeciwnym razie wykonaj UPDATE. Jeśli spróbujesz INSERT i trafi zduplikowany klucz, wygeneruje błąd, który zamienia się w wyjątek w niektórych interfejsach klienta. Wadą takiego działania w MySQL jest to, że generuje nowy identyfikator automatycznego przyrostu, nawet jeśli INSERT nie powiedzie się. Więc kończysz z lukami. Wiem, że przerwy w sekwencji auto-inkrementacji zwykle nie są czymś, o co należy się martwić, ale w zeszłym roku pomogłem klientowi, który miał przerwy 1000-1500 między udanymi wstawkami z powodu tego efektu, w wyniku czego wyczerpał zakres INT w ich kluczu podstawowym.
Jak mówi @baraky, można zamiast tego najpierw spróbować UPDATE, a jeśli ma to wpływ na zero wierszy, zamiast tego wykonaj INSERT. Mój komentarz na temat tej strategii jest taki, że AKTUALIZACJA zerowych wierszy nie jest wyjątkiem — będziesz musiał sprawdzić „liczbę wierszy, których to dotyczy” po AKTUALIZACJI, aby wiedzieć, czy się „udało”, czy nie.
Ale zapytanie o liczbę wierszy, których to dotyczy, prowadzi do pierwotnego problemu:musisz użyć różnych zapytań w MySQL w porównaniu z HSQLDB.
HSQLDB:
CALL DIAGNOSTICS(ROW_COUNT);
MySQL:
SELECT ROW_COUNT();
