SAMENVOEGEN IN invoegvolgorde

Ik kan niet spreken over wat de Vraagsteller hier vraagt, omdat het geen . oplevert zin.

Dus laten we een ander probleem aannemen:

Laten we in plaats daarvan zeggen dat ik een heap-tabel heb zonder identiteitsveld, maar wel een "Bezocht " Datumveld.
De Heap-Table registreert webpaginabezoeken van personen en ik laad het in mijn datawarehouse.
In dit datawarehouse wil ik de surrogaatsleutel gebruiken "WebHitID " om naar deze relaties te verwijzen.
Laten we Merge gebruiken om de eerste laadbeurt van de tabel uit te voeren en deze vervolgens aan te roepen om de tabellen synchroon te houden.

Ik weet dat als ik records invoeg in een tabel, dan heb ik liever dat de ID's (die worden gegenereerd door een identificatieveld) opeenvolgend zijn op basis van de volgorde die ik kies (laten we zeggen dat de "Bezochte " Date).
Het is niet ongebruikelijk om te verwachten dat een Integer-ID correleert met het moment waarop het werd gemaakt, relatief aan de rest van de records in de tabel.
Ik weet dat dit niet altijd 100% het geval is , maar maak me even een grapje.

Dit is mogelijk met Samenvoegen.

Met behulp van (wat aanvoelt als een hack ) TOP maakt sorteren in onze bijlage mogelijk:

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.
;

Je kunt zien dat ik ervoor heb gekozen om TOP 9223372036854775807 (het grootste geheel getal dat er is) te gebruiken om alles op te halen.
Als je de middelen hebt om meer dan dat samen te voegen, dan zou je het moeten opsplitsen.
>Terwijl dit "hacky workaround . schreeuwt " voor mij zou het je moeten brengen waar je heen moet.

Ik heb dit getest op een kleine steekproefset en geverifieerd dat het werkt. Ik heb de prestatie-impact ervan niet bestudeerd op grotere complexe sets van gegevens wel, dus YMMV met en zonder de TOP.