MERGE INTO порядок вставки

Question

У меня есть утверждение, которое выглядит примерно так:

MERGE INTO someTable st
USING
(
    SELECT id,field1,field2,etc FROM otherTable
) ot on st.field1=ot.field1
WHEN NOT MATCHED THEN
    INSERT (field1,field2,etc)
    VALUES (ot.field1,ot.field2,ot.etc)

где otherTable имеет автоинкрементное поле id .

Я бы хотел, чтобы вставка в someTable была в том же порядке, что и поле id поля otherTable , так что порядок из id s сохраняется при вставке несоответствующих полей.

Беглый взгляд на документы может показаться, что нет функции, поддерживающей это.

Возможно ли это, или есть другой способ сделать вставку, которая бы отвечала моим требованиям?

РЕДАКТИРОВАТЬ: Одним из подходов к этому будет добавление дополнительного поля к someTable , которое фиксирует порядок. Я бы предпочел не делать этого, если это возможно.

... после размышления подход, приведенный выше, выглядит как путь.

Answer 1

Я не могу говорить с тем, что спрашивающий здесь просит, потому что это не имеет смысла любого смысла.

Итак, давайте предположим другую проблему:

Допустим, вместо этого у меня есть таблица кучи без поля Identity-Field, но в нем есть поле даты " Visited ".
Хип-таблица регистрирует посещения человек на веб-странице, и я загружаю их в свое хранилище данных.
В этом хранилище данных я хотел бы использовать суррогатный ключ " WebHitID " для ссылки на эти отношения.
Давайте используем Merge для начальной загрузки таблицы, а затем продолжим вызывать ее, чтобы синхронизировать таблицы.

Я знаю, что если я вставляю записи в таблицу, то я бы предпочел, чтобы идентификаторы (которые генерируются полем идентификации) были последовательными и основывались на любом порядке выбора (например, «»). Посетил"Дата).
Нередко ожидать, что Integer-ID будет коррелировать с тем, когда он был создан, относительно остальных записей в таблице.
Я знаю, что это не всегда на 100%, но на мгновение меня развеселят.

Это возможно при слиянии.

Использование (что похоже на хак ) TOP позволит сортировать в нашей вставке:

MERGE DW.dbo.WebHit AS Target --This table as an Identity Field called WebHitID.
USING
(
    SELECT TOP 9223372036854775807 --Biggest BigInt (to be safe).
           PWV.PersonID, PWV.WebPageID, PWV.Visited
      FROM ProdDB.dbo.Person_WebPage_Visit AS PWV
     ORDER BY PWV.Visited --Works only with TOP when inside a MERGE statement.
) AS Source
  ON Source.PersonID  = Target.PersonID
 AND Source.WebPageID = Target.WebPageID
 AND Source.Visited   = Target.Visited
WHEN NOT MATCHED BY Target THEN --Not in Target-Table, but in Source-Table.
    INSERT (PersonID, WebPageID, Visited) --This Insert populates our WebHitID.
    VALUES (Source.PersonID, Source.WebPageID, Source.Visited)
WHEN NOT MATCHED BY Source THEN --In Target-Table, but not in Source-Table.
    DELETE --In case our WebHit log in Prod is archived/trimmed to save space.
;

Вы можете видеть, что я решил использовать TOP 9223372036854775807 (самое большое целое число), чтобы вытянуть все.
Если у вас есть ресурсы для объединения чего-то большего, то вам следует разбить их на части.
Хотя это кричит мне « хакерский обходной путь », оно должно привести вас туда, куда вам нужно.

Я проверил это на небольшой выборке и убедился, что она работает. Я не изучал влияние его производительности на большие сложные наборы данных, поэтому YMMV с и без TOP.

Answer 2

Продолжение ответа MikeTeeVee.

Использование TOP позволит вам сделать заказ в рамках подзапроса, однако вместо TOP 9223372036854775807 я бы выбрал

SELECT TOP 100 PERCENT 

Маловероятно, чтобы достичь этого числа, но этот способ имеет больше смысла и выглядит чище.

Answer 3

Почему вы заботитесь о порядке совпадения идентификаторов? Какая разница, как вы запрашиваете данные? Связанные таблицы должны быть связаны через первичные и внешние ключи, а не записи заказа были вставлены. Таблицы не упорядочены определенным образом в базах данных. Заказ должен прийти из заказа по пункту.

Более подробное объяснение того, почему вы хотите это сделать, может помочь нам найти подходящее решение.