FUSIONNER DANS l'ordre d'insertion

Je ne peux pas parler de ce que le questionneur demande ici parce que cela n'en fait aucun sens.

Imaginons donc un problème différent :

Disons plutôt que j'ai une Heap-Table sans Identity-Field, mais qu'elle a un "Visited " Champ de date.
Le Heap-Table enregistre les visites de la page Web des personnes et je les charge dans mon entrepôt de données.
Dans cet entrepôt de données, j'aimerais utiliser la clé de substitution "WebHitID " pour faire référence à ces relations.
Utilisons Merge pour effectuer le chargement initial de la table, puis continuons à l'appeler pour synchroniser les tables.

Je sais que si j'insère des enregistrements dans une table, alors je préférerais que les identifiants (qui sont générés par un champ d'identification) soient séquentiels en fonction de l'ordre que je choisis (disons le "Visited " Date).
Il n'est pas rare de s'attendre à ce qu'un Integer-ID soit en corrélation avec le moment où il a été créé par rapport au reste des enregistrements de la table.
Je sais que ce n'est pas toujours le cas à 100 %. , mais faites-moi plaisir un instant.

C'est possible avec la fusion.

Utiliser (ce qui ressemble à un piratage ) TOP permettra le tri dans notre encart :

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

Vous pouvez voir que j'ai choisi d'utiliser TOP 9223372036854775807 (le plus grand entier qui existe) pour tout extraire.
Si vous avez les ressources pour fusionner plus que cela, alors vous devriez le découper.
Alors que cela crie "solution de contournement hacky " pour moi, cela devrait vous mener là où vous devez aller.

J'ai testé cela sur un petit ensemble d'échantillons et j'ai vérifié qu'il fonctionne.Je n'ai pas étudié son impact sur les performances sur des ensembles plus complexes de données cependant, donc YMMV avec et sans le TOP.