sql >> Base de Datos >  >> RDS >> Sqlserver

FUSIONAR EN orden de inserción

No puedo hablar de lo que el interrogador está pidiendo aquí porque no hace ningún sentido.

Entonces supongamos un problema diferente:

Digamos, en cambio, que tengo una Heap-Table sin campo de identidad, pero tiene un "Visitado " Campo de fecha.
La Heap-Table registra las visitas a la página web de la persona y las estoy cargando en mi almacén de datos.
En este almacén de datos me gustaría usar la clave sustituta "WebHitID " para hacer referencia a estas relaciones.
Usemos Merge para hacer la carga inicial de la tabla, luego sigamos llamándola para mantener las tablas sincronizadas.

Sé que si estoy insertando registros en una tabla, entonces preferiría que las ID (que están siendo generadas por un campo de identificación) sean secuenciales según el Orden por que elija (digamos el "Visitado " Fecha).
No es raro esperar que un ID de entero se correlacione con el momento en que se creó en relación con el resto de los registros de la tabla.
Sé que esto no siempre es 100 % el caso , pero sígueme la corriente por un momento.

Esto es posible con Fusionar.

Usar (lo que se siente como un truco ) TOP permitirá Ordenar en nuestro Insertar:

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


Puedes ver que opté por usar TOP 9223372036854775807 (el número entero más grande que existe) para extraer todo.
Si tienes los recursos para fusionar más que eso, entonces deberías dividirlo.
>Mientras esto grita "solución alternativa " para mí, debería llevarlo a donde necesita ir.

He probado esto en un conjunto de muestra pequeño y verifiqué que funciona. No he estudiado el impacto en el rendimiento de él en conjuntos complejos más grandes de Sin embargo, los datos son YMMV con y sin TOP.