UPSERT - Чи є краща альтернатива MERGE або @@ rowcount? [зачинено]


14

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

МЕТА

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

КОНТЕКСТ

  • назва таблиці: працівник
  • ідентифікатор співробітника: має первинний ключ, а особистість особистість встановлена ​​на істину

ВАРІАНТИ

  1. виконати оновлення SQL ... перевірити @@ 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 хвилюється про те, чи це ВСТАВКА чи ОНОВЛЕННЯ)
    • pro: менше коду = швидша реалізація
    • pro: менший код = менша ймовірність

ПЕРЕГЛЯД ПРИМЕР

UPSERT співробітник (служитель_id, службовий номер, посада_тит, ім'я, ім'я, прізвище, прізвище, модифікований_AT) ЗНАЧЕННЯ (1, '00 -124AB37 ',' менеджер ',' Джон ',' T ',' Smith ', GetDate ());

  • якщо співробітник_id 1 не існує: MS SQL виконує оператор INSERT
  • якщо службовий_id 1 існує: MS SQL виконує та операцію UPDATE

4
Це здається, що запит на функцію для Microsoft, а не щось, що тут може допомогти вам вирішити. Рішення, яке Microsoft придумала, - МЕРЕ. Якщо це недостатньо гнучко / потужно для вас, вам потрібно інше рішення, яке ще не існує.
Аарон Бертран

3
На мою думку, MERGEце просто, гнучко, і це також є частиною SQL Standard. Справжня проблема з 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.