SQL Server 2008 (o más reciente)
Primero, en su base de datos, cree los siguientes dos objetos:
CREATE TYPE dbo.IDList
AS TABLE
(
ID INT
);
GO
CREATE PROCEDURE dbo.DoSomethingWithEmployees
@List AS dbo.IDList READONLY
AS
BEGIN
SET NOCOUNT ON;
SELECT ID FROM @List;
END
GO
Ahora en su código C #:
// Obtain your list of ids to send, this is just an example call to a helper utility function
int[] employeeIds = GetEmployeeIds();
DataTable tvp = new DataTable();
tvp.Columns.Add(new DataColumn("ID", typeof(int)));
// populate DataTable from your List here
foreach(var id in employeeIds)
tvp.Rows.Add(id);
using (conn)
{
SqlCommand cmd = new SqlCommand("dbo.DoSomethingWithEmployees", conn);
cmd.CommandType = CommandType.StoredProcedure;
SqlParameter tvparam = cmd.Parameters.AddWithValue("@List", tvp);
// these next lines are important to map the C# DataTable object to the correct SQL User Defined Type
tvparam.SqlDbType = SqlDbType.Structured;
tvparam.TypeName = "dbo.IDList";
// execute query, consume results, etc. here
}
SQL Server 2005
Si está utilizando SQL Server 2005, todavía recomendaría una función dividida sobre XML. Primero, crea una función:
CREATE FUNCTION dbo.SplitInts
(
@List VARCHAR(MAX),
@Delimiter VARCHAR(255)
)
RETURNS TABLE
AS
RETURN ( SELECT Item = CONVERT(INT, Item) FROM
( SELECT Item = x.i.value('(./text())[1]', 'varchar(max)')
FROM ( SELECT [XML] = CONVERT(XML, '<i>'
+ REPLACE(@List, @Delimiter, '</i><i>') + '</i>').query('.')
) AS a CROSS APPLY [XML].nodes('i') AS x(i) ) AS y
WHERE Item IS NOT NULL
);
GO
Ahora su procedimiento almacenado puede ser:
CREATE PROCEDURE dbo.DoSomethingWithEmployees
@List VARCHAR(MAX)
AS
BEGIN
SET NOCOUNT ON;
SELECT EmployeeID = Item FROM dbo.SplitInts(@List, ',');
END
GO
Y en su código C # solo tiene que pasar la lista como '1,2,3,12'...
Encuentro que el método de pasar a través de parámetros con valores de tabla simplifica el mantenimiento de una solución que lo utiliza y, a menudo, ha aumentado el rendimiento en comparación con otras implementaciones, incluidas la división de cadenas y XML.
Las entradas están claramente definidas (nadie tiene que adivinar si el delimitador es una coma o un punto y coma) y no tenemos dependencias de otras funciones de procesamiento que no sean obvias sin inspeccionar el código del procedimiento almacenado.
En comparación con las soluciones que implican un esquema XML definido por el usuario en lugar de UDT, esto implica un número similar de pasos, pero en mi experiencia es un código mucho más simple de administrar, mantener y leer.
En muchas soluciones, es posible que solo necesite uno o algunos de estos UDT (tipos definidos por el usuario) que reutiliza para muchos procedimientos almacenados. Al igual que con este ejemplo, el requisito común es pasar por una lista de punteros de ID, el nombre de la función describe qué contexto deben representar esos Ids, el nombre del tipo debe ser genérico.