2009-06-18 15 views
7

¿Las restricciones en una DataTable (por ejemplo, PrimaryKey & UniqueContraint) hacen que Selects sea más eficiente de la misma manera que lo harían en SQL Server? ¿O es su único propósito hacer cumplir las reglas sobre los datos?¿Cómo afectan las restricciones de DataTable de ADO.NET al rendimiento?

myDT.Constraints.Add("PK", myDT.Columns["UniqueID"], true); //add a primary key 
myDT.Constrinats.Add(new UniqueConstraint(new DataColumn[] { //add a unique constraint for UserID 
    myDT.Columns["UserID"], myDT.Columns["UniqueID"] 
})); 

¿Estos ejemplos potencialmente tener un mejor rendimiento en la búsqueda de seguridad de datos en el DataTable UniqueID o UserID?

+0

Creo que la revisión n. ° 2 es el título correcto, Terrapin. "Afectar" es una palabra mejor que "efecto" en este caso. Veo que has estado yendo y viniendo entre los dos, así que dejo que tú lo edites si estás de acuerdo. –

Respuesta

0

En general, las limitaciones disminuyen la velocidad. Pero para selecciones, la restricción única puede acelerar las cosas (pero puedo encontrar una referencia de MS), también puede estar limitada en función de la selección. La mayoría de las referencias que encuentro hablan de las restricciones que ralentizan las cosas.

Por lo tanto, en su caso podría mejorar el rendimiento.

http://msdn.microsoft.com/en-us/library/49z48hxc.aspx

+0

Encontré esto: http://www.tech-archive.net/Archive/DotNet/microsoft.public.dotnet.framework.adonet/2006-03/msg00379.html – eschneider

4

Creo que está confundiendo el uso de claves primarias y las limitaciones de dominio (modelo de negocio) con el uso de índices (rendimiento).

Una clave externa puede influir en un optimizador, y es común crear un índice en claves externas.

En el mundo de SQL Server, una clave principal a menudo se confunde con un índice agrupado, porque con mayor frecuencia que una clave sustituta (columna de autoincrementar identidad) se elige como clave principal e índice agrupado.

Este artículo puede ser de interés: DataSet and DataTable in ADO.NET 2.0.

En respuesta a tu comentario:

Utilice un DataView para las búsquedas clave repetitivo no primaria Si necesidad de buscar repetitivamente mediante el uso de datos clave no primarios, crea un DataView que tiene un orden de clasificación Este crea un índice que se puede usar para realizar la búsqueda. Esta es la mejor adecuada para búsquedas repetitivas porque hay algún costo para crear el índice .

El objeto DataView expone el hallazgo y FindRows métodos para que pueda consulta los datos en el subyacente DataTable. Si solo está realizando una sola consulta, el procesamiento que es requerido para crear el índice reduce el rendimiento que se gana por usando el índice.

Cuando se crea un objeto DataView, utilice el constructor DataView que toma el Ordena, RowFilter y valores RowStateFilter como constructor de argumentos junto con el subyacente DataTable. El uso del constructor DataView asegura que el índice es construido una vez. Si crea un DataView vacío y establece las propiedades Sort, RowFilter, o RowStateFilter posteriormente, el índice se compila en al menos dos veces.

+1

¿Hay alguna manera de agregar un índice a una DataTable ADO.NET que me daría una búsqueda eficiente en esas columnas? No vi uno, de ahí el UniqueConstraint, que en SQL Server me daría un índice implícito. Simplemente no sé si la misma eficiencia se traduce en .NET. – Seibar

+0

Debe compararlo y verlo usted mismo si mejora su situación. Los resultados pueden sorprenderle. –

+0

Benchmarking es siempre una buena idea. –

0

DataTable s se implementan utilizando B-trees (o alguna variación de los mismos). Un rápido vistazo a Reflector muestra que hay una clase Index más LiveIndexes propiedad en una clase DataTable, lo que implica que hay algunos índices, pero realmente no sé dónde están.

De mi (verdaderamente limitada) experiencia: las consultas sobre PK son realmente rápidas.

Cuestiones relacionadas