Estrategia de inserción masiva de c # a SQL Server

En nuestro proyecto actual, los clientes enviarán una colección de mensajes complejos / anidados a nuestro sistema. La frecuencia de estos mensajes es de aprox. 1000-2000 msg / por segundo.

Estos objetos complejos contienen los datos de la transacción (que se agregarán) así como los datos maestros (que se agregarán si no se encuentran). Pero en lugar de pasar los identificadores de los datos maestros, el cliente pasa la columna 'nombre'.

El sistema verifica si existen datos maestros para estos nombres. Si se encuentra, usa los identificadores de la base de datos; de lo contrario, cree primero estos datos maestros y luego use estos identificadores.

Una vez que se resuelven los identificadores de datos maestros, el sistema inserta los datos transaccionales en una base de datos de SQL Server (utilizando identificadores de datos maestros). El número de entidades maestras por mensaje es de alrededor de 15-20.

Las siguientes son algunas estrategias que podemos adoptar.

Podemos resolver los identificadores maestros primero a partir de nuestro código C # (e insertar datos maestros si no se encuentran) y almacenar estos identificadores en la memoria caché de C #. Una vez que se resuelven todos los identificadores, podemos insertar masivamente los datos transaccionales usandoSqlBulkCopy clase. Podemos presionar la base de datos 15 veces para obtener los identificadores de diferentes entidades y luego presionar la base de datos una vez más para insertar los datos finales. Podemos usar la misma conexión que la cerrará después de hacer todo este procesamiento.

Podemos enviar todos estos mensajes que contienen datos maestros y datos transaccionales en un solo golpe a la base de datos (en forma de TVP múltiple) y luego dentro del procedimiento almacenado, crear primero los datos maestros para los que faltan y luego insertar los datos transaccionales.

¿Alguien podría sugerir el mejor enfoque en este caso de uso?

Debido a algún problema de privacidad, no puedo compartir la estructura real del objeto. Pero aquí está la estructura hipotética del objeto que está muy cerca de nuestro objeto comercial.

Uno de estos mensajes contendrá información sobre un producto (sus datos maestros) y sus detalles de precios (datos de transacciones) de diferentes proveedores:

Datos maestros (que deben agregarse si no se encuentran)

Nombre del producto: ABC, ProductCateory: XYZ, Fabricante: XXX y algunos otros detalles (el número de propiedades está en el rango de 15-20).

Datos de transacción (que siempre se agregarán)

Nombre del vendedor: A, Precio de lista: XXX, Descuento: XXX

Nombre del vendedor: B, Precio de lista: XXX, Descuento: XXX

Nombre del vendedor: C, Precio de lista: XXX, Descuento: XXX

Nombre del vendedor: D, Precio de lista: XXX, Descuento: XXX

La mayor parte de la información sobre los datos maestros seguirá siendo la misma para un mensaje perteneciente a un producto (y cambiará con menos frecuencia), pero los datos de las transacciones siempre fluctuarán. Entonces, el sistema verificará si el producto 'XXX' existe en el sistema o no. De lo contrario, verifique si la 'Categoría' mencionada con este producto existe o no. De lo contrario, insertará un nuevo registro para la categoría y luego para el producto. Esto se hará para el Fabricante y otros datos maestros.

Múltiples proveedores enviarán datos sobre múltiples productos (2000-5000) al mismo tiempo.

Por lo tanto, suponga que tenemos 1000 proveedores. Cada proveedor envía datos sobre 10-15 productos diferentes. Después de cada 2-3 segundos, cada proveedor nos envía las actualizaciones de precios de estos 10 productos. Puede comenzar a enviar datos sobre nuevos productos, pero que no serán muy frecuentes.

Respuestas a la pregunta(2)

Su respuesta a la pregunta