UPSERT - есть ли лучшая альтернатива MERGE или @@ rowcount? [закрыто]


14

Мне было интересно, если вы столкнулись с командой T-SQL, аналогичной концепции UPSERT? Выполнение операций INSERT | UPDATE с использованием параметров (1) или (2) представляется слишком сложным и подверженным ошибкам.

ЗАДАЧА

Чтобы гарантировать, что требуемая запись (в данном случае employee_id 1) является актуальной, БЕЗ необходимости по существу писать один и тот же запрос дважды.

КОНТЕКСТ

  • Название таблицы: сотрудник
  • идентификатор сотрудника: имеет первичный ключ, и для свойства proerty установлено значение true

ПАРАМЕТРЫ

  1. выполнить SQL UPDATE ... check @@ rowcount = 0 и @@ error = 0 ... выполнить SQL INSERT, если требуется

    • con: вам фактически нужно написать один и тот же запрос дважды, один раз как вставка, один раз как обновление
    • con: больше кода = больше времени печатать
    • con: больше кода = больше места для ошибки

/programming/1106717/how-to-implement-a-conditional-upsert-stored-procedure "Обновление с использованием @@ rowcount"

  1. выполнить SQL MERGE
    • con: вам фактически нужно написать один и тот же запрос дважды, один раз как вставка, один раз как обновление
    • con: больше кода = больше времени печатать
    • con: больше кода = больше места для ошибки

http://technet.microsoft.com/en-us/library/bb510625.aspx "Слияние T-SQL"

  1. выполнить SQL UPSERT (функция не существует)
    • pro: вы определяете отношение данных к таблице один раз (пусть SQL Server беспокоится о том, является ли он INSERT или UPDATE)
    • за: меньше кода = более быстрая реализация
    • за: меньше кода = меньше вероятность

Пример UPSERT

Сотрудник UPSERT (employee_id, employee_number, job_title, first_name, middle_name, фамилия ,ified_at) ЗНАЧЕНИЯ (1, '00 -124AB37 ',' Manager ',' John ',' T ',' Smith ', GetDate ());

  • если employee_id 1 не существует: MS SQL выполняет инструкцию INSERT
  • если employee_id 1 существует: MS SQL выполняется и оператор UPDATE

4
Это похоже на запрос о возможностях для Microsoft, но никто здесь не может помочь вам решить. Microsoft предложила решение MERGE. Если это не достаточно гибко для вас, вам нужно другое решение, которого еще нет.
Аарон Бертран

3
На мой взгляд, MERGEэто просто, гибко, и это также является частью стандарта SQL. Реальная проблема с MERGEдругими UPSERTреализациями - это потенциальная эскалация блокировки или даже взаимоблокировка, которая не имеет ничего общего с синтаксисом.
a1ex07

Если у вас есть вопрос, не стесняйтесь задавать его. Как написано, это в основном диатриба о MERGEреализации в SQL Server.
JNK

Хороший вопрос - есть ли по существу утверждение UPSERT, когда сервер беспокоится о том, требует ли он вставки или обновления. Я согласен, MERGE не соответствует тому, что вы логически ожидаете от реализации «UPSERT». Учитывая, что MS решила реализовать этот способ, у меня возникнет вопрос: что могло быть недостатком или невозможностью реализовать, пытались ли они реализовать синтаксис, который вы (и я) хотели бы?
youcantryreachingme

Ответы:


14

Я думаю, что простой ответ на этот вопрос - нет. MERGEбыл ответ Microsoft на более запутанную UPSERTлогику. И вы даже не перечислили худший подход:

IF (SELECT COUNT ... ) > 0
    UPDATE
ELSE
    INSERT

Я просто набросился во рту, немного печатая это, но на самом деле это тот, который я вижу чаще всего.

В любом случае, если MERGEвы не обладаете достаточной гибкостью или мощностью, я предлагаю вам отправить запрос в Microsoft по адресу http://connect.microsoft.com/sql/ и подробно объяснить ваш бизнес-кейс. Пока вы придерживаетесь реальных преимуществ предложенного вами синтаксиса MERGE, у вас есть мой голос. Если вы слишком сильно зависаете от «подверженной ошибкам» части, я вряд ли куплю. Почему? Потому что вы можете жирным пальцем любое утверждение.

Тем не менее, я не думаю, что здесь кто-то может что-то сделать специально для вас. Вы должны исследовать потенциальные проблемы с MERGE:

http://www.mssqltips.com/sqlservertip/3074/use-caution-with-sql-servers-merge-statement/


2
Спасибо Аарон. Я просмотрел документацию по T-SQL на MSDN и не смог найти то, что искал; просто думал, что выкину это на случай, если что-то пропущу. Хотя утверждение MERGE имеет смысл в определенных ситуациях, я не могу не чувствовать, что это решение «кувалдой вбить гвоздь» для простой операции сохранения. Возможно, я должен взять мою шляпу программиста, и надеть мой DBA Fedora. Спасибо, что нашли время поделиться своими мыслями.
Pressacco
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.